Эксплоит опубликован на Github

Компания Google начала внедрять полное шифрование диска (Full Disk Encryption, FDE) по умолчанию с версии Android 5.0 Lollipop. В первое время, когда шифрование реализовали в устройствах Nexus 6, многие пользователи жаловались на снижение производительности при чтении и записи данных на накопитель, но с версии Android 6.0 эту проблему вроде бы решили.

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

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

На устройствах iOS 9 этот ключ является производной функцией от пользовательского пароля и уникального 256-битного аппаратного ключа, зашитого в смартфон на заводе. Взломать шифрование такого уровня с помощью брутфорса не может даже ФБР, как известно из недавней истории со смартфоном стрелка из Сан-Бернардино, из-за которого ФБР и Apple дошли до суда. В итоге ФБР всё-таки сумело взломать телефон с помощью неизвестной 0day-уязвимости. Как можно понять из слов главы госструктуры, за обход защиты ФБР пришлось заплатить хакерам более миллиона долларов.


Полное шифрование диска в iOS

Таким образом, брутфорс FDE возможен только с использованием конкретного аппаратного устройства. Это значительно затрудняет проведение атаки. В обычном случае можно было бы создать миллион копий и распараллелить брутфорс в облачном сервисе, что позволяет очень быстро подобрать 99% реальных паролей. Но в данном случае приходится ограничиваться единственным устройством, на котором Apple добавляет ещё и дополнительные помехи — задержки между попытками ввода пароля, ограничение на максимальное количество попыток и т.д. Вот почему для спецслужб исключительно важно найти способ извлечения аппаратного UID, тогда брутфорс пароля становится банальной технической задачей.

Полное шифрование диска в Android 5.0+ реализовано несколько иначе, чем в iOS 9, и подробно описано в блоге Николая Еленкова и в официальной документации Android.

Здесь ключ шифрования тоже является производной функцией от обычно слабого пользовательского пароля, но также от случайным образом сгенерированного 128-битного мастер-ключа (Device Encryption Key — DEK) и случайно сгенерированной 128-битной соли. Поле генерации DEK защищается с помощью тщательно продуманной схемы, в которой используются введённые пользователем значения — пинкод/пароль/паттерн (графический ключ) для входа. Затем зашифрованный DEK помещается в специальное зашифрованное хранилище под названием crypto footer. Все эти уровни шифрования нужно преодолеть, прежде чем расшифровать DEK, а затем любую информацию, записанную на накопителе.



Как и в случае с iOS 9, в операционной системе Android реализована привязка схемы шифрования к конкретному аппаратному обеспечению, чтобы не допустить брутфорса на копиях операционной системы. Функцию аппаратной привязки выполняет специальное аппаратное хранилище — KeyMaster, которое работает в особом окружении Trusted Execution Environment (TEE), полностью независимом от операционной системы Android. Защищённость ключей в окружении KeyMaster имеет важнейшее значение. Только это защищает систему полного шифрования диска от проведения эффективного брутфорса в параллельных потоках на копиях ОС.

В устройствах Android изолированное окружение никогда не выдаёт свой собственный ключ наружу в «небезопасную» среду. Наоборот, модуль KeyMaster получает из небезопасной среды «блоб ключа» (key blob), расшифровывает хранящийся там ключ — и отдаёт его обратно. Другими словами, работа системы шифрования возможна только непосредственно на аппаратном устройстве, но не в виртуальной среде на другом компьютере.

В общем весь процесс схематично можно изобразить на такой диаграмме, которую приводит Николай Еленков.



Защиту окружения KeyMaster и выполнение команд на выделенном безопасном процессоре обеспечивает защищённая среда, предоставленная производителем оборудования. В Случае с Qualcomm это среда QSEE (Qualcomm Secure Execution Environment). Она допускает к исполнению на выделенном процессоре только отдельные маленькие приложения, которые называются «трастлеты» (trustlets). Один из таких трастлетов — KeyMaster. В исходном коде Android есть инструкции для обращения к приложению KeyMaster. На самом деле трастлет поддерживает всего четыре инструкции:

 * Commands supported
 */
enum  keymaster_cmd_t {
    /*
     * List the commands supportedin by the hardware.
     */
    KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
    KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
    KEYMASTER_SIGN_DATA = 0x00000003,
    KEYMASTER_VERIFY_DATA = 0x00000004,
};

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

И вот теперь мы подошли именно к тому этапу, на котором действует новый эксплоит, который появился в открытом доступе 30 июня (репозиторий на Github). Эксплоит использует недавно найденные уязвимости CVE-2015-6639 и CVE-2016-2431.

Автор эксплоита, специалист по безопасности Гал Беньямини (Gal Beniamini) написал поддельную версию приложения QSEE и с помощью вышеупомянутых уязвимостей сумел загрузить её в защищённое окружение, тем самым осуществив повышение полномочий и взломав защиту окружения QSEE, которое участвует в процессе генерации ключа для шифрования диска.

Таким образом, гипотетический злоумышленник может «подделать» аппаратную составляющую ключа шифрования и осуществить брутфорс остальных компонентов, обойдя защиту Android на количество повторных попыток. Остаётся только подобрать перебором пользовательский пинкод/пароль.

Кстати говоря, для того редкого случая, когда пользователь установил для шифрования по-настоящему сложный пароль с высокой энтропией и его не удаётся подобрать брутфорсом за приемлемое время, есть запасной план. Если взломать шифрование действительно крайне необходимо, то можно найти точно такой же телефон, той же модели, с такими же царапинами и защитным корпусом — и запрограммировать его на отправку пароля, как только жертва введёт его. Этот поддельный аппарат подкладывается жертве вместо оригинального. Чтобы избежать раскрытия и одновременно устранить риск введения жертвой неправильного пароля с первой попытки, телефон должен быть запрограммирован на то, что никакой введённый пароль он не принимает как правильный.

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

Есть интересный момент. Защищённую среду на мобильных устройствах устанавливает не сама компания Qualcomm, а OEM-производители. Они могут сотрудничать с правоохранительными органами той страны, в юрисдикции которой находятся, и выполнять требования судебных запросов. Соответственно, если подобная криптографическая схема будет реализована российским производителем, то информация на смартфоне будет рассекречена по запросу российского суда.

И ещё один интересный момент. Несмотря на то, что Гал Беньямини несколько месяцев обсуждал данные уязвимости с Qualcomm и Google, исправить их не так просто — здесь недостаточно программного апгрейда (для двух уязвимостей патчи для Android вышли в январе и мае), а может понадобиться аппаратный апгрейд. Дело в том, что если злоумышленник получит устройство, то теоретически может откатить программный апгрейд, вернуть аппарат на уязвимую версию и провести атаку.

Как уже говорилось выше, код эксплоита опубликован на Github. Вот схема его работы.



Гал Беньямини написал несколько скриптов на Python, которые упрощают брутфорс после срабатывания эксплоита. В комментариях к его блогозаписи коллеги выразили желание помочь в портировании скрипта на мощнейшую платформу для брутфорса hashcat/oclHashcat.

Беньямини предполагает, что компания Google вместе с OEM-сборщиками выработают новую абсолютно надёжную схему аппаратно-программного шифрования, которую даже теоретически невозможно будет взломать.

Будем надеется, что такую схему реализуют на новом поколении Android-устройств.