Безопасность iOS

Недавно передо мной встала необходимость разобраться с системой безопасности iOS. В этом деле очень помог выпущенный Apple в мае 2012 года документ iOS Security. Тема очень сильно заинтересовала меня, и поэтому в статье я хочу в подробностях рассказать об архитектуре и механизмах безопасности в iOS, основываясь на этом документе Apple. Настоящей статьей я преследую три цели: во-первых, разложить для себя все “по полочкам”; во-вторых, принять участие в конкурсе; и, в-третьих, надеюсь, что статья просто будет кому-нибудь интересна.

Систему безопасности iOS можно разделить на 4 большие части:

• Базовые механизмы безопасности 
• Шифрование и защита данных 
• Сетевая безопасность 
• Доступ к устройству

В этот раз я затрону первую тему: базовые механизмы безопасности.

Базовые механизмы безопасности

Принцип безопасности заложен в саму основу iOS. Поскольку любые данные пользователя имеют высокий приоритет, Apple постарались спроектировать операционную систему так, чтобы предоставить наивысший уровень безопасности для пользовательской информации. В iPhone, iPad и iPod touch действует несколько уровней безопасности. Низкоуровневые аппаратные функции защищают устройство от вредоносного ПО, когда как высокоуровневые функции iOS обеспечивают безопасный доступ к пользовательским данным и корпоративной информации, а также предотвращают несанкционированное использование устройства.

Благодаря тесной взаимосвязи программного и аппаратного обеспечения в устройствах под управлением iOS, каждый шаг, начиная от нагрузки системы и заканчивая установкой приложений, анализируется с точки зрения безопасности и эффективности использования ресурсов. Целостность системы безопасности напрямую зависит от целостности и надежности ядра iOS – XNU. На Рисунке 1 схематично показана архитектура системы безопасности iOS. Каждый из компонентов архитектуры, так или иначе, будет описан в дальнейшем.

Рисунок 1. Архитектура безопасности iOS

Цепочка доверенной загрузки

Каждый шаг загрузки содержит компоненты, которые имеют цифровую подпись Apple. На Рисунке 2 изображена цепочка доверенной загрузки.

Рисунок 2. Цепочка доверенной загрузки

При включении устройства процессор немедленно начинает исполнять код из read-only памяти, так называемой BootROM. Код зашивается в чип еще при производстве, поэтому к коду имеется безоговорочное доверие. BootROM также содержит сертификат корневого центра сертификации Apple. C помощью сертификата BootROM проверяет цифровую подпись низкоуровнего загрузчика (Low-Level Bootloader - LLB). LLB затем проверяет подпись и запускает следующий загрузчик – iBoot. И, наконец, iBoot проверяет и запускает ядро.

Цепочка доверенной загрузки выполняет две функции. Во-первых, она гарантирует, что низкоуровневое ПО не подверглось никаким несанкционированным изменениям; и во-вторых, позволяет iOS загружаться только на устройствах Apple.

Если какому-либо шагу в процессе не удается проверить или запустить следующий шаг, то загрузка прекращается, устройство входит в режим восстановления (recovery mode) и на экране отображается надпись “Connect to iTunes”. Если же сбой происходит уже на первом шаге, то есть если BootROM не удалось проверить и загрузить LLB, то устройство входит в режим DFU (Device Firmware Upgrade – обновление прошивки устройства). В обоих случаях необходимо подключить устройство к iTunes и вернуться к заводским настройкам.

Персонализация системного ПО

Apple периодически выпускает обновления безопасности, о которых оповещает пользователя на самом устройстве или через iTunes. Apple делает все возможное, чтобы обновления безопасности были установлены на устройствах пользователя как можно быстрее.

Теперь представим себе такую ситуацию: нарушитель получил доступ к устройству и хочет понизить версию системы, чтобы использовать уязвимости, которые исправлены в новой версии. Для предотвращения подобных ситуаций, в iOS существует механизм персонализации системного ПО (System Software Personalization).

Обновления iOS можно установить либо с помощью iTunes, либо “по-воздуху” (через Wi-Fi). В первом случае скачивается и устанавливается полная копия iOS. При обновлении по Wi-Fi скачиваются только необходимые “дельта-файлы”.

Как же работает механизм персонализации системного ПО? Во время инсталляции или обновления iOS iTunes или само устройство (в случае обновления по Wi-Fi) подключается к серверу обновления Apple (gs.apple.com) и посылает следующую информацию:

1. Список криптографических параметров каждого обновления; 
2. Случайное число; 
3. Уникальный идентификатор устройства (ECID).

