Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым
Если вы являетесь регулярным читателем Хабра, то должно быть заметили что за последние несколько лет вышло немало статей о сборе персональных данных с мобильных устройств, и о попытках противодействия этому, было несколько отличных статей с детальными инструкциями по превращению своего смартфона на базе ОС Android в настоящую цитадель приватности и безопасности.
Часто для этого рекомендуется получение прав суперпользователя в системе (root-права), удаление системных приложений от Google и от производителя устройства, или даже полная замена стандартной ОС на альтернативные сборки, чаще всего LineageOS (бывший CyanogenMod). При этом первым шагом в этом процессе всегда будет так называемая «разблокировка загрузчика». Во время её выполнения устройство несколько раз покажет нам страшные предупреждения о том, что теперь оно станет более уязвимо для злоумышленников, но мы смело нажимаем «подтвердить» и шьём root или самую свежую сборку кастомной прошивки, не задумываясь о том какие проблемы создаёт нам незаблокированный загрузчик.
Я хочу рассказать вам как погоня за приватностью и безопасностью может привести к бóльшим проблемам чем использование стоковых устройств, как при физическом доступе к устройству можно установить в android бэкдор который может пережить сброс до заводских настроек, обновление или даже полную перепрошивку системы, как можно вытащить данные из зашифрованного устройства не зная пин-код, не входя в систему и без запущенного режима отладки в меню разработчика.
Вступление
Сразу в начале оговорюсь, что все упомянутые опасности будут касаться наших устройств только если у злоумышленника есть физический доступ к девайсу. Поэтому можно просуммировать необходимые начальные условия:
Физический доступ к смартфону. Нескольких минут будет достаточно.
Загрузчик на смартфоне уже находится в разблокированном состоянии. Это главное условие. Оно в 95% случаев справедливо для устройств, на которых получены root-права или установлены сторонние сборки ОС, на что и намекает название статьи, но вполне возможно что пользователь по каким-то странным причинам решил разблокировать загрузчик и без этого. Нам не принципиально, загрузчик разблокирован — можно атаковать, версия android не имеет значения, наличие или отсутствие рута также не имеет значения. Именно о возможностях, которые даёт атакующему с физическим доступом разблокированный загрузчик, и будет вся суть статьи.
Для устройства существует возможность организовать sideload. Например, для устройства есть TWRP или иной образ recovery дающий возможность перевести устройство в режим sideload. Для большинства популярных устройств, поддерживающих разблокировку загрузчика, существуют готовые образы TWRP.
Если задуматься, то ситуация с физическим доступом к смартфону не такая уж и невероятная. Например, последние годы набирает тенденция проверки мобильных устройств пограничниками при въезде в страну. Количество подобных проверок увеличивается в разы с каждым годом и вскоре может стать повсеместно распространённой практикой. С одной стороны это вопиющий произвол, нарушение законов и вторжение в частную жизнь, с другой стороны, законы большинства стран в этом моменте очень скользкие, плюс, например, на границе вы ещё не попали на территорию страны, поэтому и законы защищающие вашу частную жизнь ещё могут не действовать. В общем, «отжать мобилу» у вас смогут в подавляющем большинстве случаев. В журнале Хакер есть отличная статья обозревающая эту проблему. Если по каким-либо причинам вас задержит полиция, то все ваши электронные устройства также будут изъяты и, как и на границе, могут быть незаметно для вас пробэкдорены.
Постановка задачи
Итак, представим ситуацию, мы — злоумышленник, получивший на некоторое время в свои руки смартфон. Устройство — смартфон на базе android с разблокированным загрузчиком. Устройство имеет встроенное шифрование хранилища, его тип — аппаратный, т.е. ключи хранятся в TEE. Устройство заблокировано, для разблокировки необходимо ввести пин-код. Причём устройство находится в BFU (before-first-unlock) состоянии, это значит, что после включения устройства код разблокировки не вводился ни разу и файловая система зашифрована. На устройстве не включен режим отладки и подключиться по adb к нему невозможно. В нём содержатся данные, которые нам необходимо изъять. Устройство нужно будет вернуть владельцу, неповреждённое, в рабочем состоянии, причём владельцу не должно бросаться в глаза что его устройство было скомпрометировано.
Звучит как невыполнимая задача, и так бы оно и было, если бы нам любезно не открыл дверь сам владелец. Современные смартфоны очень хороши с точки зрения безопасности. Возможная поверхность атаки у них крайне мала. В последних версиях ОС android сделано очень многое для защиты данных пользователей. Защита системы выстроена в несколько уровней. Данные шифруются, подписи проверяются, ключи хранятся аппаратно. Везде используется подход «least privilege» — запрещено всё что не разрешено. Приложения работают в рамках серьёзных ограничений. Можно смело утверждать, что современные смартфоны являются одними из лучших примеров безопасных устройств, которые создавал человек.
Если пользователь не совершает явно странные действия вроде скачивания странных apk со странных ресурсов и не выдаёт им явно руками привилегий администратора устройства, то навредить пользователю или украсть его данные довольно затруднительно. И даже эти проблемы являются скорее не дырами в безопасности системы, а следствием свободы, которую android предоставляет пользователям, однако не все распоряжаются ей правильно. Прошли времена, когда безопасность android была поводом для шуток. На сайте известного брокера эксплоитов, компании Zerodium, FCP — full-chain with persistence или полная цепочка удалённой эксплуатации устройства с закреплением в системе в настоящий момент является самым дорогим эксплоитом, за который компания готова выложить до двух с половиной миллионов долларов.
Разблокированный загрузчик роняет уровень сложности этой задачи от невозможного до тривиального. Почему-то тема опасности открытых загрузчиков поднимается довольно редко, и, мне кажется, её значимость здорово недооценена, поэтому давайте разбираться.
Код с примером будет приведён довольно упрощённый и не в самом изощрённом варианте, но рабочий и явно демонстрирующий то, как именно это работает.
Все действия я проводил на устройствах на OnePlus 5T (он же dumpling по принятой в android device treeклассификации) на стоковой OxygenOS и LineageOS с версиями соответсвующими android 9 и 10, и XiaomiMI6 (он же sagit). Из-за этого некоторые ньюансы структуры разделов, и выводы некоторые выводы команд у вас могут отличаться, но общая суть происходящего не изменится.
Я буду часто ссылаться на ресурс source.android.com. Это примерно тоже самое что и developer.android.com, но не для разработчиков приложений, а для разработчиков устройств. Там хорошо описана работа ОС, системных компонентов, и т.д. Очень рекомендую, вряд ли где-то можно найти более структурированную информацию по устройству системы.
Что же плохого происходит когда загрузчик разблокируется?
Если вкратце — отключаются механизмы защиты Android Verified Boot (далее avb) и Device Mapper Verity (далее dm-verity). Для того чтобы понять серьёзность последствий нам необходимо рассмотреть процесс инициализации и загрузки системы. Поскольку android это linux, то многие вещи которые будут происходить будут очень похожи на процесс загрузки других дистрибутивов, но с некоторой спецификой. Нас для темы статьи будет интересовать в основном только часть загрузки до запуска первого userspace процесса, собственно, как раз — init.
Загрузка системы начинается с загрузчика. Загрузчик — это небольшой бинарный компонент, который запускается непосредственно чипсетом и отвечает за загрузку и запуск ядра. Если в настольных дистрибутивах linux мы привыкли в основном к загрузчику grub, то на android смартфонах у нас загрузчиком является aboot. Процесс загрузки происходит следующим образом:
На плату устройства подаётся питание
Выполняется первичный загрузчик (primary bootloader, PBL). Он хранится в ПЗУ чипа. Он производит инициализацию памяти некоторого минимального набора для работы с железом, например с физическими кнопками устройства и партициями.
Далее происходит инициализация и запуск вторичных нагрузок (secondary bootloader, SBL). Именно на этом этапе инициализируется и запускается Trusted Execution Environment (далее TEE) ARM TrustZone — та часть arm чипа которая отвечает за критические вещи связанные с безопасностью устройства. В ней работает целая отдельная операционная система, чаще всего — Trusty, её также как и android производит google. В TEE хранятся ключи, и TEE умеет производить с материалом этих ключей операции над данными которые ему может прислать основная ОС. Именно с TEE через уровень абстракции железа (hardware abstraction layer, далее HAL) взаимодействует AndroidKeystore который часто используется разработчиками для различных операций связанных с криптографией и обеспечением безопасности данных. Также здесь хранятся важные ключи, например ключи необходимые для расчёта MAC для операций записи в специальный защищённый от несанкционированной перезаписи блок памяти (replay protected memory block, далее RPMB) и, что особенно интересно для нас, ключи для проверки подписи файловых систем на этапе AVB. TEE запускается до запуска основной ОС, потому что ей необходимо ограничить себя от прямого взаимодействия с основной ОС и исключить возможность модификации с её стороны, а также потому что собственно она хранит ключи необходимые для проверки целостности системы до её старта.
Далее исполняется aboot. Он собирает информацию для того чтобы понять что и как именно нужно запустить. На этом этапе он смотрит на флаги записанные в специальной памяти, на зажатые физические кнопки, и принимает решение в каком режиме продолжить загрузку системы: в штатном режиме, в режиме восстановления (recovery), в режиме прошивки (fastboot). Загрузчик может также загружать другие специальные режимы, которые зависят от конкретного чипа или устройства, например EDL на чипах Qualcomm который используется для экстренного восстановления устройства путём загрузки прошивки образа подписанного ключами Qualcomm публичная часть которых зашита внутрь чипа. Мы будем рассматривать штатный процесс загрузки.
Некоторые устройства использует механизм seamless updates, его также называют A/B partitions. В этом случае загрузчик обязан выбрать правильный текущий слот для загрузки. Суть этого механизма в том что некоторые разделы представлены в двух экземплярах, например вместо обычного /system на устройстве будут /systema и /systemb, вместо /vendor — /vendora и vendorb. Цель этого — более быстрые и защищённые от окирпичивания устройства обновления системы, т.е. например вы загружены в систему используя слот A, вы собираетесь обновить устройство, выбираете соответсвующий пункт в настройках и продолжаете спокойно работать с системой. Пакет обновления скачивается, но вместо перезагрузки в специальный режим обновления и ожидания прошивки, оно сразу шьётся, но не на запущенную систему (это и не получится сделать), а в разделы второго слота B: /systemb, /vendorb и, если необходимо, в другие. После прошивки система отмечает флаги что следующая загрузка системы должна быть штатной и должна использовать слот B и предлагает перезагрузиться. Вы перезагружаете устройство, загрузчик выбирает слот B и продолжает загрузку, всего через несколько секунд ожидания ваша новая ОС загружена, отмечаются флаги что загрузка прошла успешно, текущий образ системы работает, с ним всё хорошо, а значит можно продублировать текущую систему во второй слот. В случае если загрузка не закончится успехом, то система не поставит флаги об успехе и загрузчик поймёт что новая система не работает, нужно загрузиться в старый слот, повреждённое обновление на него не накачено и вы продолжите работать с устройством как ни в чём не бывало.
Продолжается штатная загрузка. Загрузчик ищет в подключённых устройствах раздел /boot. Этот раздел содержит две необходимые для запуска системы составляющие: ядро ОС — kernel, и начальный образ файловой системы — initramfs (в android он практически везде называется ramdisk и я далее буду называть его именно так). Вот здесь начинают работать механизмы защиты ОС от модификации или наоборот, их работа отключается в том случае если наш загрузчик был разблокирован. При загрузке считается хэш сумма данных содержащихся в /boot разделе и сравнивается с эталонным хэшом который рассчитан и подписан приватным ключом производителя устройства в момент сборки системы, эта подпись должна быть успешно верифицирована AVB ключом хранящимся в TEE. В случае разблокированного загрузчика этой проверки не производится, т.е. система будет запускать любые ядро и ramdisk, даже если они не подписаны производителем устройства.
Механизмы защиты продолжают работу. Далее проверяется что целостность загружаемого раздела с системой также не нарушена. Ramdisk хранит публичный ключ verity_key, приватной частью которого подписан корневой хэш в таблице dm-verity хешей для системного раздела. Осуществляется проверка подписи после чего происходит переход к загрузке системы. Если загрузчик нашего устройства разблокирован, то эта проверка также пропускается.ё
Весь этот процесс называется boot flow и отлично проиллюстрирован здесь:
У загрузки с avb может быть 4 конечных состояния, условно обозначаемых цветами:
green state — загрузчик заблокирован, используется embedded root of trust, т.е. публичный ключ avb поставляется в аппаратном TEE. Целостность ядра и системы не нарушена. Никаких сообщений пользователю не показывается. Система загружается. Так происходит всегда когда мы пользуемся обычным, не модифицированным устройством.
yellow state — загрузчик заблокирован, но вместо аппаратно хранимого ключа от производителя устройства используется user-settable root of trust, т.е. ключи avb генерируются и используются на этапе сборки системы, а затем публичный ключ зашивается в специальный раздел вместе с прошивкой системы. Целостность ядра и системы не нарушена. Пользователю на 10 секунд показывается большой желтый предупреждающий знак и сообщается что устройство загружает стороннюю операционную систему. После этого система загружается.
orange state — загрузчик разблокирован, root of trust игнорируется. Целостность ядра и системы не проверяется. Пользователю на 10 секунд показывается большой оранжевый предупреждающий знак и сообщается что целостность разделов устройства не проверяется, и система может быть модифицирована. После этого система загружается. Так происходит на устройствах с установленными root-правами или альтернативной сборкой ОС, именно этот случай нас интересует.
red state — загрузчик заблокирован, используется любой root of trust, целостность системы нарушена при заблокированном загрузчике, либо система повреждена (что для dm-verity в общем-то одно и тоже, как описано в документации). Пользователю показывается сообщение о том, что система повреждена. Система не загружается.
Задача механизмов avb и dm-verity убедиться в том, что загружаемые ядро и система не были изменены и дошли до устройства пользователя в таком виде в каком их выпустил производитель устройства. Если пользователь решил установить root-права или альтернативную сборку ОС, то он неминуемо нарушит хэши партиций и чтобы система могла продолжить работу, а не уходила сразу в «красное состояние» в котором откажется загружаться, ему придётся разблокировать загрузчик и с точки зрения avb перевести устройство в «оранжевое состояние» где android будет закрывать глаза на модификации системы. Этим пользуются и инструменты для получения root, и сторонние сборки, этим могут воспользоваться и злоумышленники, этим воспользуемся и мы.
Логическим следствием перехода в «оранжевое состояние» и отключения avb является возможность загружать образы с ядром не подписанные производителем устройства. Среди любителей модифицировать android самым популярным проектом такого рода является «Team Win Recovery Project» или просто TWRP. TWRP позволяет делать с устройством практически всё, в частности монтировать и модифицировать любые разделы не загружаясь в саму систему непосредственно. Именно эта возможность нам будет нужна для нашей задачи, но для начала надо разобраться с тем, как именно данные пользователя хранятся на устройстве.
Как устроено хранилище
Если мы посмотрим на структуру разделов на хранилище смартфона, то увидим что их на устройстве довольно много.
# ls -la /dev/block/by-name
total 0
drwxr-xr-x 2 root root 1480 1973-02-10 03:40 .
drwxr-xr-x 4 root root 2160 1973-02-10 03:40 ..
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 LOGO -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 abl -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 ablbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 apdp -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 bluetooth -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 boot -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 boot_aging -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 cache -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib64 -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib64bak -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlibbak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 config -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 devcfg -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 devinfo -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dip -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dpo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dsp -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 frp -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 fsc -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4g9n4 -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4j1ed -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4t0n8 -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_8v1ee -> /dev/block/sde44
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 hyp -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 hypbak -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 keystore -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 limits -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 logdump -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 logfs -> /dev/block/sde37
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 md5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtp -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtpsecapp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtpsecappbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 minidump -> /dev/block/sde47
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 misc -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 modem -> /dev/block/sde10
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 msadp -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 oem_dycnvbk -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 oem_stanvbk -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 param -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 pmic -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 pmicbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 recovery -> /dev/block/sde22
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 reserve -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 reserve1 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 reserve2 -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 reserve3 -> /dev/block/sdf7
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 rpm -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 rpmbak -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 sec -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 splash -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 sti -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 storsec -> /dev/block/sde41
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 storsecbak -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 system -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 toolsfv -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 tz -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 tzbak -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 userdata -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 vendor -> /dev/block/sdf6
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 xblbak -> /dev/block/sdc1Большинство из них небольшие, и содержат, например, логотип производителя девайса, который отображается сразу после подачи питания на плату устройства. Есть раздел содержащий прошивку, работающую на baseband процессоре и отвечающую за мобильную связь, звонки и интернет по стандартам 2G, 3G, LTE и т.д. Есть разделы содержащие BLOBы необходимые для работы с некоторыми устройствами. Нас будет интересовать всего несколько разделов, содержание которых монтируется в файловую систему и напрямую используется во время работы ОС:
Раздел boot содержит ядро операционной системы.
Раздел system содержит саму операционную систему, все её исполняемые файлы, неизменяемые конфиги, системные библиотеки, android-фреймворк и другие jar файлы необходимые для работы виртуальной машины, в которой исполняются android приложения. Начиная с android 10 на многих устройствах вместо обычного system раздела используется раздел systemasroot, он отличается точкой монтирования, но его суть та же — он содержит файлы ОС.
Раздел vendor содержит пропиетарные компоненты ОС от производителя устройства. Например, драйвера Qualcomm и т д
Раздел userdata содержит данные касающиеся текущего экземпляра установленной операционной системы. Его мы рассмотрим подробнее.
Данные текущей установленной ОС включают, например, текущие ключи adb, установленные в системе текущие настройки, изменяемые конфиги и т.д. В userdata располагаются внутренние директории приложений, которые принято называть песочницами или «internal storage» установленных приложений, а также общее файловое хранилище, в котором лежат фото, видео, музыка, документы, загрузки пользователя и остальную его информацию. Именно его мы можем увидеть в системном приложении «Файлы». Общее файловое хранилище с точки зрения установленных приложений является «externalstorage».
Данные приложений, «internal storage», находятся по пути /data/data. В этой директории сложены директории-песочницы отдельных приложений, соответствующие их полным именам пакетов. Например:
drwx------ 8 u0_a69 u0_a69 4096 2021-01-29 13:31 com.google.android.youtubeКак вы можете видеть, владельцем директории является u0a69. При установке пакетов android присваивает каждому приложению отдельного системного пользователя и группу и создаёт им домашнюю директорию в /data/data, по аналогии с /home/user в настольных дистрибутивах linux. Номера uid начинаются с 10000, номера до 10000 зарезервированы и используются системными приложениями и сервисами. В названии u0 означает — первый пользователь (обычно он всегда первый и единственный, за исключением редких случаев, когда устройство поддерживает многопользовательский режим), a69 — просто номер приложения. Эта директория хранит файлы, кэш, базы данных, shared preferences приложений и т.д. Доступ в директорию возможен только приложению владельцу. Даже системные приложения поставляемые с устройством (пользователь system: system, uid=1000, gid=1000) и adb shell (пользователь shell: shell, uid=2000, gid=2000) не могут получить доступ к файлам других приложений.
Общее хранилище, «external storage», находится по пути /data/media/0, внешние SD-карты соответственно будут называться /data/media/1. Во время работы оно линкуется в /storage.
Если мы являемся обычным непривилегированным приложением, то всё что нам доступно для записи — своя песочница, и, если получено разрешение WRITEEXTERNAL_STORAGE, общее хранилище. Вся остальная часть раздела userdata нам недоступна, однако ей пользуется сама операционная система, храня там, например dalvik-кэши.
Система специально спроектирована таким образом, что во время работы с устройством единственный раздел, состояние которого изменяется, это userdata. Во время штатной работы с устройством в промежутке между обновлениями системы, состояние разделов boot, system и vendor остаётся неизменным. Boot обычно не виден нам в ФС напрямую, содержание system и vendor монтируется в режиме «read-only», потому что в них ничто никогда не должно быть перезаписано. Именно поэтому avb может так удобно проверять целостность системы. Разделы boot, system и vendor могут перезаписываться только когда производитель устройства присылает обновление, а вместе с обновлением и новые подписи разделов для dm-verity, поэтому verified boot не нарушается. Попытка перезаписать любой из этих разделов без обновления подписей приведёт к блокировке работы устройства или даже к превращению устройства в кирпич, восстановить который можно будет только через замыкание test-point-ов на плате или через различные специальные режимы, которые у каждого производителя устройства свои, например у Qualcommэто EDL.
Изначально, раздел userdata пуст. Когда устройство запускается, оно смотрит на его содержание, и если там ничего нет, то система понимает что она запускается первый раз, а значит необходимо провести действия связанные с первым запуском — распаковать и установить системные приложения из read-only директорий /system/app и /system/priv-app, назначить им системных пользователей, создать им директории песочницы, скопировать и применить некоторые настройки по умолчанию, подготовить лаунчер, показать пользователю приветственное сообщение и провести онбординг. Из-за этого первый запуск устройства после покупки происходит значительно дольше чем обычно. В случае если раздел userdata уже наполнен, то этот шаг пропускается и система загружается за несколько секунд.
Сброс до заводских настроек, как вы уже могли догадаться, это просто форматирование раздела userdata, после которого устройство снова будет отрабатывать ровно тем же образом что и при запуске в самый первый раз. Ни один из других разделов при этом не модифицируется.
Как устроено шифрование хранилища
Для начала разберёмся как устроено шифрование хранилища, потому что это самое труднопреодолимое препятствие для изъятия данных. Шифрование применяется на уровне файловой системы. Существует два основных подхода к организации шифрования:
FDE — full-device-encryption — полнодисковое шифрование. Это значит что всё устройство хранения зашифровано, и даже загрузка операционной системы невозможна до его расшифровки. Поэтому в этом случае владельцу устройства для работы с ним сначала, ещё до загрузки операционной системы, необходимо ввести ключ с помощью которого хранилище будет расшифровано и только потом произойдёт загрузка системы. Такой подход требовал «двойной» загрузки системы, сначала в минимальном варианте для показа формы ввода пароля, а потом в полноценном, после расшифровки хранилища. Он применялся на некоторых устройствах с версиями android 5–7, однако на современной версии ОС и современных устройствах не используется
FBE — file-based-encryption — шифрование отдельных частей файловой системы. Применительно к androidзашифрованы только те части системы, где хранятся данные пользователя. Незашифрованным остаются ядро, системный раздел, и т.д. Строго говоря, проще перечислить то, что зашифровано, а зашифрованы только /data/data и /data/media. Все остальные части системы остаются незашифрованными. Это позволяет операционной системе успешно загружаться до экрана авторизации пользователя, стартовать системные сервисы и accessibility сервисы, принимать SMS. Начиная с android 7 и переходом на FBE появилось Directboot API, которое даёт приложениям возможность запускаться и в ограниченном режиме работать до ввода кода разблокировки и расшифровки файловой системы. FBE позволяет сочетать высокие стандарты защиты данных в хранилище и отличный пользовательский опыт. Пользователь не отвлекается на ввод дополнительного пароля до запуска системы, система не тратит ресурсы на шифрование и расшифровку частей файловой системы где не содержится личных данных владельца. Это современный подход, который используется на современных устройствах и является обязательным для всех новых устройств, начиная с android 9.
Первый ввод кода разблокировки очень важен, потому что именно в этот момент происходит фактическая расшифровка оставшихся частей раздела userdata. Система получает возможность завершить загрузку и запустить лаунчер. После этого ключи шифрования к файловой системе будут храниться в памяти и не покинут её до выключения питания. Из-за этого среди специалистов занимающихся извлечением данных из устройств принято выделять два состояния устройства:
BFU (before first unlock) — до первого ввода кода разблокировки
AFU (after first unlock) — после первого ввода кода разблокировки
До первого ввода кода разблокировки данные пользователя всегда зашифрованы, после первого ввода — всегда расшифрованы. Даже когда пользователь в дальнейшем нажимает кнопку питания или система сама уходит в сон, то данные, с точки зрения ОС, больше не переходят в зашифрованное состояние, теперь их защищает только экран блокировки. В android пока не предусмотрен механизм очищения ключей для расшифровки файловой системы из памяти после определённого периода неактивности.
Это значит, что если после того, как устройство было разблокировано хотя бы однажды подключиться к нему, например по adb, то пользовательские данные будут доступны и можно получить к ним доступ даже если экран заблокирован.
Вот так выглядит общее хранилище до первого ввода кода разблокировки:
# ls -la /data/media/0/
total 100
drwxrwx--- 13 media_rw media_rw 4096 2021-01-29 10:45 .
drwxrwx--- 4 media_rw media_rw 4096 2021-01-29 10:43 ..
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 3aIg6706qnt+JRerXQc,9B
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 5RxSnwRfzXH5JsgykyuneB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 9QCg2626EAEHNRc,IpjzjC
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 XLrhnulSzxYVPwgkHhs8YC
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:45 ZC6kM5uXi6,coHL+OYgLCB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 kJJ0DN8Tmhcs7hicwcEZ3A
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 mPaCm6PJHF9,MyimVTRozC
drwxrwxr-x 3 media_rw media_rw 4096 2021-01-29 10:43 qIkgta78EOvsfnjupFXQ+C
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 uAP,C13tjXpxdP8PWVeMRD
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 v33cOjp,wu+hlgBIWnQdjB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 xxjD9tk7bDh9XZUzoDwMbBА вот так после:
# ls -la /data/media/0/
total 100
drwxrwx--- 13 media_rw media_rw 4096 2021-01-29 10:45 .
drwxrwx--- 4 media_rw media_rw 4096 2021-01-29 10:43 ..
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Alarms
drwxrwxr-x 3 media_rw media_rw 4096 2021-01-29 10:43 Android
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 DCIM
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Download
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Movies
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Music
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Notifications
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Pictures
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Podcasts
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Ringtones
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:45 bluetoothНа самом деле, шифрование хранилища — самая трудно преодолимая часть нашей задачи по извлечению данных. Обойти шифрование с ключами в аппаратном ТЕЕ никак не представляется возможным, но зато из этой информации следует несколько полезных выводов, а наша задача начинает формироваться в конкретные технические требования.
Во-первых, получать доступ к личным файлам пользователя в любом случае придётся только после ввода кода разблокировки.
Во-вторых, разблокированный загрузчик даёт возможность переписывать системный раздел, а он никогда не зашифрован, даже в BFU состоянии.
Это подводит нас к мысли о том, что можно воспользоваться возможностью модифицировать никогда не шифруемую часть системы, внедрить в неё агента, который никак не затронет и не испортит зашифрованные данные, а в последствие даст нам доступ к ней после того как устройство будет возвращено пользователю и он сам первый раз введёт код разблокировки. Поскольку пользователь явно не будет вводить код разблокировки подключив устройство к нашему usb кабелю или находясь в нашей локальной сети, то использование adb нам не подходит и необходимо организовать удалённый доступ в формате reverse-shell.
Получение удалённого доступа
Для android существует популярная полезная нагрузка в Metasploit фреймворке которая теоретически может дать нам удалённый доступ к устройству — android/meterpreter/reverse_tcp, однако с ней есть проблемы:
Она поставляется в виде обычного приложения. Мы технически не можем установить в android приложение в зашифрованное хранилище, плюс даже если бы могли, это явный шанс скомпрометировать себя, т.к. приложение будет видно в лаунчере и в списке установленных приложений в настройках, а если на устройстве пользователя установлено одно из антивирусных решений, то оно может задетектить его как вирус по публично доступным признакам. Мы можем пересобрать его изменив сигнатуры или даже внедрить в какое-нибудь другое приложение, но сути это не поменяет.
Она была рассчитана на более старые версии android и часть её функций может не работать на современных версиях системы. Некоторые её возможности требуют подтверждения руками системных диалогов с разрешениями, некоторые просто не заведутся.
Она работает как обычное непривилегированное приложение, а значит ни к чему особо доступ иметь не может. Если на системе нет root-прав, то мы сможем получить только файлы из общего хранилища и только после подтверждения пользователем диалога с разрешением что автоматически выдаст нас. Если на системе есть root-права, то получить их мы сможем только после явного подтверждения диалога с разрешением. Мы могли бы руками отредактировать базу данных magisk для внесения себя в список приложений которым доступен root и отключить для себя логирование и уведомления о предоставлении root-доступа, но для этого нам нужно отредактировать файл из внутренней директории приложения, а она зашифрована.
Будучи обычным приложением она будет попадать под управление жизненным циклом, система в лучшем случае будет отправлять её в сон в doze-mode, в худшем — просто убьёт и перезапустить её будет некому. Умер процесс приложения — умер и процесс агента, поскольку является дочерним процессом приложения.
Для того чтобы агент мог без проблем поддерживать себя постоянно запущенным, не отсвечивать в операционной системе и не попадать под регулирования и ограничения для установленных приложений, необходимо оформить его в виде системного сервиса — демона.
Для того чтобы понять как именно это сделать, нужно вернуться к процессу загрузки системы, однако теперь мы верхнеуровнево рассмотрим оставшуюся её часть происходящую сразу после рассмотренного в начале boot flow, т.е. когда загрузчик загрузил раздел boot, отработал механизм verified boot и система получила добро на запуск:
Ядро и ramdisk распаковывается в оперативную память, и загрузчик запускает ядро.
Ядро стартует, инициализиру
