Безопасность Apple Mobile Devices. Часть III. Что происходит после нажатия Power

Итак, в прошлой части мы остановились на мысли, что современный iPhone имеет смысл рассматривать уже не как устройство, в котором где-то лежит некий суперсекретный ключ, а как довольно сложную машину состояний, которая на каждом этапе проверяет, имеет ли следующий кусок системы право вообще существовать.

Попробуем теперь пройти всю эту цепочку руками, от момента нажатия кнопки Power до запуска какого-нибудь Signal или Telegram, и посмотреть, в какой именно момент какие куски железа и софта начинают друг другу доверять.

Сразу оговорюсь, что буду местами упрощать детали реализации, иначе вместо статьи получится справочник страниц на триста, но общая архитектура от этого не пострадает.

Начинается все, как и раньше, с BootROM.

Это тот самый маленький кусок кода, зашитый непосредственно в SoC еще на производстве и не подлежащий обновлению после того, как процессор покинул фабрику. Именно поэтому уязвимости уровня checkm8 были настолько неприятны для Apple: если ошибка находится в коде, который физически нельзя переписать, "починить" уже выпущенные устройства невозможно вообще, можно только изменить архитектуру следующего поколения железа.

BootROM в данном случае является самым нижним корнем доверия основной системы.

У него есть ровно одна фундаментальная задача: проверить, что следующий этап загрузки действительно подписан Apple, и только после этого передать ему управление.

То есть в самом начале у нас пока нет ни iOS, ни файловой системы, ни пользовательского пароля, ни приложений, вообще ничего привычного. Есть процессор, немного ROM-кода и криптографическая проверка следующего куска.

Если подпись не сходится, цепочка рвется.

Если сходится, запускается следующий компонент.

Дальше в игру вступает iBoot, который по смыслу по-прежнему делает примерно то же, что делал двенадцать лет назад: проверяет и подготавливает запуск ядра, следит за тем, что загружается именно разрешенный образ системы, участвует в recovery/update сценариях и продолжает цепочку доверия дальше.

На этом месте полезно остановиться и заметить одну штуку, которая кажется очевидной только задним числом.

Secure Boot не доказывает, что система безопасна.

Он доказывает только, что загружается именно тот код, который Apple разрешила загружать.

Это не одно и то же.

Если в разрешенном Apple коде есть уязвимость, Secure Boot с удовольствием эту уязвимость запустит.

То есть подпись отвечает на вопрос "это наш код?", но никак не на вопрос "в нем нет ошибок?".

Именно поэтому вся история jailbreak и вообще exploitation Apple устройств много лет строилась не вокруг того, чтобы подделать криптографическую подпись Apple, что в нормальной постановке практически безнадежно, а вокруг того, чтобы найти ошибку уже в доверенном коде и заставить его сделать то, чего он делать не должен.

После iBoot стартует XNU kernel.

И вот здесь начинается уже привычная операционная система.

Поднимается память, драйверы, I/O, sandbox, userspace, системные сервисы и все остальное хозяйство, которое мы в обычной жизни называем iOS.

Но даже на этом этапе телефон еще нельзя считать "разблокированным" в человеческом смысле этого слова.

Ядро загрузилось.

Система работает.

Радиомодули могут жить своей жизнью.

Экран показывает интерфейс.

Но значительная часть пользовательских данных все еще криптографически недоступна.

И вот тут появляется Secure Enclave.

Если сильно упростить, внутри вашего iPhone сидит второй маленький компьютер, которому основной Application Processor не доверяет настолько, чтобы просто передать ему секреты, и который в свою очередь не доверяет основному процессору настолько, чтобы отдавать ему свои.

Secure Enclave имеет собственную загрузочную цепочку, собственную память, собственные аппаратные ключи и отдельную операционную среду.

На современных устройствах значительная часть наиболее неприятной для атакующего логики происходит именно там.

Например, обработка пользовательского passcode.

Когда вы вводите PIN на экране, ситуация не выглядит так, что iOS берет строку "123456", сравнивает ее с записью где-нибудь в /etc/passwd и, если совпало, говорит "проходите".

Пароль используется как часть криптографического процесса.

И это принципиально важный момент.

Ваш passcode сам по себе не является ключом от всех данных.

Он скорее является одним из ингредиентов процедуры, в которой участвует также аппаратный секрет конкретного устройства.

То есть если злоумышленник скопировал содержимое flash-памяти iPhone, это еще не означает, что он может унести этот образ домой, запустить перебор на кластере видеокарт и спокойно ждать.

Криптографическая операция привязана к конкретному железу.

Нужен именно тот процессор, внутри которого живет уникальный аппаратный секрет.