Получив данные от клиента, сервер проверяет, возможна ли установка такой версии обновления на устройство пользователя. Если установка возможна, то сервер добавляет к параметрам ECID (именно ECID “персонализирует” устройство), подписывает их (параметры и ECID) и отправляет обратно пользователю. Только после успешной проверки пользователь может продолжить установку.

Как уже упоминалось выше, BootROM содержит сертификат корневого центра сертификации Apple, поэтому цепочка доверенной загрузки сможет проверить электронную подпись сервера обновлений.

Механизм персонализации также гарантирует, что не удастся скопировать старую версию iOS с одного устройства на другое. Благодаря случайному числу, нарушитель не сможет сохранить ответ сервера, чтобы в будущем использовать его для понижения версии системы (атака повтором).

Тем не менее, способы понижения версии системы существуют. Но и здесь есть одно условие: для успешного понижения версии необходимо иметь сохраненный SHSH-сертификат прошивки той версии, на которую вы собираетесь понижать систему. SHSH-сертификат – это уникальная цифровая подпись прошивки. SHSH-сертификат для каждой версии прошивки отличается, именно поэтому, не имея SHSH-сертификат старой прошивки, понизить версию системы не получится. Кроме того, необходимо внести изменения в файл hosts. Это делается для того, чтобы iTunes взаимодействовал не с сервером Apple, а с поддельным сервером, который всегда разрешает установку старой прошивки.

Подписание кода приложений

После загрузки iOS следит за тем, какое пользовательское предложение может быть запущено, а какое нет. Для гарантии того, что все приложения поступили из проверенного источника, и что в них не было внесено никаких изменений, iOS требует, чтобы каждый исполняемый код был подписан. Приложения, поставляемые вместе с устройством (например, Mail или Safari), подписываются самой Apple. Обязательное подписание кода расширяет рамки действия принципа доверия с уровня операционной системы на уровень приложений и препятствует выполнению вредоносного или самомодифицирующегося кода.

Для публикации своих приложений сторонние разработчики должны зарегистрироваться в Apple и присоединиться к программе iOS Developer Program. Перед выпуском сертификата Apple проверяет личность каждого разработчика. Сертификат дает разработчикам возможность подписывать приложения и размещать их в Apple Store. Приложение также проверяется Apple на предмет нормального функционирования, возможных багов и.т.п.

Но и тут не обходится без прецедентов. Уследить за всеми приложениями не представляется возможным, и иногда за звучным названием (например, Microsoft Word 2012) и немаленькой ценой скрывается совершенно бесполезное приложение или приложение, не выполняющее заявленных функций. Нерадивые разработчики также могут создавать искусственные отзывы, чтобы искусственно поднять рейтинг своим приложениям.

Очень часто перед организациями встает необходимость писать программы для внутреннего использования и распространять их среди своих рабочих. Для этого организации могут присоединиться к программе iOS Developer Enterprise Program (iDEP). После проверки организация может получить специальный профайл, который позволяет разрабатывать приложения для внутреннего пользования. Чтобы запускать корпоративное приложение, пользователь должен на свое устройство установить профайл. Это также гарантирует, что доступ к приложению будут иметь только работники компании.

В отличие от других мобильных платформ, iOS не позволяет пользователям установить потенциально вредоносное ПО или исполнять код из сомнительного источника. Каждый раз перед загрузкой исполняемых страниц в память операционная система производит проверку подписи кода. Проверка позволяет выявить нежелательные изменения в коде с момента установки или обновления приложения.

Безопасность времени выполнения процессов

Итак, допустим, что приложение поступило из доверенного источника, и его код надлежащим образом подписан. Но и на этом меры безопасности не заканчиваются. iOS также следит за тем, чтобы приложение никак не повлияло на работу других приложений или системы. Именно поэтому все сторонние приложения работают в “песочнице” (sandbox). У каждого приложения есть домашняя папка, в которой хранятся его файлы, домашняя папка создается во время установки приложения на устройство. При необходимости доступ к системной информации приложение может получить посредством API или системных служб.

Системные файлы и ресурсы также защищены от пользовательских приложений. Большинство системных процессов, как и все процессы сторонних приложений, выполняются с правами непривилегированного пользователя “mobile”. Раздел, на котором установлена iOS, доступен только для чтения.

Необязательные системные утилиты (например, удаленное подключение или шелл) исключены из системного ПО, а API не позволяют пользовательским процессам повысить свои привилегии, чтобы внести изменения в другие приложения или саму iOS.

