ttt

iPhone 5c стал последним смартфоном от Apple, основанном на 32-битном процессоре. В то же время iPhone 5c – знаковая модель, получившая широкую известность после инцидента в Сан-Бернардино. Пять лет назад взлом iPhone 5c террориста из Сан-Бернардино стал камнем преткновения и причиной жаркого спора между Apple и ФБР. Сегодня же взломать такой аппарат можно быстро и достаточно просто.

Чем интересен iPhone 5c, по любым меркам – серьёзно устаревший телефон? Как минимум, двумя вещами. С технической точки зрения это – последняя модель iPhone, в которой нет сопроцессора Secure Enclave, что позволяет получить полный доступ к его содержимому, включая все без исключения ключи шифрования. Взлом iPhone этой модели – по сути, последняя оставшаяся возможность покопаться во внутренностях подсистемы безопасности iOS, которая в более новых моделях становится недоступной из-за аппаратной защиты.

Но интересна эта модель не только с технической, но и с политической точки зрения. Именно эта модель стала камнем преткновения и точкой столкновения интересов Apple и Федерального бюро расследований.

Историческая справка

Являясь, по сути, проходной бюджетной моделью, iPhone 5c стал печально известным после террористической атаки в Сан-Бернардино в декабре 2015 года. Принадлежавший работодателю стрелка телефон этой модели оказался заблокирован неизвестным ни самому работодателю, ни спецслужбам паролем из четырёх цифр. Более того, устройство было настроено на уничтожение всех данных после десяти неудачных попыток подобрать пароль. Судорожные метания привели к поспешным поступкам. Работодатель террориста изменил пароль от iCloud, что привело к невозможности создания свежей резервной копии в облаке. Работа спецслужб застопорилась; для извлечения информации из телефона был нужен код блокировки.

Технических средств для взлома таких устройств в те годы не существовало. Федеральное бюро расследований потребовало, чтобы в Apple создали программное обеспечение, которое позволило бы ФБР разблокировать iPhone 5c террориста. В Apple отказались создавать такое программное обеспечение (хотя чисто технически могли это сделать, не напрягаясь). Было назначено судебное слушание. Однако за день до него обвинение потребовало отсрочки, заявив о существовании третьей стороны, способной помочь в разблокировке. Ещё через несколько дней было объявлено, что ФБР удалось разблокировать аппарат. Слушание не состоялось, иск был отозван.

До сих пор официально неизвестно, каким методом воспользовалось ФБР для получения пароля и кто его разработал. Однако нам известна примерная сумма, уплаченная за взлом устройства: директор ФБР Джеймс Коми сообщил в интервью, что взлом телефона обошёлся ФБР более чем в 1,3 миллиона долларов. Впрочем, имя подрядчика так и не обнародовали. Некоторые анонимные источники утверждают, что подрядчикам была израильская компания Cellebrite, которая не опровергла, но и не подтвердила этот факт. Однако The Washington Post сообщила, что, по словам очередных анонимных «людей, знакомых с вопросом», ФБР заплатило «профессиональным хакерам», которые использовали неопубликованную уязвимость в программном обеспечении iPhone.

Альтернативы

У предложенного нами способа взлома iPhone 5c есть несколько альтернатив. В первую очередь, конечно же, нужно упомянуть сугубо коммерческие продукты и сервисы компании Cellebrite. Эти решения доступны исключительно правоохранительным органам, причём не каждой страны, а их стоимость составляет десятки тысяч долларов.

В своё время перебирать коды блокировки можно было при помощи аппаратного «чёрного ящика» IP-BOX и его клонов. Основной недостаток всех этих устройств в том, что они не работают с современными версиями iOS: поддерживаются только версии iOS до iOS 8.1 включительно. Второй недостаток – низкая скорость перебора: порядка 6 секунд на попытку, 17 часов на взлом четырехзначного PIN-кода.

