Android: извлекаем данные с зашифрованной SD-карты и получаем доступ к скрытым методам

Сегодня в выпуске: обзор систем безопасности Android, объяснение атак типа Cloak & Dagger, гайд по извлечению данных с зашифрованной карты памяти, обход ограничений на загрузку нативных библиотек и доступ к скрытым Java-методам, уязвимость в Android Download Provider. А также: несколько инструментов пентестера и подборка библиотек для программистов.

Почитать

Как Android обеспечивает безопасность

The Android Platform Security Model — написанный сотрудниками Google вайтпейпер, посвященный теории и практике реализации подсистем безопасности в Android. В документе много воды, но есть и хоть и не новая, но полезная новичкам информация. Наиболее интересные моменты:

  • Android использует три вида аутентификации (проще говоря: метода разблокировки экрана) с разным уровнем надежности и, соответственно, уровнем доступа: 1) пароль или пин-код — считается наиболее надежным и поэтому дает полный контроль над устройством без всяких ограничений; 2) отпечаток пальца или снимок лица — менее надежный, поэтому система запрашивает пароль после каждой перезагрузки телефона, а также через каждые 72 часа; 3) аутентификация по местоположению или близости определенного Bluetooth-устройства — наименее надежный метод, поэтому на него накладываются те же ограничения, что и на биометрический метод, плюс он не позволяет получить доступ к аутентификационным ключам Keymaster (например, тем, что используются для платежей), а принудительный запрос пароля происходит не через 72 часа, а уже через четыре.
  • Песочницы (изолированная среда исполнения) для приложений в Android реализованы с помощью запуска каждого приложения от имени созданного специально для него Linux-пользователя. Приложение имеет полный контроль над файлами своей песочницы (/data/data/имя_пакета), но не может получить доступ к файлам других приложений и многим системным файлам. Система также использует UID (идентификатор пользователя) для контроля полномочий приложения.
  • Контроль доступа на основе UID не распространяется на карты памяти и USB-накопители, так как зачастую они используют файловую систему FAT, которая не позволяет назначить права доступа к файлам. Чтобы решить эту проблему, Android использует виртуальную файловую систему (sdcardfs), которая подключается к каталогу /sdcard/Android. Приложения могут хранить данные внутри нее без опасения, что другие приложения получат к ним доступ. Также Android позволяет подключить карту памяти в режиме Adoptable Storage, когда SD-карта форматируется в зашифрованную ФС ext4 и становится частью внутреннего хранилища данных.
  • Единственный способ покинуть песочницу — получить права root. В Linux пользователь root имеет неограниченный доступ к файловой системе (ядро отключает любые проверки доступа для этого пользователя).
  • Для защиты ключей шифрования/аутентификации Android и приложения могут использовать Keymaster. Это подсистема, позволяющая хранить данные в TEE (Trusted Execution Environment), специальном микрокомпьютере внутри SoC, к которому имеет доступ только система. TEE позволяет защитить данные даже в том случае, если злоумышленник получил права root. Начиная с девятой версии Android также поддерживает StrongBox, выделенный чип TEE, разработанный самой Google. Он позволяет защититься от атак класса Rowhammer.
  • Для защиты от эксплуатации уязвимостей в системных компонентах Android использует SELinux, подсистему ядра Linux, позволяющую более тонко управлять правами доступа, а также контролировать доступ процессов к системным вызовам. К примеру, обнаружив в одном из системных компонентов уязвимость, взломщик может попытаться принудить этот компонент выполнить системный вызов exec для запуска root shell, но, если правила SELinux запрещают это делать данному компоненту, вызов будет отклонен.
  • Начиная с седьмой версии Android способен гарантировать, что ни операционная система, ни загрузчик не были скомпрометированы. Такая проверка называется Verified Boot и выполняется на этапе загрузки: сначала загрузчик сверяет контрольную сумму раздела boot, затем один из следующих компонентов загрузки сверяет контрольные суммы файлов в разделе system. Тот же механизм используется для защиты от отката на предыдущую версию прошивки, которая может содержать уязвимости. Производители вольны сами выбирать, как должна повести себя система в случае обнаружения нарушения: вывести на экран предупреждающее сообщение или прекратить загрузку.

Как работают атаки класса Cloak & Dagger

Cloak and Dagger  —  Mobile Malware Techniques Demystified — небольшая заметка о том, как работают атаки класса Cloak & Dagger. Мы писали об этом типе атак еще в 2017 году, но тогда рассмотрели только одну из них: кейлоггер, не требующий дополнительных прав в системе. Эта статья посвящена другой атаке, позволяющей заставить пользователя включить настройку доступа к AccessibilityService (позволяет перехватывать любые нажатия пользователя и нажимать кнопки интерфейса за него), замаскировав переключатель под нечто безобидное.

Атака использует разрешение SYSTEM_ALERT_WINDOW, которое приложения из Google Play получают автоматически. SYSTEM_ALERT_WINDOW позволяет выводить элементы интерфейса поверх других приложений, то есть реализовать такие вещи, как плавающие окна, меню, панели управления. Создатели вирусов быстро смекнули, что эту возможность можно использовать для перекрытия текущего окна на экране и обмана пользователя, поэтому с версией Android 5 Google выкатила защиту, которая проверяет, не был ли перекрыт какой-либо опасный для включения элемент интерфейса оверлеем, и отказывается его включить, если это так. Поэтому Cloak & Dagger вместо одного оверлея на весь экран создает несколько небольших и выкладывает их вокруг элемента управления, так что в результате защита не срабатывает.

Обход защиты на включение AccessibilityService с помощью трех-четырех оверлеев

Атака работает на Android версий 4.4.4–7.1.2, исходный код доступен.

В дополнение можно отметить еще одну статью на смежную тему: Android Toast Overlay Attack: “Cloak and Dagger” with No Permissions. Ее авторы пошли еще дальше и реализовали ту же атаку вообще без использования разрешения SYSTEM_ALERT_WINDOW. Вместо него они засунули все оверлеи в toast-сообщение, то самое, которое позволяет выводить в нижней части экрана информационные сообщения. Как оказалось, такие сообщения тоже представляют собой полноценные полноэкранные окна, большая часть которых прозрачна. И у приложения есть доступ к этому окну и возможность его изменять.

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

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


"Евгений Зобнин : @ezobnin Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.."