Доступ сторонних приложений к пользовательской информации или специальным сервисам (таким как iCloud) контролируется с помощью “прав доступа” (entitlements). Права доступа встроены в приложение и представляют собой пару “ключ-значение”. Поскольку права доступа имеют цифровую подпись, то их нельзя изменить. Права доступа широко используются системными приложениями и демонами для осуществления специальных привилегированных операций, которые в противном случае потребовали бы прав root’а. Благодаря использованию прав доступа в значительной степени снижается риск несанкционированного повышения привилегий.

 Рисунок 3. Пример прав доступа для использования iCloud

Следующий механизм – рандомизация адресного пространства (Address space layout randomization - ASLR) – защищает систему от эксплуатации багов в памяти. ASLR – это технология, благодаря которой случайном образом изменяется расположение важных структур в адресном пространстве процесса. Встроенные приложения используют ASLR для гарантии того, что размещение всех регионов памяти во время запуска рандомизируется. Кроме того, Xcode – среда разработки приложений для iOS – автоматически компилирует сторонние приложения с поддержкой ASLR.

И, наконец, последний механизм защиты, это ARM’s Execute Never (XN). Функция ARM’s XN помечает страницы в памяти как недоступные для выполнения кода. iOS позволяет приложениям использовать страницы, помеченные одновременно, как доступные для записи и выполнения кода, только при выполнении строгих условий: у приложения должно присутствовать право доступа “dynamic-codesigning”, а такое право доступа есть только у приложений, выпущенных самой Apple. И даже при выполнении этого условия, приложение сможет запросить страницу, доступную для записи и выполнения, только один раз. В частности, этим пользуется Safari для своего JIT-компилятора JavaScript.

Путь к свободе

После всего вышесказанного система безопасности iOS может показаться неприступной. Но почему тогда после выхода новой версии iOS, многие люди с нетерпением ждут jailbreak’а? И их надежды рано или поздно оправдываются. Как вообще возможен jailbreak? Для начала немного теории.

Jailbreak (англ. “побег из тюрьмы”) – это процедура, позволяющая получить полные права доступа ко всем разделам на устройстве.

Главная цель при jailbreak’е – модифицировать файл /private/etc/fstab, чтобы смонтировать системный раздел, как доступный для чтения/записи. Jailbreak также подразумевает модификацию службы AFC (служба используется iTunes для доступа к файловой системе устройства); модифицированная служба называется AFC2, и она позволяет получить доступ к файловой системе уже с правами root. Современные jailbreak’и также делают патч ядра для обхода механизма подписания кода и других ограничений.

Существует три вида jailbreak’а:

• привязанный (tethered) – такой jailbreak держится до перезагрузки устройства. После перезагрузки потребуется вновь сделать jailbreak, причем устройство будет неработоспособных до тех пор, пока не будет сделан повторный jailbreak. 
• полупривязанный (semi-tethered) – jailbreak также работает только до перезагрузки, но после перезагрузки устройство все же можно использовать. 
• непривязанный (untethered) – jailbreak в истинном смысле слова: не слетает при перезагрузке.

К сожалению (или к счастью), код пишут люди, и поэтому он не обходится без багов. Jailbreak возможен именно благодаря уязвимостям в коде. Существует множество эксплойтов, использующих уязвимости на различных уровнях системы, например:

• на уровне BootROM (0x24000 Segment Overflow, usb_control_msg(0xA1, 1) Exploit). Эксплойты этого уровня могут нарушать принцип цепочки доверия с самого начала, например, обходя проверку подписи LLB. 
• на уровне iBoot (iBoot Environment Variable Overflow, usb_control_msg(0x21, 2) Exploit). 
• на уровне ядра (IOSurface Kernel Exploit, ndrv_setspec() Integer Overflow, HFS Heap Overflow). 
• и даже на уровне пользовательских процессов (MobileBackup Copy Exploit, T1 Font Integer Overflow, Racoon String Format Overflow Exploit).

В каждой новой версии операционной системы Apple старается исправлять уязвимости предыдущей системы.

Итак, в этой статье рассказывалось о базовых функциях безопасности операционной системы iOS, а также о том, что, несмотря на кажущуюся неуязвимость системы, всегда найдутся способы обойти функции безопасности. Да, возможно, для кого-то jailbreak покажется всего лишь безобидным способом бесплатно устанавливать приложения, но речь здесь идет о другом, jailbreak еще раз подтверждает простую истину: полностью безопасных систем нет; и один из способов держать уровень безопасности на приемлемом уровне – это своевременные обновления.

В следующей статье речь пойдет о самой, на мой взгляд, интересной и сложной подсистеме безопасности iOS – шифровании и защите данных.

Источники:

1. http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf 
2. https://developer.apple.com/library/ios/navigation/index.html 
3. http://theiphonewiki.com/wiki/ 
4. http://www.idownloadblog.com/downgrade/