Ещё одной попыткой стало решение за авторством Сергея Скоробогатова. В своём проекте «Анализ безопасности Apple iPhone 5c» Сергей продемонстрировал атаку, позволяющую подобрать код блокировки iPhone 5c. У метода, предложенного Сергеем, также есть недостатки. Во-первых, телефон потребуется разобрать, что не каждому по силам. Второй недостаток тот же, что и у IP-BOX: скорость перебора не превышает одного пароля в 5 секунд. Сам Сергей утверждает, что взломать четырехзначный код доступа можно примерно за сутки, а перебор шестизначного PIN-кода и вовсе бессмыслен.

Как это работает

Мы создали чисто программный метод, позволяющий запустить перебор паролей непосредственно на самом устройстве. Отвёртка и паяльник для этого не нужны; достаточно простого кабеля Lightning. Наш метод базируется на хорошо изученном эксплоите checkm8, который, впрочем, непригоден для запуска атаки на пароль в чистом виде. В настоящий момент мы реализовали атаку только с компьютеров Mac.

Процесс взлома iPhone 5c выглядит следующим образом.

Для начала нам нужно загрузить на устройство свой собственный кастомный ramdisk. Именно с него осуществляется перебор пароля. Загрузка кастомной (неподписанной) прошивки стала возможной благодаря BootROM эксплойту checkm8. Для загрузки устройства и отключения всех проверок выполняем следующие шаги.

Шаг 1. Переводим телефон в режим DFU

На первом шаге необходимо ввести устройство в режим DFU. Сделать это можно только вручную; никакой команды, которая могла бы это сделать, не существует. Для iPhone 5c обнаружено несколько вариантов перехода в нужный режим. Например, такой.

При использовании Elcomsoft iOS Forensic Toolkit будут выданы интерактивные инструкции.

Довольно простой нам кажется следующая последовательность.

Начальное состояние: телефон должен быть выключен и не подключён к компьютеру.

• Нажимаем кнопку Home (единственную/центральную на лицевой панели), и удерживая её, подключаем кабель Lightning. Отпускаем Home, когда на экране устройства появится картинка «Подключитесь к iTunes».
• Одновременно зажимаем Home и Sleep/Power (кнопка блокировки на верхнем торце устройства) и удерживаем их в течение 8 секунд (на некоторое время на экране появится логотип Apple).
• Отпускаем кнопку Sleep/Power, но продолжаем удерживать Home ещё 8 секунд.

Если всё сделано правильно, экран аппарата останется чёрным, а в iTunes или Finder (в зависимости от используемой версии macOS) телефон появится как iPhone in recovery mode (режим восстановления).

Всё готово к следующим шагам.

Шаг 2. Эксплоит DFU

На этом шаге проводим загрузку в режим pwned DFU по методу, который используется в эксплойте checkm8. Этот эксплоит интересен тем, что использует аппаратную уязвимость в загрузчике BootROM, которая не может быть исправлена обновлением прошивки. На устройствах с Secure Enclave (все 64-битные модели iPhone начиная с iPhone 5s) таким образом можно сделать джейлбрейк, но запустить быстрый перебор паролей не удастся: Secure Enclave ограничит скорость перебора на аппаратном уровне. А вот iPhone 5c – идеальный кандидат: аппаратного сопроцессора безопасности нет, можно делать практически что угодно.

Вопрос: зачем в таком случае взламывать код блокировки? Не проще ли сразу извлечь из телефона данные? Увы, без кода блокировки извлечь получится очень ограниченное количество информации. Основной массив данных будет зашифрован, а ключ вычисляется на основе кода блокировки, который вводит пользователь после загрузки устройства. При этом и вынести перебор за пределы iPhone тоже нельзя; проверка кода блокировки и вычисление ключей шифрования должна проводиться процессором самого устройства.

Однако продолжим. В результате работы эксплоита мы попадаем в режим, известный под неофициальным названием pwned DFU. Это всё ещё режим DFU (то есть, система не загружена), но у нас появился доступ к системным файлам (таким образом можно установить джейлбрейк checkra1n) и к Ramdisk устройства.

Нас сейчас интересует именно Ramdisk. Для запуска атаки на код блокировки нам нужно запустить наш собственный код. Однако для запуска неподписанного приложения одного лишь эксплоита мало, так как мы должны пропатчить проверку подписи на каждом этапе загрузки, а именно в файлах из прошивки iBSS, iBEC и kernelcache.

Шаг 3. Отключаем проверки подписи