А этот процессор, в свою очередь, не обязан разрешать вам миллион попыток в секунду.

И вот здесь появляется один из тех моментов, когда аппаратная архитектура внезапно становится важнее длины пароля.

Если пароль перебирается не на RTX-кластере, а через конкретное защищенное устройство, которое способно искусственно замедлять попытки, блокировать их или привязывать к внутреннему состоянию, пространство атаки резко меняется.

Именно поэтому короткий цифровой PIN на современном iPhone в реальной жизни может быть гораздо неприятнее для атакующего, чем кажется, если мыслить обычными категориями password hash.

Конечно, это не значит, что четыре цифры внезапно стали хорошим паролем.

Это значит только, что атакуется уже не просто пароль.

Атакуется протокол.

Теперь переходим к данным.

Пусть у нас на телефоне лежит фотография.

Интуитивная модель говорит: существует зашифрованный диск, у диска есть ключ, после разблокировки телефона ключ появляется и диск расшифровывается.

В современных Apple устройствах это слишком примитивная картина.

Данные разбиты на классы защиты.

У отдельных файлов могут быть свои ключи.

Эти ключи завернуты другими ключами.

Доступность конкретного класса зависит от текущего состояния устройства.

Например, некоторые данные доступны после первой разблокировки после загрузки и остаются доступны до следующего reboot.

Другие могут снова становиться недоступными после блокировки экрана.

Отсюда, кстати, известные термины BFU и AFU, Before First Unlock и After First Unlock, которые регулярно всплывают в forensic-среде.

Один и тот же физически включенный iPhone до первой разблокировки и после нее с точки зрения доступности данных является практически двумя разными машинами.

До первой разблокировки после reboot значительная часть ключевого материала еще не была разблокирована через пользовательскую аутентификацию.

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

И это уже имеет вполне практические последствия.

Если вы исследуете захваченный телефон, вопрос "он включен?" малоинтересен.

Куда интереснее вопрос "он уже был разблокирован после последней загрузки?".

Разница может быть колоссальной.

Теперь допустим, пользователь успешно ввел пароль.

Secure Enclave согласился, что аутентификация прошла.

Необходимые keybags, class keys и прочий криптографический инвентарь перешли в состояние, позволяющее системе читать соответствующие данные.

Можно ли теперь сказать, что все закончилось?

Разумеется нет.

Потому что мы пока только разрешили самой операционной системе читать определенные файлы.

Но у нас есть еще приложения.

Каждое приложение в iOS живет не просто как исполняемый файл, а внутри довольно жестко ограниченного окружения.

У приложения есть code signature.

Есть entitlements, то есть подписанный набор разрешений, которые Apple допустила для конкретного бинарника.

Есть sandbox-профиль.

Есть контейнер данных.

И если какое-то приложение внезапно решит "а дай-ка я прочитаю базу Signal, фотографии Telegram и токены банковского клиента", одного желания будет недостаточно.

Приложению в нормальном режиме просто не дадут открыть чужие файлы.

И здесь снова возвращается тот же архитектурный принцип.

Защита строится не на одной стене.

Она строится на том, что после прохождения каждой стены вас встречает следующая.

Допустим, нашли баг в Safari и получили исполнение произвольного кода внутри WebContent процесса.

Это еще не root.

Получили escape из sandbox.

Это еще не kernel.

Получили kernel read/write.

Это еще не автоматически Secure Enclave.

Получили контроль над Application Processor.

Это еще не автоматически пользовательский passcode.

Получили доступ к файловой системе.

Это еще не означает доступ ко всем Data Protection classes.

Получили доступ к одному приложению.

Это еще не означает, что можно подписать произвольный код или нормально пережить reboot.

В результате современный exploit все меньше похож на "нашел одну дырку и взломал айфон" и все больше напоминает сборку лестницы из нескольких уязвимостей, каждая из которых позволяет достать до следующей ступеньки.

Собственно, поэтому хорошие exploit chains стоят таких денег.

Не потому что одна ошибка памяти стоит миллионы долларов.

А потому что нужны несколько ошибок в правильных местах, на правильных версиях системы, с правильной надежностью, желательно без краша устройства, с обходом mitigation-механизмов и в идеале так, чтобы пользователь вообще ничего не заметил.

Отдельная веселая тема здесь, конечно, PAC.

Pointer Authentication появилась именно потому, что классическая эксплуатация memory corruption десятилетиями строилась на довольно простой идее: если я могу испортить указатель, то, возможно, смогу заставить процессор исполнить нужный мне адрес.

Apple решила добавить к некоторым указателям криптографическую подпись.

То есть адрес возврата функции теперь условно представляет собой не просто "вернись по адресу 0x12345678", а "вернись по адресу 0x12345678, причем вот доказательство, что этот указатель сформирован в допустимом контексте".

