Смартфоны и планшеты постоянно обрабатывают и хранят огромное количество самой разной конфиденциальной информации. Работа с важными данными всё сильнее полагается на использование мобильных устройств. Находятся ли личные и коммерчески важные данные в безопасности? Кто и как может получить доступ к личной информации? Проведём подробный сравнительный анализ современной безопасности пользовательских данных на Apple iOS и Google Android.
- Введение
- Общие принципы безопасности и конфиденциальные данные мобильных устройств
- Apple iOS
- Google Android
- Выводы
Введение
На текущий момент мировой рынок операционных систем для мобильных устройств с большим отрывом возглавляют двое лидеров: Google Android и Apple iOS.
Рисунок 1. Доля мобильных платформ в мире согласно statcounter.com
В процессе эволюции обе платформы сформировали свои подходы к организации безопасности данных пользователя. Каждая имеет свои преимущества и недостатки. Закрытая среда разработки iOS и оперативное реагирование на уязвимости создают доверие к Apple. Но до сих пор Apple полностью не защищает пользователей от взлома и компрометации данных по различным каналам.
Google за последние несколько лет значительно повысила безопасность ОС Android за счёт внедрения криптографической функциональности. Но специалисты по киберкриминалистике (форензике) всё ещё могут обойти защитные механизмы Android и получить доступ к данным.
Рассмотрим детальнее каждую из операционных систем, разберём методы защиты, обозначим сильные и слабые стороны безопасности. В итоге сформируем рекомендации как для пользователей, так и для разработчиков по обеим платформам. Анализ подготовлен на базе публикации исследования securephones.io от 11 января 2021 г.
Общие принципы безопасности и конфиденциальные данные мобильных устройств
Практически все данные пользователя мобильных устройств конфиденциальны: электронная почта, сообщения, биометрическая информация, фото- и видеоконтент, документы, местоположение, пароли, история работы в браузере и многое другое. Какие именно данные наиболее конфиденциальны и какие техники защиты используются на данный момент? Также обозначим общую модель угроз.
Техники защиты данных
Можно выделить несколько ключевых техник контроля доступа к данным.
Безопасность и изоляция ПО. Современные операционные системы мобильных устройств строго разграничивают доступ приложений и доступ пользователя. Например, подозрительные приложения не могут получить доступ к данным, на которые не имеют соответствующих прав. Для запуска произвольного кода на устройстве необходимо произвести обход данного ограничения: «джейлбрейк» для iOS или получение рут-доступа для Android.
Доступ посредством кодов и биометрии. Контроль доступа к интерфейсу ОС зачастую осуществляется через пароль произвольной силы, как правило, цифровой. Можно активировать паттерн (графический ключ — последовательность) на экране блокировки. Всё чаще применяется биометрический доступ: посредством распознавания лица или отпечатка пальца.
Шифрование файлов и дисков. В случае обхода злоумышленником программных методов защиты он столкнётся с зашифрованными данными. Это могут быть как отдельные файлы, так и разделы диска. Шифрование данных, как правило, организовано асимметрично: в оборудование встроена одна часть ключа, а вторая генерируется на основе выбранного пользователем пароля.
Безопасное аппаратное обеспечение устройств. Последнее время производители внедряют сопроцессоры безопасности и их виртуализированные аналоги. Это защищает от программных атак и от атак на оборудование устройства, усиливая механизмы шифрования конфиденциальных данных, в частности биометрических шаблонов.
Безопасное резервное копирование и работа с облачными системами. С недавнего времени поставщики услуг предоставляют безопасную модель облачного хранения резервных копий данных устройства. Современная система зашифрованного резервного копирования исключает прямой доступ облачного провайдера, злоумышленников или правоохранительных органов к данным пользователя.
Модель угроз
В настоящее время мобильные устройства вполне хорошо защищены от традиционных дистанционных атак. Однако прямой длительный физический доступ к устройству (или его компонентам) значительно облегчает работу злоумышленника или специалиста по форензике, что повышает риск извлечения данных.
Прямой доступ к устройству может быть получен незаконно, путём кражи устройства, или законно, путём исполнения законодательных предписаний, которые могут включать выдачу паролей доступа. Это — очень тонкий момент, потому как органы власти могут воспользоваться своим служебным положением или же невежеством пользователя, что может привести к полной компрометации устройства. Нельзя исключать и того, что злоумышленник совершит атаку методами социальной инженерии, выдавая себя, например, за того же представителя правоохранительных органов, или подделает судебные документы, получив в итоге доступ к мобильному устройству.
Физический доступ к устройству с применением инструментов киберкриминалистики позволяет не только извлечь данные, но и получить токены доступа к безопасному облачному хранилищу, находящиеся в памяти. Данные из устройства и из облачного хранилища, как по отдельности, так и вместе, могут содержать разные категории личной информации, создавая серьёзную угрозу нарушения конфиденциальности пользователя.
Конфиденциальные данные мобильных устройств
Специалисты по форензике извлекают наиболее приоритетные категории конфиденциальных данных для поимки преступников. Эти данные мы можем взять за основу:
- IMEI, MEID / ESN и прочие данные абонента сотовой сети;
- контакты, адресная книга, календарь, заметки и т. д.;
- журналы входящих и исходящих вызовов;
- SMS, MMS, мгновенные сообщения;
- файлы: аудио, видео, документы;
- электронная почта;
- активность браузера: история, закладки;
- GPS и геолокационные данные;
- социальные сети: аккаунты, контент;
- SIM / UICC, провайдер, IMSI, MSISDN и т. д.
Необходимо отметить, что этот список данных не отражает обязательную угрозу конфиденциальности пользователя. Некоторые данные могут иметь короткий срок актуальности, а некоторые несут информацию о наших родственниках, друзьях, коллегах. В эру повсеместного интернета и возрастающей мощности машинного обучения утечка даже некоторых данных из списка может привести к нарушению конфиденциальности целой группы пользователей.
Apple iOS
В 2020 году корпорация Apple заявила, что количество активных устройств по всему миру составляет более 1 400 000 000. 48 % смартфонов в США и западных странах — iPhone под управлением iOS. Постепенный рост количества устройств Apple на мировом рынке привлекает не только злоумышленников, но и специалистов по поиску уязвимостей (багхантеров), которым корпорация предлагает программы вознаграждения до 2 000 000 долларов США.
В ограничения ОС и приложений, работающих на устройствах Apple, корпорация вкладывает большие средства. Высокая ценность эксплойтов и централизованное реагирование на инциденты создают классическую борьбу между щитом и мечом. Рассмотрим текущие технические аспекты защиты информации пользователей Apple, но сначала оглянемся в прошлое и вспомним историю функций безопасности iOS.
Обзор эволюции защиты Apple iOS
Шифрование данных. Первая версия шифрования данных флеш-памяти при отключении питания была реализована в iOS 3 (2009 год). Ключ шифрования не зависел от кода доступа пользователя и не требовался для дешифровки.
В iOS 8 (2014 год) Apple значительно увеличила количество зашифрованных данных на устройстве с использованием ключа, который генерировался на основе пароля пользователя. С функцией Data Protection удаление данных происходит вместе с ключами без возможности восстановления. Однако в некоторых случаях удаление данных пользователем происходит посредством их переноса в соответствующий раздел базы данных SQL на устройстве, что сохраняет возможность последующего восстановления.
От кодов к биометрии. TouchID появился в 2013 году, а в iOS 9 (2015) была увеличена стандартная длина цифрового пароля — до шести символов. До этого пароли, состоявшие из четырёх символов, могли быть обойдены программными эксплойтами. Ёмкостный датчик отпечатков пальцев и последующий FaceID (2017), по мнению Apple, повысили и упростили безопасность, так как частота, с которой обрабатываются биометрические данные, ограничена SEP (Secure Enclave Processor). Эффективность данных нововведений подвергалась сомнению в научных кругах.
SEP-архитектура и усиление аппаратных компонентов устройств. С эволюцией iOS менялись аппаратные компоненты устройств Apple. До введения чипа A4 (собственная однокристальная разработка SoC) Apple использовала компоненты от Samsung, LG и прочих производителей (2007–2009 годы). Безопасность строилась на шифровании загрузочной памяти NOR с помощью аппаратного ключа AES (ключа UID), который управлялся ускорителем Crypto Engine.
Архитектура SEP (Secure Enclave Processor) была впервые реализована в чипе A7 (iPhone 5S, 2013) и позволила выполнять функции безопасности отдельно от основного процессора, на котором работают ОС и приложения. Активируя TouchID, SEP использует собственный ключ UID для шифрования. Особенность заключается в том, что при генерации ключа SEP даже производители не знают ключ UID. Начиная с чипа A7 происходит последовательное усиление безопасности и производительности, расширение функций SEP. Например, в чипе A12 (2020 год) Apple установила защиту на режим обновления прошивки устройства (DFU mode), как это реализовано в режиме восстановления (recovery mode).
iCloud Keychain. В 2016 анонсирован iCloud Keychain, а в iOS 11 (2017) представлен CloudKit с последующим API для сторонних разработчиков. Преимущество состоит здесь в том, что хранение контейнера произвольных данных в облаке организовано особым образом: никто кроме пользователя со своим Keychain, даже сама Apple, не может дешифровать эти данные.
Современная защита данных пользователя iOS
Ключевые элементы защиты сформированы взаимодействиями непосредственно с устройством и с облачными технологиями.
Аутентификация
Физическое взаимодействие с устройством: цифровой / буквенный код или биометрическая аутентификация. 6-символьный пароль активирован по умолчанию. Поддерживается выбор более длинных парольных буквенно-цифровых фраз. Возможно полное отключение аутентификации, что крайне не рекомендуется Apple. Попытки перебора цифровых паролей блокируются временными интервалами. TouchID (ёмкостный датчик отпечатка пальца) и FaceID (распознавание лица камерой, чувствительной к глубине) применяются Apple для организации более высокого уровня безопасности пользователей.
Подписывание кода приложений
Цифровые подписи помогают серьёзно ограничивать исполняемый код на iOS. Это достигается за счёт безопасной загрузки (происходит проверка подписи, встроенной на низком уровне (Boot ROM), что гарантирует долгосрочную защиту от инициализации подозрительного софта) и за счёт подписи приложения, представляющей собой следующую комбинацию: подпись, которая контролируется Apple, и сертификаты с открытым ключом для масштабирования системы. Для более специализированного запуска приложений на iOS в рамках организации необходимо приобрести так называемые «сертификаты подписи предприятия».
Песочница и анализ кода
Для защиты от подозрительных приложений накладываются ограничения доступа к пользовательским данным и API посредством изолированной среды (песочницы). Приложению ограничивается доступ к файловой системе, пространству памяти. В подписанном манифесте обозначается разрешённый доступ к системным ресурсам и службам, например службе геолокации. Приложения из App Store проходят автоматическую и ручную проверку кода. Впрочем, даже при этих строгих ограничениях некоторые нежелательные приложения могут пройти проверку и нарушить конфиденциальность пользователя.
Шифрование
На тот случай, если злоумышленнику удастся обойти механизмы безопасности через логические уязвимости или недостатки в оборудовании, Apple подготовила надёжную систему шифрования данных устройства — Data Protection. iOS применяет криптографические стандарты AES, ECDH over Curve25519 и прочие одобренные Национальным институтом стандартов и технологий США (NIST). Доступ к данным привязан к устройству и контролируется пользователем. Ключ для шифрования данных формируется на основе комбинации выбранного пользователем пароля и UID (уникальный аппаратный секретный криптоключ). После перезагрузки устройства требуется восстановить ключи шифрования путём ввода установленного ранее пароля, далее для разблокировки ключей достаточно биометрических данных.
Обход шифрования пресекается двумя путями: функцией получения ключа на основе пароля и методом ограничения предположений с увеличением временных интервалов.
Apple использует несколько «классов защиты» (Class key) шифрования, которые разработчики вольны выбирать при создании файлов или объектов данных:
- Полная защита (CP) — через 10 секунд после блокировки устройства ключи шифрования удаляются.
- Защищено пока не открыто (PUO) — сохраняется эфемерный открытый ключ в памяти, передача зашифрованных файлов при заблокированном устройстве. Включается полная защита данных (CP) после того, как файл был создан и закрыт.
- Защищено до первой аутентификации пользователя — первой разблокировки (AFU) — при вводе первого пароля ключи шифрования расшифровываются в памяти и остаются там при блокировке устройства.
- Нет защиты (NP) — при выключенном устройстве ключи шифрования зашифрованы только аппаратными ключами UID. Эти ключи постоянно доступны в памяти, когда устройство включено.
Рисунок 2. Схема иерархии ключей iOS Data Protection
Keychain
Это — зашифрованное хранилище ключей и конфиденциальной информации (логины / пароли), которое имеет общедоступный API. Оно защищено аппаратными ключами и паролем пользователя. Опция Non-Migratory (NM) позволяет дешифровать данные только на том устройстве, где данные были зашифрованы (применяется UID).
Резервное копирование
Возможно выполнить локально на персональный компьютер или в iCloud. Локальный бэкап можно зашифровать выбранным паролем, в результате сформируется структура Keybag. Ненадёжный пароль будет иметь слабую устойчивость к перебору вариантов (брутфорсу), поскольку никак не связан с аппаратными ключами устройства. Здесь iOS использует 10 миллионов итераций PBKDF2 для повышения устойчивости к перебору. При копировании в Apple iCloud данные шифруются Curve25519, что позволяет делать бэкап, когда устройство заблокировано, без раскрытия секретных ключей. Вследствие того что ключи зашифрованы с помощью iCloud Keychain, известных Apple, производитель или злоумышленник может получить доступ к содержимому резервной копии. Поэтому Keychain дополнительно шифрует оба типа резервной копии ключом UID для предотвращения восстановления на новом устройстве.
Данные, содержащиеся в резервной копии iCloud: данные приложений, резервные копии Apple Watch, настройки устройства, домашний экран и приложения, iMessage, SMS и MMS, фото и видео, история покупок в сервисах Apple, рингтоны, пароль голосовой почты.
iCloud и iCloud Keychain
iCloud позволяет хранить не только бэкапы, но и любые другие данные пользователя, указанные для синхронизации с облаком. Данные передаются по сети с помощью TLS и хранятся в зашифрованном виде. Криптографическое преобразование осуществляется с помощью 128-битного ключа AES и ключа полученного из пароля пользователя.
iCloud Keychain позволяет синхронизировать (с использованием асимметричного шифрования) Keychain между устройствами Apple, а в случае утраты устройства — восстановить Keychain посредством кода безопасности iCloud. Этот код формируется из пароля пользователя при включенной двухфакторной аутентификации или же создаётся автоматически, если та не включена. Применяя технологию HSM (надёжных аппаратных модулей), Apple не имеет доступа к содержимому резервных копий iCloud Keychain, а при HSM-аутентификации код безопасности iCloud не передаётся (используется протокол безопасного удалённого пароля SRP). Копия зашифрованной iCloud Keychain отправляется на устройство пользователя только после подтверждения, что число неудачных попыток было меньше 10. Если было зафиксировано больше 10 попыток, то запись уничтожается и пользователю понадобится зарегистрироваться повторно для использования iCloud Keychain. Apple утверждает, что после развёртывания HSM ключи подписи, необходимые для изменения ПО, уничтожаются автоматически, что ограничивает корпорации доступ к данным пользователей.
SEP: TouchID и FaceID
Secure Enclave Processor (SEP) — сопроцессор, использующий зашифрованную память и организующий работу по аутентификации, управлению ключами, шифрованию и генерации случайных чисел. Если ядро iOS было взломано, то SEP обеспечивает шифрование за счёт своей автономной архитектуры.
Рисунок 3. Схема обработки ключа Secure Enclave Processor
Работа аутентификации TouchID / FaceID согласуется посредством SEP.
Рисунок 4. Схема работы Apple TouchID и FaceID
Уменьшение фронта атаки
Это достигается ограничениями путей ввода-вывода данных для заблокированного устройства. Для доставки эксплойта на устройство Apple потребуется один из этих путей: синхронизация данных в фоновом режиме (электронная почта, облачные сервисы), пуш-уведомления, некоторые сетевые уведомления (Wi-Fi, Bluetooth, сотовая связь) и порт Lightning на устройстве.
С введением USB Restricted операционная система iOS ограничивает доступ подозрительных подключений посредством USB/Lightning, например инструментов форензики. iOS останавливает работу USB после первого подключения, если устройство не было принято пользователем как доверенное. Известные доверенные подключения через USB/Lightning запоминаются на 30 дней.
iMessage и FaceTime
Apple поддерживает сквозное (end-to-end) шифрование при видео- / аудиосвязи между своими устройствами посредством FaceTime. В основе лежит SRTP (безопасный транспортный протокол в режиме реального времени). iMessage применяет схему шифрования «signcryption». Для публичных ключей используется Apple Identity Service — как доверенный орган, обеспечивающий подлинность пользователей.
Актуальные техники обхода защиты пользовательских данных iOS
Выход нового устройства Apple на рынок сопровождается улучшениями безопасности, что привлекает злоумышленников, специалистов по киберкриминалистике и багхантеров, которые могут получить шестизначные суммы за обнаружение уязвимостей. Рассмотрим основные современные техники обхода защиты для iOS.
Джейлбрейк и программные эксплойты
Джейлбрейк часто используется для снятия ограничений iOS и выпускается для конкретного устройства и версии iOS. Многие инструменты форензики используют его для доставки «полезной нагрузки» в уязвимый программный компонент, как правило, через USB/Lightning. Доставка может быть осуществлена через сообщения или посредством специально подготовленных веб-страниц. Нередко используется цепочка эксплойтов. Когда контроль над ядром iOS получен, можно извлечь данные, которые не были зашифрованы. Последующая модификация (патчинг) программного ядра позволяет запускать любой код в системе.
Apple весьма быстро реагирует на уязвимости, которые приводят к джейлбрейку, что держит цену актуальных рабочих вариантов очень высокой.
Джейлбрейки checkm8 / checkra1n наиболее эффективны в 2020 году с точки зрения киберкриминалистических исследований и позволяют работать с устройствами до iPhone X и любой версией iOS.
Эксплойты Cellebrite UFED Touch и 4PC позволяют запускать резервное копирование без авторизации пользователя или активировать загрузчик с кодом Cellebrite для извлечения частей файловой системы устройства.
Подбор пароля
Пароль доступа к устройству необходим для получения ключей дешифрования информации классов CP и AFU.
До введения архитектуры SEP ограничения на угадывание и проверка пароля контролировались процессором устройства, что позволяло проводить разные успешные атаки, которые заключались в сбросе счётчика неверно введённых паролей.
На более ранних версиях iOS можно было отключить питание устройства для сброса счётчика, а в 2016 году была продемонстрирована техника с возможностью зеркалирования флеш-памяти NVRAM на iPhone 5C для обеспечения неограниченного числа ввода паролей.
Ограничение на подбор в 80 мс делает атаки перебором бессмысленными для сложных паролей с буквами и цифрами. Для PIN-кода из 6 цифр, который используется по умолчанию, ограничения SEP на угадывание представляют собой основное препятствие.
Таблица 1. Оценка времени перебора цифровых паролей в iOS
| Длина пароля | 4 цифры | 6 цифр | 10 цифр |
| Всего вариантов | 10^4 = 10 000 | 10^6 = 1 000 000 | 10^10 |
| Всего используется | 9276 | 997090 | - |
| 80 мс/попытка ожидание | 12,37 минуты 6,19 минуты |
22,16 часа 11,08 часа |
∼25 лет |
| 10 мин./попытка ожидание | ∼70 дней ∼35 дней |
∼20 лет ∼10 лет |
∼200 000 лет |
Взлом SEP
Для взаимодействия с SEP необходимы привилегии ядра. Джейлбрейк, вероятно, необходим в цепочке для взлома SEP. При успешной атаке на SEP злоумышленник или специалист по киберкриминалистике получает неограниченный доступ к ключам шифрования и прочим функциям защиты устройства с возможностью полностью извлечь любые файлы.
В 2018 году компания Grayshift представила инструмент GrayKey, который, по неподтверждённым данным, мог обходить ограничения SEP. Был представлен ряд утечек, например успешный взлом пароля блокировки экрана iPhone X этим же инструментом. В январе 2020 г. появилась утечка из ФБР, где говорилось, что GrayKey получил доступ к заблокированному iPhone 11 Pro Max (iOS 13), который неуязвим для checkm8, что оставляет много вопросов: было ли это рабочим эксплойтом или же компрометацией непосредственно SEP?
Обход блокировки экрана
Пользователи устройств могут случайно обнаружить в интерфейсе iOS поведение, которое позволяет обойти блокировку экрана. Например, это может быть поведение при доступе к камере, виджету погоды или часов. Для воспроизведения успешного обхода требуется аккуратность и последовательность действий. Обход блокировки может открыть несанкционированный доступ к фотографиям, контактам, iTunes. Как правило, Apple быстро закрывает подобные пути обхода.
Локальное извлечение данных
Стратегия извлечения данных зависит от того, в каком состоянии было устройство на момент захвата: выключено или включено. При конфискации мобильных устройств Apple сотрудники правоохранительных органов разных стран нередко забирают на анализ и смежные устройства, например MacBook или Apple TV, используют клетку Фарадея и автономный источник питания для предотвращения выключения устройства.
При компрометации iOS злоумышленником последним уровнем защиты данных будет шифрование, организованное Data Protection. Поэтому текущие методы извлечения данных без согласия (или при недоступности) пользователя могут происходить по одному из трёх направлений, перечисленных далее.
- Доступ к устройству с помощью ключей. Если ключи шифрования загружены в память, их можно извлечь. Например, инструменты форензики Cellebrite UFED и XRY Logical позволяют подключаться к устройствам iOS через порт USB/Lightning или через Bluetooth, инициировать резервное копирование или просмотреть файлы.
- Обход защитных механизмов. В некоторых случаях данные, недоступные для извлечения, могут быть извлечены. Инструмент GrayKey, успешно получивший коды доступа пользователей, служит тому примером. Если устройство находится в состоянии AFU (и даже BFU), то открыта возможность высокочастотной атаки перебором пароля пользователя. Успешная атака позволит извлечь всю файловую систему iOS, Keychain и содержимое iCloud.
- Альтернативные источники данных. Здесь применяется атака на резервную копию iOS, которая хранится на локальном компьютере и имеет сравнительно слабую защиту от брутфорса. Также используется возможность извлечения данных пользователя из облачных сервисов.
Извлечение данных из облака
Всё больше и больше данных мобильных устройств синхронизируется с облачными сервисами, что смещает акцент в сторону извлечения данных не из устройства, а из облака. Компрометация SEP может позволить извлечь Keychain, который откроет доступ к службам iCloud, Slack, Twitter, Instagram, Facebook, Google, Uber, Dropbox. Вероятно, данные токены хранятся в режиме AFU, чтобы поддерживать функционирование при блокировке устройства, но это открывает дополнительные риски, снижая защиту SEP, так что здесь приходится полагаться только на безопасность ядра iOS.
Конфискация смежных устройств Apple (MacBook, Apple TV) может помочь получить данные для аутентификации в iCloud в сочетании с другими методами форензики.
Как можно было бы повысить защиту iOS
Усиление защиты данных. Apple разработала качественный фреймворк для защиты данных пользователя, но пока что Data Protection не используется в максимально строгом режиме. Например, токены аутентификации для облачных сервисов подвержены риску извлечения из памяти. Класс защиты в состоянии AFU вполне надёжен, но требуется более тщательная организация его работы.
Динамическая защита данных. Может быть реализована при взаимодействии с пользователем на основе алгоритмов обучения в сочетании с усилением защиты до класса CP. iOS прогнозирует, какие ключи должны применяться и когда, своевременно удаляя из памяти неактуальные ключи шифрования и загружая актуальные по мере необходимости.
Сквозное шифрование бэкапов и iCloud. Apple хранит ключи, которые могут дешифровать данные бэкапов в iCloud. Используя iCloud Keychain, можно качественно организовать сквозное резервное копирование, недоступное для Apple, но доступное для любого доверенного устройства пользователя. Это же можно применить и для контейнера CloudKit, что значительно повысит безопасность хранения данных пользователя в облаке.
Ликвидация особых случаев обхода шифрования. Ключ сквозного шифрования iMessage хранится в резервной копии iCloud, к которой Apple имеет доступ. Данную лазейку следует устранить путём переноса ключа в контейнер CloudKit с применением сценария «end-to-end».
Пароли на локальные бэкапы. Рекомендуется повышение сложности паролей локальных бэкапов для защиты от перебора. Можно реализовать это путём оптимизации интерфейса или обучения пользователей.
Усиление iCloud Keychain. Слабое место — кластер HSM, потому как нет прозрачности шифрования со стороны сервера. Здесь Apple может применить технологию Certificate Transparency, при которой узлы проверяют адреса и корректность HSM, публично транслируют информацию или делятся ею между собой.
Ограничения на USB-интерфейс. Более строгие ограничения при управлении USB/Lightning на уровне ядра iOS могут усилить безопасность и предотвращать работу эксплойтов, например checkm8.
Ограничения на режимы DFU и JTAG. Пользователи могут в любой момент перевести своё устройство в режим DFU, и эксплойты потенциально способны использовать эту лазейку. Здесь можно организовать аутентификацию с применением криптографии.
Аналогичные рекомендации можно применить к режиму JTAG, который, как правило, большинству пользователей нет необходимости использовать.
Прозрачность и функциональные противоречия. Противоречия в подходе Apple к вопросу защиты данных пользователя следует устранить. Например, включая / выключая опцию синхронизации данных с iCloud, пользователь сталкивается с запутанной политикой, с риском утечки данных. Это же относится и к интерфейсу, к настройкам и управлению iCloud по умолчанию.
Влияние iOS-сообществ. Огромное количество пользователей и популярность iOS создают базу любителей и исследователей разного уровня. Взаимодействие с этими сообществами (не только на уровне багхантинга), например посредством открытого исходного кода, поможет не только усилить безопасность iOS, но и услышать потребности пользователей, привнести инновации.
Google Android
Доля мирового рынка мобильных устройств под управлением системы Android огромна. Android, или Android Open Source Project (AOSP), — это набор программного обеспечения с открытым исходным кодом, разработанного Open Handset Alliance под покровительством Google. Мобильные сервисы Google (GMS), включающие в себя проприетарные API и программные сервисы, значительно расширяют и усложняют экосистему Android.
Будучи основанной на базе Linux, Android имеет все преимущества и недостатки безопасности данной операционной системы. Уязвимости мобильных устройств под управлением Android всегда остро ощущаются во всём мире в силу большой популярности и распространённости. Рассмотрим, как именно организована защита пользовательских данных в Android, но сначала, как и раньше, оглянемся в прошлое.
Обзор эволюции защиты Android
Изолированная среда приложения. С первых версий файловое хранилище Android разделено на внутреннее (встроенное в устройство) и внешнее (SD Card). Именно внутреннее хранилище находится под особым контролем операционной системы; там приложение изолируется в песочнице, получая доступ только к своей собственной части хранилища.
В Android 4.3 был добавлен SELinux (Security Enhanced Linux), который был активен для критических системных функций, а начиная с Android 5.0 механизмы безопасности SELinux применялись уже ко всей системе. Последующее развитие привело к тому, что в Android 9.0 каждое приложение работает в отдельной «песочнице» SELinux.
Надо отметить, что начиная с Android 7.0 более строгие ограничения вводятся и на внешнее хранилище данных (SD Card).
Шифрование данных. Первые версии не применяли никаких методов шифрования для защиты данных пользователя. В Android 4.4 введена опция шифрования всего диска, а с Android 5.0 шифрование диска стало стандартом по умолчанию. Последующая эволюция Android оптимизировала работу с шифрованием, добившись комбинации из шифрования метаданных (интегрирована в Android 9.0) и шифрования на основе файлов (Android 7.0), что позволяет устройству безопасно выполнять критически важные системные функции без разблокировки телефона.
Контроль целостности. Происходит посредством проверки загрузочного кода и файлов APK (Android Package).
Проверка загрузочного кода в разделе осуществлялась модулем «dm-verity» и была введена в Android 4.4. Если целостность данных была нарушена, пользователь получает предупреждение, но загрузка ОС продолжается. В Android 8.0 представлена новая версия загрузчика Android Verified Boot (AVB).
Проверка установки APK-файлов из источников отличных от доверенных (Google Play) добавлена в Android 2.1. В Android 7.0 введена система подписи приложения, специфичная для APK.
В 2021 году Google требует, чтобы приложения при публикации в Google Play использовали App Bundles. Окончательную сборку и подписывание APK перед публикацией в Google Play осуществляет непосредственно Google, что вызывает протесты и недовольство многих разработчиков.
Надёжность аппаратного обеспечения. Android не требует использования специального оборудования согласно спецификациям от Open Handset Alliance. Android 4.1 вводит механизм Keymaster Hardware Abstraction Layer (HAL) для хранения ключей на уровне аппаратной абстракции. Keymaster TA выполняет операции подписи и проверки приложений. В Android 6.0 добавлены AES и HMAC, а также контроль за использованием ключей шифрования.
Введение дополнительного аппаратного модуля безопасности (secure element), аналогичного SEP в iOS, стало обычным явлением в последние годы. Это — криптографический модуль, существующий отдельно от основного процессора и предназначенный для работы исключительно с секретными данными пользователя. В Android 9 добавлена функциональность StrongBox Keymaster, которая расширяет возможности Keymaster TA в целях осуществления криптографических операций на главном процессоре устройства.
Современная защита данных пользователя Android
Аутентификация
Цифровой код, буквенно-цифровая фраза или паттерн (графический ключ-узор). По некоторым исследованиям, паттерн-аутентификация эквивалентна по силе цифровому паролю из двух или трёх цифр. Также поддерживается биометрическая аутентификация по отпечатку пальца или лицу пользователя, что применяется производителями устройств по желанию, потому как не требуется для Android в обязательном порядке.
Поддерживается опция Smart Lock, когда система использует информацию об окружении для разблокировки (например, когда телефон находится дома или в кармане).
Песочница для приложений
Используется дискреционный контроль доступа (DAC) и SELinux. Файлы приложения в системе имеют разрешения основанные на идентификаторах пользователей Linux, поэтому попытка доступа приложения не к своим файлам вызывает ошибку. Дополнительный уровень изоляции обеспечивает SELinux. Политики SELinux позволяют осуществлять контроль привилегий приложений более строго. Обязательный контроль доступа (MAC) гарантирует, что если процесс запущен с правами суперпользователя (root), это не приведёт к полной компрометации системы.
Шифрование
Разделяется в Android на два вида: полное шифрование диска и файловое шифрование.
Полное шифрование диска (появилось в Android 4.4) базируется на модуле «dm-crypt» ядра Linux. Применяется алгоритм AES-128 в режиме CBC с ESSIV. Мастер-ключ шифруется ключом, который создаётся из пароля пользователя (цифровой код, фраза, паттерн). Мастер-ключ должен быть доступен при загрузке ОС, чтобы была возможность активировать основные функции системы. После аутентификации пользователя мастер-ключ хранится в памяти устройства всегда, так как он необходим для всех операций блокирования доступа к разделу с данными.
Файловое шифрование обеспечивает более гранулированный контроль. Модуль «fscrypt» ядра Linux использует алгоритм AES-256 в режиме XTS для файлов и CBC для метаданных файлов. Зашифрованные файлы в свою очередь разделяются на две категории: Credential Encrypted (CE) и Device Encrypted (DE). Данные CE зашифрованы с использованием ключа, полученного из пользовательского пароля, поэтому доступ к ним открывается только после разблокировки устройства. Данные DE базируются на секретах непосредственно устройства и доступны как при загрузке, так и после разблокировки. По умолчанию для всех приложений применяется CE, а DE зарезервирован для определённых системных приложений (вызовы, часы, клавиатура и т. д.).
Сочетание шифрования на основе файлов с шифрованием метаданных позволяет Android осуществить защиту всего содержимого на устройстве. Однако злоумышленник, которому удалось получить доступ к памяти устройства (например, применив эксплойт для компрометации ядра системы), может получить прямой доступ к мастер-ключу и зашифрованным данным.
Съёмный носитель данных (SD-карта)
Удобная функция расширения памяти устройства обеспечивается поддержкой SD-карт. В Android 6 представлена опция адаптируемого хранилища, когда система может интегрировать SD-карту как часть своего внутреннего хранилища, применять там шифрование и управлять доступом. С другой стороны, эта опция привязывает SD-карту к одному устройству, так как ключи шифрования хранятся непосредственно на последнем.
Аппаратные элементы безопасности
Безопасность в современных устройствах под управлением Android реализуется и аппаратными методами. Устройства с архитектурой ARM применяют механизм ARM TrustZone. В отличие от Apple SEP, TrustZone использует один процессор, а не отдельный сопроцессор, что никак не сказывается на уровне защиты. Некоторые производители устанавливают дополнительный процессор безопасности: например, у Samsung он есть в линейке Galaxy S, а Google вставляет чип Titan M в устройства линейки Pixel. Эти модули (secure elements) являются по сути аналогами Apple SEP для операций только с секретными данными. Ключи Keymaster передаются в эти защищённые аппаратные модули для обработки, никак не задействуя основной процессор.
Android Verified Boot (AVB)
Применяется модуль верификации «dm-verity» для проверки целостности начальной загрузки системы на основе криптографического хеш-дерева. Если по мере загрузки модулей ОС одно из значений не совпадает с ожидаемым, то проверка завершается ошибкой и устройство переводится в нефункциональное состояние. Поддерживается опция отката к предыдущей безопасной версии Android, которая хранится в защищённом от несанкционированного доступа разделе.
Разблокированный загрузчик позволяет отключить AVB и выполнять произвольный код при загрузке устройства, что может быть полезно разработчикам или пользователям, желающим получить рут-доступ.
Рисунок 5. Алгоритм работы Android Verified Boot
Google Mobile Services (GMS)
Многие функции безопасности связаны с мобильными сервисами Google (GMS), такими как Drive, Gmail, Duo, Photos, Maps, Play Services. Устройства, которые прошли сертификацию и приняты в GMS, помечаются как «Play Protect certified».
Google использует Google Cloud для хранения данных и применяет протокол TLS для связи клиента с сервером. Все данные в Google Cloud зашифрованы ключами, которые известны Google. Сквозное шифрование поддерживается только в приложении Google Duo.
Разработчики приложений взаимодействуют с GMS через Play Services API. Следует отметить API SafetyNet, который по сути является службой проверки Android-устройств на предмет наличия рут-прав или подозрительного ПО.
Подписывание APK и проверка кода
AOSP требует, чтобы разработчик подписал созданное им запускаемое приложение. Подпись (цепочка сертификатов и кортежи) файла APK соответствует открытому ключу, распространяемому вместе с ним. До публикации приложения в Play Store производится автоматическая и ручная проверка кода приложения сотрудниками Google.
Начиная с версии Android 11 применяется также модуль «fs-verity» — для непрерывной проверки файлов APK. Если телефон сертифицирован GMS, то есть опция установки приложений из «неизвестных источников», например тех, которые отсутствуют в Play Store или созданы альтернативными разработчиками.
Резервное копирование
Организовано двумя способами посредством GMS. Начиная с версии Android 2.2 применяется Android Backup Service. Приложение создаёт резервные копии пар ключей и значений согласно конфигурации пользователя. Эта опция не является обязательной и настраивается разработчиком приложения.
В Android 6 появился механизм Auto-Backup, который автоматически синхронизирует данные с Google Drive. В этом случае настройки разработчика не требуются, а пользователю предоставляется возможность отказа от данной услуги.
Оба варианта резервного копирования используют Google Cloud для хранения. GMS организует транспортировку данных с устройства в облако.
С 2018 года поддерживается сквозное шифрование для Android Backup Service. Ключ для шифрования бэкапов генерируется на устройстве, для доступа к ключу применяется классическая аутентификация пользователя (PIN-код, пароль или паттерн). Для защиты ключа со стороны Google применяется модуль Titan HSM (входит в Google Cloud Key Vault). Titan HSM активирует свой ключ только при правильной аутентификации со стороны пользователя устройства. Также Titan HSM обеспечивает защиту от брутфорса и контролирует возможность отката на предыдущие версии ПО.
Данные, которые не относятся к приложениям, копируются отдельно в сервис Google Drive по аналогии с Android Auto-Backup. Эти данные шифруются с использованием пароля аккаунта Google или средства аутентификации пользователя на устройстве. Google имеет доступ к этим ключам.
Некоторые производители предлагают собственные службы бэкапирования. Android Debug Bridge (и ряд сторонних инструментов) позволяет осуществить защищённое паролем резервное копирование на локальный компьютер через интерфейс USB.
Рисунок 6. Схема работы резервного копирования в Android
Сообщения и видеосвязь
В Android не поддерживается сквозное шифрование для обмена сообщениями посредством SMS / MMS или Google Messages. Такая защита есть только у видеозвонков в Google Duo (протокол DTLS-SRTP), которые являются одноранговыми (без сервера-посредника, только настройка соединения маршрутизируется через Google).
Рисунок 7. Схема установления безопасного соединения в Google Duo
В групповых видеочатах также поддерживается сквозное шифрование, где с каждым из участников происходит парный обмен ключами.
Техники обхода защиты пользовательских данных Android
Получение рут-доступа и использование эксплойтов. Получение рут-доступа в Android аналогично джейлбрейку на iOS — оно позволяет модифицировать ОС под нужды пользователя, обходить ограничения производителей или запускать произвольный код. Некоторые устройства открыто поддерживают «рутирование» для целей разработки. Для выполнения этой процедуры необходимо разблокировать загрузчик. В этом случае все данные пользователя удаляются, так как система более не доверяет загрузчику и не может гарантировать безопасность данных. Существуют эксплойты, которые позволяют обходить данное ограничение и получать доступ к данным пользователя. Производители устройств, в свою очередь, блокируют попытки рутирования. Samsung, например, с 2013 года использует Knox-bit — запрограммированный электронный предохранитель, который после срабатывания может быть заменён только аппаратно. Google SafetyNet также обнаруживает устройства, на которых удалось получить рут-доступ. Согласно данным SafetyNet от 2017 года, 5,6 % устройств Adroid рутированы.
Получение рут-доступа с помощью эксплойтов без угрозы стирания данных пользователя осуществляется по разным векторам. Например, это может быть атака на ядро ОС или на конкретный код устройства (OEM или особенности SoC).
Android базируется на ядре Linux, поэтому многие уязвимости последней актуальны для Android и позволяют получить доступ суперпользователя. Например, уязвимость Linux Dirty CoW легла в основу эксплойта под Android, а брешь PingPongRoot, обнаруженная в ядре Android, могла быть использована в Linux. Также постоянно выявляются новые, ещё неизвестные (0-day) уязвимости, которые могут быть использованы для получения рут-доступа, в том числе на большом количестве устройств.
Атака на конкретное устройство более узконаправленна. Рассматриваются особенности оборудования, прошивка компонентов — например, Qualcomm EDL. При некоторых манипуляциях с устройством загружается интерфейс аварийной отладки Qualcomm EDL, а не Android, что позволяет злоумышленнику записать необходимый код в раздел Android и получить права суперпользователя без потери данных. Некоторые устройства с компонентами MediaTek можно безопасно рутировать инструментом SP-Flash-Tool без разблокировки загрузчика. Список таких устройств и уязвимостей на базе ядра весьма обширен в силу распространённости и специфики ОС Android.
Альтернативные и потенциальные техники обхода защиты. Подозрительные приложения, установленные из недоверенных (и даже доверенных) источников, не всегда несут риск компрометации данных пользователя, но злоумышленник, которому удалось внедрить такого рода ПО, имеет определённые преимущества в обходе защитных механизмов Android.
Рисунок 8. Диаграмма распределения подозрительных приложений из недоверенных источников (2018 год)
Уязвимость в конкретном приложении может привести к утечке данных, как это было, например, в WhatsApp. Удалённое выполнение кода приводило к краже архива сообщений приложения. Режим песочницы эффективно ограничивает такого рода уязвимости и не позволяет скомпрометировать всю систему.
Атака на доверенное аппаратное и программное обеспечение может быть полезна в цепочке эксплойтов. Впрочем, успешных атак, например, на Samsung Secure Processor или Google Titan M зафиксировано не было. Google предлагает 1 000 000 долларов США за рабочий эксплойт для Titan M.
Брутфорс пароля и паттерна ограничивается механизмом Gatekeeper, который позволяет контролировать запросы посредством пауз между попытками. Однако возможно обойти ограничения Gatekeeper путём компрометации архитектуры TEE TrustZone и даже полностью исключить проверку посредством хитрых лазеек.
В некоторых случаях Google Smart Lock позволяет обойти блокировку экрана без аутентификации пользователя. Однако случаев, когда доступ к заблокированным функциям Android или данным пользователя был получен посредством обхода блокировки экрана, не зафиксировано.
Локальное извлечение данных инструментами форензики. Посредством Android Debug Bridge можно сделать полную резервную копию устройства на локальную машину и получить все данные, но при условии, что устройство уже разблокировано или известен PIN-код. Если SD-карта не была привязана к устройству и зашифрована, то можно извлечь SD-карту.
В противном случае для получения доступа к данным можно использовать различные инструменты форензики, например утилиту Autopsy с открытым исходным кодом. В более сложных ситуациях можно воспользоваться профессиональными сервисами от Cellebrite, Oxygen или Magnet, которые имеют свои инструменты извлечения данных, основанные на различных эксплойтах и методиках.
Извлечение данных из Google Cloud. Android тесно связан со множеством служб Google и хранит данные в Google Cloud без сквозного шифрования, имея полный доступ к данным. По запросам правоохранительных органов данная информация может быть предоставлена на экспертизу. Исключение составляет сервис Android Backup Service.
Если по каким-то причинам Google отказывает в запросе или доступ к облачным данным пытается получить злоумышленник, то применяются инструменты форензики, позволяющие извлечь из устройства токены аутентификации для облака. Далее данные скачиваются из облака в ручном режиме.
Как можно было бы повысить защиту Android
Шифрование данных пользователя при блокировке экрана
Ключ шифрования должен удаляться из памяти после блокировки экрана. Пока пользователь не использует устройство, личные данные будут недоступны. Введение такой функциональной особенности в Android повысит текущий уровень безопасности, но потребует от разработчиков адаптировать работу приложений в фоновом режиме при заблокированном экране. Это также ограничит эффективность извлечения данных из рутированных устройств посредством эксплойтов.
Внедрение сквозного шифрования для обмена сообщениями и других продуктов Google
Сквозное шифрование в службах GMS повысит доверие пользователей и обеспечит надлежащую безопасность данных. С другой стороны, Google использует машинное обучение на всех пользовательских данных, к которым имеет доступ, для повышения качества услуг. Необходимо принимать во внимание, что, обеспечивая надёжную конфиденциальность пользователям, сквозное шифрование может ограничивать доступ к данным для органов защиты правопорядка, мешая, например, борьбе с наркотрафиком.
Безопасный доступ в работе с прошивкой
Многие эксплойты обходят защитные механизмы Android используя уязвимости в прошивке. Можно пойти аппаратным путём и распространять программаторы прошивки с защищёнными от взлома компонентами, что позволит поставщикам отслеживать утечки. Второй вариант — отзыв сертификата скомпрометированного программатора.
Усиление компонентов аппаратной части
Функциональность TEE TrustZone может быть усилена аппаратно при использовании выделенного сопроцессора безопасности. Уменьшая стоимость устройств, производители не всегда внедряют дополнительный сопроцессор для повышения безопасности и устойчивости к аппаратным и программным атакам.
Повышение частоты обновления Android
Современные устройства обеспечивают вполне надёжную защиту данных пользователя. Однако огромное количество устройств работает не на самой последней версии ОС по разным причинам, что создаёт риск уязвимости ко многим атакам. Особенно это касается устаревших устройств, на которые нельзя установить финальную версию ОС. Обучение пользователей и повышение частоты обновлений безопасности Android поможет снизить риски для безопасности данных пользователей.
Больше преимуществ от открытого кода и экосистемы
Большая популярность и охват рынка могут усилить безопасность Android по многим фронтам. За счёт открытого кода разработчики могут внедрять улучшения, которые не зависят от Google. Со своей стороны Google может продвигать протоколы и формировать стандарты безопасности. Единое ядро Linux и Android выгодно обеим платформам: улучшения Linux отражаются на Android и наоборот. Обе системы помогают друг другу своевременно обнаруживать и устранять критические уязвимости, постепенно повышая безопасность.
Выводы
При должном усилии злоумышленник имеет высокую вероятность получить доступ к конфиденциальным данным пользователя вне зависимости от используемой платформы. Выделим особенности безопасности каждой из операционных систем.
Особенности безопасности Apple iOS:
- аутентификация пользователя (цифровой PIN-код, пароль, биометрия) + SEP;
- подписывание кода (Boot ROM и подписывание приложений);
- песочница и анализ кода приложений;
- шифрование (AES, ECDH over Curve25519, UID, Data Protection classes);
- Keychain (API для безопасного хранения ключей);
- резервное копирование (Keybag и iCloud Backup Keybag);
- облачный сервис iCloud и CloudKit (API для iCloud);
- iCloud Keychain (синхронизация и восстановление Keychain);
- аппаратное обеспечение безопасности (SEP);
- контроль и ограничение фронта атаки (Wi-Fi, Bluetooth, пуш-уведомления, USB/Lightning).
Особенности безопасности Google Android:
- аутентификация пользователя (цифровой PIN-код, пароль, паттерн, биометрия) + Gatekeeper и Smart Lock;
- песочница приложений (DAC + SELinux);
- шифрование всего диска и файлов (AES-128/256, Credential Encrypted и Device Encrypted), а также SD-карты;
- Trusted Execution Environment (TEE) и дополнительный аппаратный модуль безопасности (secure element);
- Android Verified Boot;
- резервное копирование (Auto-Backup и Backup Service);
- Google Mobile Services;
- подписывание приложений и анализ кода;
- сквозное шифрование в Google Duo.
Несмотря на то что Apple более тщательно организовывает шифрование файлов на устройстве и в облаке, чем Google, существуют ситуации, когда злоумышленник может получить многие (или все) данные пользователя. Хранение токенов аутентификации для iCloud в режиме AFU требуется переработать. Обеспечение сквозного шифрования всех данных в облаке устранит противоречия в политике конфиденциальности Apple.
Сквозное шифрование рекомендуется и для Android GMS. Более серьёзный недостаток Android — это постоянное хранение ключей шифрования в памяти устройства после первой разблокировки. Внедрение аналога iOS Complete Protection значительно увеличит защиту данных пользователя от атак злоумышленников.
Пользователям мобильных устройств можно порекомендовать использовать максимально сложные пароли, а также биометрическую аутентификацию везде, где она рекомендуется операционной системой. По возможности следует применять 2FA (двухфакторную аутентификацию). Полезно изучить настройки синхронизации данных с облачными сервисами и не передавать в облако ничего лишнего.
Рутирование / джейлбрейк устройства — это большой риск запуска произвольного кода (в том числе и на уровне прошивки), который может оказаться небезопасным и полностью скомпрометировать устройство.
Сейчас безопасность пользовательских данных у обеих мобильных платформ организована весьма качественно, но впереди ещё много работы по улучшению защиты как для Google Android, так и для Apple iOS.