На этом шаге мы патчим проверку подписи в iBSS. В iBEC же патчится не только проверка подписи, но и устанавливаются следующие параметры загрузки:

boot-args: "rd=md0 -v amfi=0xff cs_enforcement_disable=1"

Благодаря этим параметрам мы получаем verbose boot и отключаем проверку подписи у ядра.

Для загрузки устройства нужен ещё один файл – DeviceTree. Он представляет собой иерархическое описание аппаратных устройств, которые затем будет использовать ядро. Этот файл патчить не нужно.

Шаг 4. Патчим Ramdisk

Ещё одним важным файлом, который загружается на устройство, является сам Ramdisk. В контексте операционной системы iOS Ramdisk – это виртуальный диск с файловой системой, который хранится в оперативной памяти устройства.

В качестве основы возьмём Restore Ramdisk из официальной прошивки Apple и модифицируем его. В штатный Ramdisk добавим стандартные утилиты командной строки (bash, mkdir, ls и т.п.) - без них мы не сможем потом получить доступ к командной строке и выполнять какие-либо команды на устройстве. Но прежде всего в рамдиск необходимо загрузить сервер SSH, чтобы иметь возможность подключиться к телефону с компьютера. Для этого скопируем на Ramdisk sshd c необходимыми файлами конфигурации и пропатчим утилиту restored_exteral (она изначально есть на рамдиске), чтобы она сразу же после загрузки рамдиска поднимала сервер SSH.

Шаг 5. Патч ядра

Теперь нам нужно пропатчить ядро (kernelcache).

Изначально iPhone 5c вышел с iOS 7.0; последняя версия iOS, доступная для этого телефона — 10.3.4. Начиная с iOS 10 (а мы загружаем прошивку именно этой версии) для запуска приложения недостаточно просто отключить проверку подписи. Помимо этого необходимо, чтобы хеш исполняемого файла находился в так называемом AMFI trust_cache. Соответственно, первым делом отключаем проверку trust_cache (иначе sshd и пропатченная утилита restored_external просто не запустятся).

Второй важный патч связан с тем, что для перебора пароля нам нужен доступ к аппаратному ключу 0x835, но по умолчанию этот ключ недоступен из userland. Таким образом, мы должны пропатчить один из драйверов, чтобы получить доступ к этому ключу и иметь возможность перебирать коды блокировки из userland.

Таким образом, порядок загрузки такой: pwnedDFU → iBSS → iBEC → DeviceTree → ramdisk → kernelcache.

Чтобы проделать эту последовательность, потребуются инструменты pwnedDFU (есть только в версии для macOS) и irecovery (macOS и Windows).

Вот последовательность команд, которая приводит к нужному результату:

• pwnedDFU -p — выполняем сам эксплойт checkm8;
• pwnedDFU-f iBSS.n41ap — загружаем iBSS на устройство;
• irecovery -f iBEC.n41ap — загружаем iBEC на устройство;
• irecovery -f DeviceTree.n41ap — загружаем DeviceTree на устройство;
• irecovery -c devicetree — выполняем команду devicetree;
• irecovery -f ramdisk10 — загружаем ramdisk на устройство;
• irecovery -c ramdisk — выполняем команду ramdisk;
• irecovery -f kernelcache.n41ap — загружаем kernelcache на устройство.

В данном примере ramdisk10 и kernelcache.n41ap – пропатченные версии стандартного ramdisk и kernelcache, а iBSS.n41ap и iBEC.n41ap – соответственно, патченные версии iBSS и iBEC.

Иногда на одном из этапов возникает ошибка.

В таких случаях нужно перезагрузить телефон (а иногда – и компьютер; ошибка может возникать из-за проблемы в USB драйвере, которая лечится только перезагрузкой). После этого нужно заново ввести телефон в режим DFU и проделать все шаги снова.

Шаг 6. Монтируем разделы

После того, как мы пропатчили и загрузили все файлы, нужно смонтировать разделы устройства, чтобы иметь доступ к его файловой системе. Системный раздел находится в /dev/disk0s1s1, пользовательский в /dev/disk0s1s2. Нам интересен именно пользовательский, так что монтируем его к /mnt2:

mount -o rw -t hfs /dev/disk0s1s2 /mnt2

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

Следующая команда сохранит содержимое пользовательского раздела в архив tar:

ssh -p 3022 root@localhost tar -c /mnt2 | dd of=<path_to_output_file>

Кстати, если всё, что тебе нужно – это дамп пользовательского раздела, то нет никакой необходимости проделывать все указанные операции вручную: достаточно установить джейлбрейк checkra1n и воспользоваться готовым набором скриптов iPhone-rootFS-tool. Толку с такого дампа, однако, немного: без пароля (а мы, напомню, находимся в режиме хоть и pwned, но DFU) мы не сможем расшифровать пользовательские данные – по крайней мере, большую их часть.

В статье Джеймса Даффи Speed > Security – Apple’s Approach To iOS Data Security рассказывается о том, какие данные с пользовательского раздела доступны без пароля. В список входят:

• список учётных записей электронной почты;
• логины в социальные сети – например, можно найти идентификатор учётной записи SnapChat;
• для некоторых приложений – уникальные идентификаторы чатов и контактов (их в незашифрованном виде хранят, к примеру, всё тот же SnapChat и WhatsApp);
• история доступа к сетям Wi-Fi;
• история сетевой активности приложений (база данных /private/var/wireless/Library/Databases/DataUsage.sqlite);
• сетевые настройки (содержимое /private/var/preferences/);
• сообщения голосовой почты (в папке /private/var/mobile/Library/Voicemail/);
• история данных местоположения (достаточно ограниченная, но всё же);
• частичный доступ к медиафайлам;
• список установленных приложений и краткая информация по истории использования;
• небольшая часть содержимого «Связки ключей»; конкретно – записи с атрибутами kSecAttrAccessibleAlways и kSecAttributeAccessibleAlwaysThisDeviceOnly.

О «Связке ключей» нужно рассказать чуть подробнее. Атрибуты из последнего пункта используются для тех типов записей из «Связки ключей», которые должны быть доступны сразу после загрузки устройства. С одной стороны, это немного: основной массив паролей, сертификатов и ключей становится доступным только после первой разблокировки устройства. С другой - пароли от учётных записей mail.ru и rambler.ru почему-то были сохранены именно с этим классом защиты. Я не могу сказать, какой именно версии приложений были созданы эти записи; попытка воспроизвести ситуацию с последними версиями приложений провалилась. Однако пароли в режиме BFU были найдены.

Набор скриптов SPIDER поможет извлечь из образа незашифрованные файлы и базы данных.

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

Взлом пароля

Итак, мы организовали связь с компьютером и получили среду, позволяющую запускать неподписанные приложения. Теперь нужно запустить непосредственно перебор пароля (кода блокировки экрана). Этим делом занимается утилита passcode нашей собственной разработки, которую мы предварительно загрузили на Ramdisk вместе с другими утилитами командной строки.

Сам пароль как таковой на устройстве не сохраняется ни в открытом, ни в зашифрованном виде. iOS проверяет правильность введённого пароля следующим образом. На основе введённого пользователем PIN-кода формируется так называемый парольный ключ, который используется для расшифровки ключей классов защиты (class keys). Если при помощи введённого пользователем пароля удалось успешно расшифровать все ключи классов защиты, то пароль считается правильным, а соответствующие ключи можно использовать для расшифровки пользовательских данных.

Как уже упоминалось ранее, проверка пароля осуществляется на самом устройстве. При этом разница в производительности между стареньким iPhone 5c и современным iPhone 11 – скорее на порядки, чем в разы. Разработчики Apple постарались сделать так, чтобы разблокировка любого iPhone занимала у пользователя одно и то же время. Количество итераций откалибровано таким образом, чтобы соответствующие ключи расшифровывались за 80 мс. Это и есть максимальная скорость перебора паролей, демонстрируемая утилитой passcode.

Алгоритм проверки пароля выглядит следующим образом. В iOS есть специальная сущность System Keybag, в которой хранятся зашифрованные ключи каждого класса защиты. Сам System Keybag хранится в файле /private/var/keybags/systembag.kb. Этот файл, в свою очередь, зашифрован алгоритмом AES_CBC_256 на ключе BAG1, который хранится в Effaceable Storage.