Подделали адрес, подпись не сходится, процесс завершается.

Разумеется, как всегда в security, это не магическая защита от всего на свете.

PAC обходили, обходят и будут обходить.

Но он опять повышает стоимость перехода от "у меня есть повреждение памяти" к "у меня есть произвольный control flow".

Именно это вообще является сквозной идеей всей современной Apple security.

Не сделать эксплуатацию невозможной.

Сделать каждый следующий переход дорогим.

Кстати, если посмотреть на архитектуру с этой стороны, довольно забавно меняется само понятие root.

В классическом Unix root является богом.

UID 0, и система практически ваша.

В iOS root уже давно не бог.

Root является просто очень привилегированным участником системы, окруженным сущностями, которым на его мнение временами глубоко плевать.

Secure Enclave не обязан раскрывать ему секреты.

Аппаратные ключи не обязаны ему показываться.

BootROM не обязан исполнять подписанный им код.

AMFI не обязан считать его бинарник допустимым только потому, что процесс имеет UID 0.

Sandbox и entitlements могут продолжать существовать как отдельные механизмы.

И вот это, пожалуй, один из самых интересных сдвигов всей индустрии.

Privilege больше не является скаляром.

Нельзя просто сказать: "у этого процесса уровень доступа 100, значит он сильнее процесса с уровнем доступа 50".

Есть разные измерения доверия.

Один компонент может иметь полный контроль над kernel memory, но не знать аппаратного ключа.

Другой может выполнять криптографические операции аппаратным ключом, но не иметь доступа к пользовательской файловой системе.

Третий может читать фотографии пользователя, но не иметь права исполнять неподписанный код.

Получается не лестница привилегий, а граф capabilities.

И вот теперь можно наконец запустить условный Signal.

Система проверяет подпись бинарника.

Проверяет entitlements.

Создает процесс в соответствующем sandbox.

Приложение получает доступ к собственному контейнеру.

Если его база данных относится к классу Data Protection, недоступному в текущем состоянии устройства, файл может физически находиться на накопителе, но прочитать его все равно не получится.

Если доступ разрешен, ключевая иерархия уже находится в нужном состоянии, файловая система отдает расшифрованные блоки приложению.

При этом само приложение может сверху добавить собственное шифрование базы, собственный PIN, собственное использование Keychain и еще несколько уровней защиты.

То есть путь от нажатия кнопки Power до появления списка чатов выглядит примерно так:

BootROM должен поверить iBoot.

iBoot должен поверить kernel.

Kernel должен поднять доверенную userspace-среду.

Secure Enclave должен прийти в допустимое состояние.

Пользователь должен доказать знание passcode или пройти биометрию в рамках разрешенной политики.

Должны стать доступны соответствующие ключевые классы.

Подпись приложения должна быть валидной.

Entitlements должны совпасть с тем, что приложению разрешено.

Sandbox должен позволить открыть конкретный контейнер.

Data Protection должен позволить расшифровать конкретный файл.

И только после этого Signal наконец сможет показать вам, что кто-то прислал очередной стикер.

Двенадцать лет назад я смотрел на эту конструкцию и думал примерно так: вот Bootloader, вот iBoot, вот AES GID key, если где-то перехватить управление достаточно рано, дальше все посыпется.

Сегодня правильнее было бы сказать иначе.

Чем раньше вы перехватили управление, тем больше у вас возможностей повлиять на последующие состояния.

Но это не означает, что все последующие компоненты обязаны вам поверить.

И вот это, пожалуй, главное отличие архитектуры современных устройств от той довольно линейной модели доверия, которая существовала в голове у большинства из нас во времена первых jailbreak.

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

Прошел стену, оказался внутри.

Современный iPhone скорее похож на город, в котором после городской стены есть паспортный контроль в каждом районе, внутри района отдельный банк, внутри банка сейф, а сейф вдобавок интересуется не только тем, кто вы такой, но и тем, каким маршрутом вы сюда пришли.

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

И если в 2014 году вопрос звучал "как взломать iPhone?", то сейчас технически корректнее спросить:

какое именно состояние системы мы хотим получить и какие границы доверия для этого придется пересечь?

Вот с этого места уже начинается действительно интересная часть.

Потому что в следующей статье можно наконец разобрать современный jailbreak не как магическую кнопку "снять защиту", а как exploit chain: какие именно звенья приходится ломать, зачем нужны kernel bugs, sandbox escape, PAC bypass, entitlement tricks, почему persistence является отдельной проблемой и почему очередной "полный jailbreak" в заголовке новости зачастую означает совсем не то, что означал тот же термин пятнадцать лет назад.