У расшифрованной «сумки ключей» есть заголовок (header) и список зашифрованных ключей. Из заголовка нам важно получить такую информацию, как тип пароля (0 – PIN из 4 или 6 цифр, 1 - числовой произвольной длины, 2 - символьный произвольной длины), соль и количество итераций.

В процессе перебора мы вычисляем парольный ключ с помощью алгоритма PKDF2_HMAC_SHA1. На входе – очередной вариант пароля, соль и количество итераций из заголовка. Далее мы «растягиваем» вычисленный ключ (key stretching) c помощью аппаратного ключа 0x835, получая таким образом новый ключ на основе ключей 0x835 и passcode key. Наконец, на последнем шаге мы пытаемся полученным ключом расшифровать ключи классов защиты. Если все ключи успешно расшифровались, то пароль считается правильным. Если нет – переходим к следующему варианту.

Скорость работы: пароль из 4 или 6 цифр

Современные версии iOS по умолчанию предлагают защитить устройство паролем из шести цифр. Переключиться на 4-значный PIN можно, но не нужно: благодаря биометрическим датчикам (Touch ID и Face ID) вводить код блокировки тебе потребуется очень редко (как правило, не чаще раза в несколько дней). Соответственно, небольшое неудобство можно и потерпеть в пользу значительно возросшей безопасности.

А вот iPhone 5c биометрическим датчиком не оборудован; код блокировки пользователю приходится вводить каждый раз для доступа к телефону. В результате на этом устройстве по умолчанию предлагается установить четырехзначный PIN. Более того, даже если ты установишь пароль из шести цифр, а потом захочешь его сменить, система вновь предложит тебе ввести пароль из четырех цифр.

Задержка между попытками в 80 мс даёт скорость перебора в 13.6 паролей в секунду. Полностью перебрать все комбинации из 4 цифр можно за 12 минут.

Пароли, состоящие из шести цифр, перебираются с той же скоростью; полный перебор занимает порядка 21 часа, однако реальное время разблокировки может быть значительно меньше. Причина здесь в том, что некоторые пароли встречаются чаще других, и эта статистика нам известна. Чаще всего, как ни странно это звучит, пользователи используют пароли из так называемого «чёрного списка». Если ты попытаешься установить в качестве пароля, скажем, код 000000 или 123456, то система предупредит тебя о потенциальной небезопасности такого пароля – но всё-таки разрешит тебе его использовать. Многие пользователи устанавливают такие пароли по принципу «никто не догадается».

Полный список паролей из «чёрного списка» можно извлечь, проанализировав образ iOS при помощи Malus-Security/iExtractor. Делается это довольно просто; ниже – пример кода, который был использован авторами исследования Extracting iOS’s passcode blacklist (PDF):

VERSION="13.3.1_17D50"

CODENAME="YukonD17D50.D22D221OS"

FILE="dyld_shared_cache_arm64" # or "dyld_shared_cache_armv7s" for iOS 7 to 10.3

hdiutil attach decrypted.dmg

strings /Volumes/$CODENAME/System/Library/Caches/$FILE | \

grep "\bSecPasswordSeparator\b" -A 120 > blacklist_iOS_$VERSION.txt

hdiutil unmount $CODENAME

В процессе атаки инструментарий в первую очередь опробует самые часто используемые пароли (к примеру, 123456, 000000, 343434 и т.п.), во вторую – пароли, в которых может быть закодирована дата (день рождения пользователя или одного из членов семьи – весьма распространённый цифровой пароль). Лишь в том случае, если не сработает ни одна из этих атак, время отработки которых составляет примерно полтора часа, программа включит режим полного перебора.

Буквенно-цифровые пароли

Скорости в 13,6 паролей в секунду достаточно для взлома паролей, состоящих только из цифр (до шести включительно). Сложность же буквенно-цифровых паролей такова, что взломать их за разумное время не представляется возможным. Соответственно, в настоящий момент взламывать буквенно-цифровые пароли мы даже не пытаемся. Но если ты попытаешься это сделать, то рекомендую воспользоваться словарём – например, составленным из известных паролей пользователя.