Comments 210
Согласен, root может давать немало ништяков от которых сложно отказаться. Тут, каждому на вкус и цвет, но честно говоря, я лично самым полезным нахожу Afwall, а остальное вроде как и нерутовыми инструментами достигается
Банковскими приложениями на телефонах лучше вообще не пользоваться, учитывая, какой у них список разрешений — они имеют доступ буквально ко всему.
Для пользования банковскими приложениями нужен отдельный телефон, с дефолтным набором невычищаемых приложух, но с последним принимаемым обновлением оси. Никаких медиафайлов, никаких контактов. Нормальное состояние аппарата - выключен, его полузаряженная батарея, флешки и симки (под каждый банк своя) хранятся отдельно
лучше быть живым параноиком, чем мертвым оптимистом. Я уж не говорю о том, что в случае пересечения той же РФ или США границы - могут попросить показать телефон. Я очень не хотел бы, чтобы там нашли БК и всякие учетки на биткойн биржах.
Что мешает сохранить данные на пару зашифрованных флэшек или положить шифрованный же образ на арендованный сервер, а телефон обнулить или настроить на второй, специально для этого созданный аккаунт, в котором будут только котики и попса?
Например то, что много какой софт (даже не только банковский) на андроиде вы так забекапить не сможете без рута (на iOS чуть получше с этим), вычистить ВСЕ следы конкретных приложений — тоже не факт что обычный пользователь сможет, кроме как полным сбросом.
А второй аккаунт могут попросить показать.
Хотя… меня на контроле максимум просили включить (просто чтобы началась загрузка, проверка что девайс то чем кажется видимо) а не копались.
Но вот границу США у меня не было пока нужды пересекать.
А второй аккаунт могут попросить показать.
Какой аккаунт, гражданин начальник? Вот, всё здесь: котики, переписка с родителями и девушкой, а больше и нет ничего.
В этом и смысл, что граница пересекается с пустым телефоном или с аккаунтом, специально для этого заготовленным, а потом снова сброс, авторизация в основном аккаунте и восстановление всех данных.
Потом, конечно, будет разоблачение, не все пользователи успеют попасться, но конкретным потерпевшим от этого легче не станет.
Всё равно root, таскер и прочее ПО работает с вашими данными и коммуникациями. Тут можно и без банковских приложений бед натворить. Свою карточку вы спрятали, а жене от вас придёт СМС: «Сбил человека, надо ему на Сбер перевести 20 тыс.», ваши же деньги мошенникам уйдут, просто «из другого кармана».
Прошу прощения, помню давно при установке обновления через TWRP для того же Lineage OS мне приходится выводить пароль который я ввожу на экране блокировки.
Загрузчик заблокирован.
Что это, и почему это не защищает от опасного вами?
Телефон зашифрован, а значит что-то прошить можно только после ввода пароля, ну или полностью прошить чистой через компьютер прошивкой. Разве нет?
Это никак не защищает от описанного потому, что с разблокированным загрузчиком злоумышленнику нет смысла пытаться угадывать пароль TWRP — он просто загружает образ TWRP без пароля и шьёт в устройство что пожелает.
Часть статьи как раз описывает что когда мы обычно говорим что устройство «зашифровано», то на самом деле в нём зашифровано всего лишь две директории. Злоумышленник может установить нагрузку в ту часть системы, которая не шифруется FBE
У меня рут стоит для вполне обычных приложений, для которых по какой-то причине нет штатного доступа: синхронизация времени по NTP, бэкапы данных приложений, блокировка рекламы, запись звонков.
Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.
Пишите обязательно. Рут использую как минимум для файрвола (очень удобно срезать рекламу в тех местах, где доступ в интернет не предполагается в принципе, например в оффлайн-играх). Риски, связанные с открытием загрузчика (и наличием рекавери, которое смотрит в мир голым задом), в принципе понимал с самого начала, и принимал как неизбежное зло. Так что возможность закрыть загрузчик обратно со своими ключами была бы кстати.
Спасибо! Надо сделать себе пометку в планы на будущее
Почему в том же TWRP нет возможности пароль поставить, чтобы любой рандом не мог в него загрузиться?
Потому что любой рандом может загрузиться в свой образ TWRP, который пароль спрашивать не будет. И ему не будет важно, а что там за пароль в вашем TWRP.
Именно, просто условный злоумышленник делает fastboot boot unpasswored_twrp.img и игнорирует то TWRP которое установлено в рековери раздел
Что по поводу сделать подписанный загрузчик (и заблокировать систему), а уж он уже загружает кастомную систему не взирая на ее подпись?
Нет сделать круче, носить с собой дополнительное устройство, с которого будет производиться загрузка, т.е. включение выключенного смартфона должно производиться не с той версии twrp что записана на смартфоне, а со своего, гарантированно не испорченного, запускаемого в памяти телефона, а уже оно запрашивает пароль и расшифровывает раздел… можно заодно проверить на модификацию локальный загрузчик, чтобы отсигналить — 'тебя пытались взломать'
p.s. интересно, можно ли это сделать со второго смартфона? обычно установка модификаций android требует десктопный компьютер, хватит ли для этого usb otg и соответствующего кабеля?
Увы, большинство мер по доверенной загрузке и прочим очень низкоуровневым механизмам не относятся к коду самой системы напрямую, их реализует вендор просто ориентируясь на определённый интерфейс в системе с которым будет взаимодействовать. Сейчас эта мера — комплекс всех инструментов реализующих процесс verified boot. Накрутить что-то кастомное — очень сложно, и требует владения железом и драйверами к нему, т.е. фактически невозможно в нынешних условиях
Модель начала 2020 года, достаточно новый китаец.
Похоже на то. Значит их ещё могут и выпускать. Я сам никогда не сталкивался с FDE лично, а почти везде написано что в основном шифрование в андроиде это всегда FBE
но дата раздел зашифрован, доступа нет.
1)если у меня включено FDE, то проверять хеши нужно только в случае если смартфон запрашивает пароль для включения(а не для разблокировки), а не при каждом риске попадания смартфона в чужие руки?
2)Склонировать образ смартфона, установить на другой и сбрутить пароль не получится?
Я не наблюдал сам за работой FDE, поэтому не могу быть уверен на 100% что именно он шифрует внутри. Из того что я прочитал, полагаю что он шифрует раздел userdata целиком, но system и boot также не трогаются, поэтому нам также стоит следить за хэшами в случае временного попадания устройства в чужие руки.
Второе — не получится, потому что шифрование завязано на ТЕЕ. Мы можем склонировать userdata раздел, но тогда брутфорсить нам полное пространство ключей — 2^128. Скорее уж получится локально пробовать подбирать пины, многие люди снижают энтропию на несколько порядков используя части даты рождения или телефонных номеров своих или близких родственников, может повезти
2)спасибо, так и думал, но хотел убедиться.
Хм, может я недопонял вопрос. Тот сценарий который я описал требует перезагрузки устройства, сначала в fastboot, потом в рековери, потом снова в систему. Без перезагрузок ничего сделать не получится, поэтому не выключая смартфон атаку не провести
Всё верно, FDE точно так же шифровал только /data. По поводу перебора, возвращаемся к самому первому включению.
Первое что делает устройство обнаружив пустой раздел /data - генерирует ключ шифрования (увы не помню про сложность/длину и искать не в настроении), которым и будет зашифрована /data, и соответственно "шифрует" пока ещё пустой раздел. Далее, как сказано в статье он заполняется данными. Для хранения ключ шифруется стандартным паролем "default_password", при сборке прошивки вендор может его сменить (не знаю ни единого случая его замены). При установке защиты на экран блокировки - ключ шифрования перешифровывается новыми данными. При этом нет необходимости перешифровывать весь раздел /data.
Спасибо за интерес к статье! Про механику шифрования раздела с данными и "default_password" - хорошее замечание, я не раскрыл этот момент в статье, потому что с точки зрения извлечения данных в сценарии когда у атакующего есть физический доступ это имеет значение только на телефоне без установленной блокировки экрана, а без установленной блокировки экрана злоумышленник и так сможет посмотреть всё что захочет.
А где хранится ключ шифрования?
Допустим я разгрохал телефон в хлам, должен ли я принести в сервис для восстановления информации что-то кроме чипа памяти и пароля от смартфона?
Судя по логике да, т.к. если достаточно только чипа памяти, то все короткие пароли(пин код) можно подобрать переборов.
И тогда возникает вопрос: а вообще можно вытащить информацию, если смартфон ремонту не подлежит?
Есть.
Yellow mode https://source.android.com/security/verifiedboot/boot-flow (заливается СВОЙ Root of trust, им все что надо подписывается, загрузчик лочится)
Но телефон должен нормально поддерживать VerifiedBoot. По сути только Pixel'ы.
Верно. Ещё часть ванплюсов. К сожалению, в настоящее время реализация механизма user settable root of trust является добровольной, а не обязательной для сертификации устройства со стороны Google для компаний производящих устройства под андроид, поэтому почти никто это не делает. Мне бы лично хотелось чтобы большинство устройств имели такую возможность. По сути, это сделало бы устройства на кастомных прошивках одинаково безопасными (и уж точно куда более приватными) по сравнению со стоковыми прошивками от производителя и не было бы необходимости писать эту статью
Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС
Да, надеюсь увидеть статью. Даже имея рут права как класс, грамотно настроив их выдачу можно хорошо обезопасить себя. Но разблокированный загрузчик все портит. О успешном переводе его статуса в yellow слышал только на пикселях.
Спасибо. Для этого необходимо чтобы производитель реализовал поддержку avb_custom_key. К сожалению, это необязательная фича для сертификации и многие ей пренебрегают. Я знаю что такое есть в пикселях, и сам проверял что есть на OnePlus. Возможно кто-то ещё поддерживает, но я об этом не знаю
Ого, неожиданно. Правда вот яндексофоны в продаже найти не так просто
Но это не фича, это бага. Но не Яндекс её фиксить не собирается, не Гугл у них CTS и SafetyNet сертификацию отзываться и не думает. Зато запустить модем мы вам не дадим, юзайте кривой какой дали.
Еще интересно, позволит ли такой статус пройти SafetyNet CTS Profile проверку с hardware-based key attestation, которую сейчас невозможно обойти Magisk Hide. Как например сейчас на Pixel 3a.
С установленным magisk наверное не получится, потому что незачем и наличие рута при заблокированном загрузчике чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять. Однако можно заблокировать загрузчик на альтернативной сборке ОС, той же LineageOS, только надо не полениться собрать её в релизном варианте.
Я вот подумал что можно попробовать вытащить код magiskhide и попроьовать поиграться с ним, либо попробовать адаптировать стороннее решение по аппаратной аттестации. Так например свой аппаратный аттестатор сделан в GrapheneOS (там разработчики большие молодцы и очень заботятся о безопасности), свой аттестатор есть в huawei (им отключили гугл сервисы и приходится выкручиваться)
Отчасти поэтому и возникла вся движуха с root правами. Действительно, глупо отрицать что гугл не выжимает по максимуму пользовательских данных из устройств на своей ОС, однако суть статьи — просто показать что у альтернативных решений есть свои проблемы
Поэтому Android — это не Linux, как Вы написали в статье.
В GNU/Linux незашифрованный/разблокированный только раздел под загрузчик (если исходить из настроенной безопасности), например под GRUB (иначе, например, старенький BIOS не поймет как загружаться). Однако этот раздел легко захэшировать (не только файлы в тч и свободное пространство) и сверять хэш при загрузке. И если, что-то злостное дописать в раздел загрузчика, хэш не совпадет. После обновления GRUB/системы, просто вручную перехэшировать раздел и все.
С Android такое не прокатит по многим причинам, основная причина, что Транснациональной корпорации — такой бизнес не выгоден и понять их можно.
у альтернативных решений есть свои проблемы
И 'всюду' навязано мнение, что Root — это уязвимость/плохо/компрометация (Гугл с задачей по перестройке сознания масс справился хорошо).
Рассмотрим другую ситуацию. Телефон не разблокирован. Производитель забил на обновления. Баги копятся и множатся. Установив приложение из GooglePlay уже существует риск нарваться на малварь, которая поднимет себе права до root через эксплоит.
Кроме того открываются векторы атаки через RCE. Вплоть до 0-click RCE, когда от пользователя вообще ничего не зависит. И единственный способ этого недопустить — это альтернативная сборка с фиксами. Ну или смена всего телефона на новый.
Существует (теоретически) прекрасный способ избежать всех вышеописанных проблем. Сделать возможной установку пользовательских ключей. Примерно таким же образом, каким сейчас происходит разблокировка (заметим, ещё не создано ни одной малвари, которая способна была бы самостоятельно разблокировать телефон. Это почти невозможно. По целому ряду причин).
Именно полноценная установка, а не прописывание в vbmeta. С прожиганием альтернативы во фьюзы, и проверкой всей цепочки. Это всё ещё не даст пользователю доступ в TrustZone, а значит не угрожает DRM.
Осталось только заставить производителей реализвать такую возможность. Право на безопасные EOL обновления. (Типа права на ремонт.)
>> а моём стареньком смартфоне с android 9
что ж это за старенький смартфон такой? 9ка это конец 2018 года ЕМНИП. Т.е. смартфону должен быть год-полтора.
Спасибо! Я пока не достиг кунфу для внедрения в ядро, но может быть разберусь в этом в будущем. Читал что в начале 2010-х существовали зловреды которые внедряли свой модуль ядра и организовывали свою работу через него.
Согласен насчёт того что часто альтернативные сборки решаютв ситуациях когда вендор забросил девайс. Например Xiaomi mi4 вендор забросил, не соврать бы, на android 6, а LineageOS поддерживают его аж до 16 версии (android 9), и всё это силами энтузиастов.
Насколько я понимаю, user-settable root of trust даёт всё то же что и полноценная ОС с embedded root of trust. Ну, только желтую предупреждающую плашку показывает на 10 секунд при запуске. Есть какие-то подводные камни? Мне кажется главный головняк с «желтым» загрузчиком — это собирать обновления руками.
Наверное я употребил слово «старенький» с оглядкой на темпы выхода новых версий ОС. Девайс — Huawei honor 9, в 2018 году брал
Справедливо. Никакой свой код в первичном загрузчике и в том что работает в ARM TrustZone без embedded ключа запустить не получится, разумеется.
Тем не менее «желтого» состояния достаточно чтобы при физическом доступе нельзя было загрузить рековери образ или поменять что-либо в read-only разделах.
Мой с 9 андроидом уже более 2х лет используется. Причём телефон мог выйти до релиза 9, а затем обновиться.
Варианты с прожиганием фьюзов тоже есть. Ищите модель, у которой в подписях тестовые ключи (строки “General use test key” в сертификатах). Не имею свежей статистики, но точно видел такое в нескольких моделях BQ на MSM8937. Можно одним махом скачать какой-нибудь «сборник firehose загрузчиков под разные модели» (есть такие) и позаглядывать им в подписи на предмет всё того же “General use test key” (либо полного отсутствия подписей).
Если уже что-то записано во фьюзы, то нельзя. Лет 5 назад еще были телефоны с невключенным SecureBoot и чистыми фьюзами под ключи. Сейчас таких практически нет.
Где test key — там не настраивали secure boot и фьюзы пустые (при сборке в любом случае всё подписывается, какой-то ключ должен быть, вот по умолчанию этот тестовый и генерируется, но во фьюзы он сам не попадёт, для этого нужно в явном виде сгенерировать и прошить образ fuseblower). Однако, как уже написал vm03, сейчас такого совсем мало (Qualcomm активно давил на лицензиантов чтобы те не забывали включать secure boot), но и с user-installable ROT, как пишут, вариантов немного. Хотя есть ещё не-Qualcomm платформы, где с secure boot бардак (UniSoC в Alcatel например), но то на любителя :)
что ж это за старенький смартфон такой? 9ка это конец 2018 года ЕМНИП. Т.е. смартфону должен быть год-полтора.Ну вот у меня nexus 5 2013 года. К нему есть Lineage на базе 10(!) андроида. Не знаю, на сколько она ей там хорошо живется, не проверял. У меня стоит на базе 8го. Вполне нормально работает.
Производители телефона могли бы сделать возможность пользователю установить пароль на режим отладки в параметрах разработчика.
Разблокировал параметры разработчика, включил режим отладки — система просит установить пароль. Теперь при подключении устройства в режиме загрузки надо ввести пароль.
Таким образом пользователи могут получить рут и защищены от установки бэкдоров.
Если не ошибаюсь, сейчас для запуска режима отладки нужно вводить код разблокировки. Проблема в том что это тот же самый код разблокировки, которым открывается экран после того как смартфон вышел из режима сна. Если злоумышленник знает его, то и adb запустит.
Тут ключевая мысль всё таки в разблокированном загрузчике. При таком подходе заходить в режим отладки не обязательно чтобы подкинуть в систему проблем
Начнём с того, что если у вас нет root прав на устройстве, то вы не являетесь его хозяином. Это нужно чётко понимать. Устраивает вас ошейник (а без root прав это именно ошейник и ничто иное) или нет — решать вам.
Посыл «современный смартфон защищён» является так называемой ложной альтернативой. Вам продают идею о защите от гипотетического злоумышленника и его возможных действий в будущем, уже сейчас осуществляя полный доступ к вашим данным и всем вашим действиям на устройстве (конечно же «для вашего блага»).
Ну и здравый смысл подсказывает, что в любой экстремальной ситуации не смартфон, а вы являетесь слабым звеном — вы сами отдадите и смартфон и любые пароли к нему.
И последнее: хранить критические данные на «пластмассовом обмылочке» который вы всегда и везде носите с собой — это не лучшая идея в принципе и если вы ещё этого не поняли, то вам нужно ещё немного поразмышлять на эту тему.
Я очень ценю и уважаю приватность и желаю чтобы большинство устройств могли обеспечить её на высочайшем уровне. Я очень люблю кастомные прошивки, довольно много их ковырял и подпиливал под себя, я считаю очень важным их существование и бесконечно благодарен сообществу, которое их развивает. Я как никто другой понимаю то о чем вы говорите, иначе этой статьи просто не появилось бы. Я согласен с вами, просто суть статьи немного не в этом.
Суть в том что в интернете полно статей которые рассказывают про root и альтернативные прошивки, но не рассказывают про обратную сторону их наличия на устройстве. Многие люди насмотревшись на громкие лозунги и красивые картинки с «мужчиной в масочке с усиками» с радостью освобождают свой смартфон, но с точки зренич довольно популярно модели угроз (физическое изъятие) делают его намного более уязвимым чем он был до освобождения. Посыл статьи — рассмотреть ситуацию со всех сторон и дать понимание о том что у освобождения есть минусы, о которых нужно помнить чтобы не создать себе лишних проблем
Но если у тебя хватило понимания необходимости освобождения и квалификации, чтобы установить альтернативную прошивку — то уж возможные риски разблокировки загрузчика для тебя должны быть очевидны.
если у вас нет root прав на устройстве, то вы не являетесь его хозяином
Смелое утверждение. Что именно подразумевается под «являться хозяином» и «не являться хозяином»? Каким образом предоставление устройства as is, без полного доступа к системе, лишает вас статуса его хозяина? Устройство поставляется как изделие с некими потребительскими свойствами, и root-доступ в их число не входит. Вы можете самостоятельно увеличить число потребительских свойств, но это уже ваше личное дело. Например, двигатель современного автомобиля не позволяет вам, как раньше на Жигулях, в гараже расточить цилиндры или внести ещё какие-нибудь подобные изменения в его низкоуровневую конструкцию, но это же не значит, что автомобиль вам не принадлежит?
Продолжая логику: если корпус устройства запаян и вы не можете его развинтить, то вы не являетесь его хозяином.
Каким образом предоставление устройства as is, без полного доступа к системе, лишает вас статуса его хозяина?
То, что не я(владелец) решаю какое ПО запускать на моем компьютере(смартфон это ж тоже компьютер). А производитель решает, какое ПО я могу запустить.
Еще одна(пусть и немного кривая) аналогия из мира авто. Это как если бы производитель авто указывал мне, кого я могу везти и в своей машине и кому передать руль. Современные смартфоны это как машины на которых можно перевозить пассажиров только из одобренного производителям списка, а управлять машиной может только водитель с разрешением от производителя машины.
Как минимум знать что делает ваш телефон и возможность управлять им.
>но это же не значит, что автомобиль вам не принадлежит?
А теперь представьте, что при покупке в салоне вы обязаны подписать договор (иначе автомобиль вам просто не продадут) по условиям которого: а) автомобиль может уехать в любое место в любое время не спрашивая хозяина б) свойства автомобиля, количество кресел, наличие руля, кондиционеров и подлокотников может быть изменено производителем в любую секунду не уведомляя вас об этом в) производитель автомобиля и некие третьи лица получают полный 24/7 доступ ко всему, что происходит внутри автомобиля с помощью 10 установленных веб-камер и 20 микрофонов г) так же вы обязаны просматривать рекламу на лобовом стекле.
Именно это сейчас представляют из себя смартфоны без рута, если проводить аналогию с авто, а не стачивание гаек на цилиндрах. Да, у вас в руках есть некая болванка с набором функций компьютера, но по решению левой пятки гугла/эппла эта болванка через запушенный ими в фоне апдейт может превратиться в кирпич.
Например я в audi не могу добавить свежую карту - автомобиль её не принимает. т.к. "закончилась лицензия". Производитель "бесплатно" разрешил 5 обновлений и всё. Хотя законы РФ считают, что я собственник авто.
У меня по прочтению появилась папа вопросов:
- Пароль в twrp сможет предотвратить инъекцию?
- Может ли теоретически сам магиск предоставлять дополнительную защиту от инъекции чужого когда, как написано в статье?
Вообще было предельно понятно, что разблокировка позволяет делать с устройством практически все, если его можно взять в руки. Но тут что на что меняем, имхо рут и возможность удаления всякого говна от производителя гораздо лучше гипотетической потери аппарата с личными данными, ибо эти данные есть не на каждом аппарате, а вот приложения — везде
- К сожалению нет. Именно поэтому в официальную TWRP и не вводят эту функцию. Разблокированный загрузчик позволит просто проигнорировать запароленную TWRP и загрузить вместо неё свою, незапароленную через fastboot boot img.img
- Теоретически мы сможем также вырезать эти проверки из исходников magisk.
Думаю каждый решает сам для себя что важнее. Опять же, на пикселях и ванплюсах мы можем прописать свои ключи для проверки avb и эта атака работать не будет
Хорошие описание безопасности андроида(не без неточностей для упрощения), но вот это резануло:
LineageOS, не включают в пакеты обновления ядро,
LineageOS всегда включает в себя ядро и обновляет его при каждом обновление. Это одна из причин почему LineageOS безопаснее стока в реальной эксплуатации, большинство мантейнеров оперативно закрывают уязвимости в ядре.
Ну и непонятно, зачем столько возьни(что-то пишем в system, патчим политики selinux и тд), если вы меняете boot. Добовляете свой код в ядро и ваш код выполнятется на уровне выше, чем весь андроид, делайте что хотите.
Ну и в целом ситуация когда безопасность современных смартфонов завязана на ключ производителя устройства и владельцем не контролируется мне очень не нравится, производитель может пихать в прошивку любую блотварь, а владелец устройства делать нечего не может, кроме как ставить дополнительное по.
На своём ноутбуке(и десктопе)(и таких пока вроде большинство) я могу добавить свои ключи для SecureBoot, и даже удалить все предустановленные ключи, оставив только свои.
На смартфонах удалить ключи производителя удалить нельзя негде, на очень редких можно добавить свой avb ключ(и то это будет yellow режим), смартфонов где можно сделать unlock становится все меньше. При этом на современных квалкомах, прошивку модема(которая работает с большими привелегиями, чем андроид) можно запустить только подписанную производителем.
Ну и кроме блотвари, производители умудряются делать такие дырищи в своих прошивках…
А всякое банковское ПО считает эти 5 лет необновленные с кучей известных и неизвестных дыр безопасными, а кастом с исправлениями всех известных уязвимостей настолько опасным, что отказываюися работать.
производитель может пихать в прошивку любую блотварь
Не «производитель может пихать в прошивку любую блотварь», а сама прошивка является одной большой «блотварью».
Спасибо за отзыв!
Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды, может быть получится в дальнейшем развить тему статьи в сторону модификации ядра, но пока могу только так. Разумеется, злоумышленнику выгоднее работать напрямую из ядра, так меньше торчит флагов компрометации в системе.
Ситуация с невозможностью контролировать устройства это действительно проблема, думаю, последний десяток лет уже. В андроиде всё особенно тяжело, т.к. даже на альтернативной сборке и со своими avb ключами остаётся целая куча пропиетарных компонентов от производителя без оторых устройство просто не сможет работать.
Насчёт поставки ядра с LineageOS — не знал. На мои устройства приходят обновления только system и vendor образов. Можете пожалуйста ткнуть меня в ссылку где это описано? Исправлю в тексте статьи
Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды
С учетом, что ядро "универсальнее", чем юзерспейс андроида, думаю найти готовую "вредоносную нагрузку" для ядра будет не сложнее.
На мои устройства приходят обновления только system и vendor образов
Берем свежие lineage-17.1-20210202-nightly-dumpling-signed.zip и lineage-17.1-20210204-nightly-sagit-signed.zip с download.lineageos.org и смотрим что там:
$ unzip -l lineage-17.1-20210204-nightly-sagit-signed.zip
Archive: lineage-17.1-20210204-nightly-sagit-signed.zip
signed by SignApk
Length Date Time Name
--------- ---------- ----- ----
299 01-01-2009 00:00 META-INF/com/android/metadata
5208 01-01-2009 00:00 compatibility.zip
552698230 01-01-2009 00:00 system.new.dat.br
0 01-01-2009 00:00 system.patch.dat
131506390 01-01-2009 00:00 vendor.new.dat.br
0 01-01-2009 00:00 vendor.patch.dat
2093472 01-01-2009 00:00 META-INF/com/google/android/update-binary
1630 01-01-2009 00:00 META-INF/com/google/android/updater-script
15396864 01-01-2009 00:00 boot.img
1028 01-01-2009 00:00 install/bin/backuptool.functions
2233 01-01-2009 00:00 install/bin/backuptool.sh
7632 01-01-2009 00:00 system.transfer.list
1870 01-01-2009 00:00 vendor.transfer.list
1342 01-01-2009 00:00 META-INF/com/android/otacert
--------- -------
701716198 14 files
unzip -l lineage-17.1-20210202-nightly-dumpling-signed.zip
Archive: lineage-17.1-20210202-nightly-dumpling-signed.zip
signed by SignApk
...
18523432 01-01-2009 00:00 boot.img
...В обоих прошивках присутствует boot.img. Ну что бы убедится, что он не просто лежит, смотрим META-INF/com/google/android/updater-script и там есть:
package_extract_file("boot.img", "/dev/block/bootdevice/by-name/boot");То есть boot вполне себе прошивается при установке этих zip.
Ну и вот исходники из которых ядро и рамдиск собирается при каждой сборке (вот именно прям из этих на github)
https://github.com/LineageOS/android_kernel_xiaomi_msm8998
https://github.com/LineageOS/android_device_xiaomi_msm8998-common/tree/lineage-17.1/rootdir
Тут конечно не все, что попадает в рамдиск, но если захотите поэксперементировать с собственным boot.img будет полезно.
остаётся целая куча пропиетарных компонентов
Меня сейчас больше даже не это (это тоже, но меньше, сейчас систему без блобов сложно найти) бесит, а то что производитель, а не я решает что можно запустить на купленном мной устройстве. Я например не могу запустить, пусть с блобами, но свою прошивку модема. Вот есть например Яндекс.Телефон, на поддержку которого Яндекс забил, и есть в нем бага в прошивке модема, которая приводит к зависанию модема при работе с Теле2. И вот на руках полностью рабочее железо, но пользоваться полноценно им нельзя. И нечего с этим не сделаешь, запустить "модем" можно только подписанный производителем.
PS: Не знаю не одного устройство на которое бы LineageOS собиралась бы без boot. И одно из обязательных требований для включения устройства в "официальные сборки" LineageOS, это сборка ядра из исходного кода https://github.com/LineageOS/charter/blob/master/device-support-requirements.md#kernel
Изоляция приложений обходится внедрением кода в сами приложения. Например, если в приложении есть логин или реклама от Фейсбука или Гугла, то вся активность пользователя сливается в аналитику. Сбор аналитики от Фейсбука даже нельзя отключить.
Это самый простой вариант из возможных, но самый «не тру» для настоящих энтузиастов кастомного android. Если скомбинировать его со способами выключения предустановленных системных приложений описанных в недавней статье, то вполне может получиться неплохо.
У меня на одном из старых телефонов не только весь подобный хлам был установлен, но даже прошиты уникальные UUID устройства для трекинга для facebook, yandex и сбера. Прошиты прямо build.prop, прямо в /system, прямо на этапе сборки системы производителем. Из можно было увидеть через вызов getprop.
З.Ы. Дата для добровольно принудительного внедрения отечественного ПО выбрана таки знаменательна
Если вы про flash-память, то неясно, как вам поможет удаление предустановленных приложений. Они предустанавливаются в /system, а не в /data, от их удаления у вас места не прибавится (если только вы не хотите что-то своё напихать в /system, но не думаю, что вы этого хотите).
С самого рожения андроида /system — отдельный readonly раздел. Собственно поэтому factory reset сводится к глупому форматированию /data, ни системные, ни тем более загрузочные файлы не страдают (и поэтому ресет не спасет от полученных через рут червей).
Хорошая статья с кучей технических подробностей, однако тема очевидная. Имея разблокированный загрузчик, всегда можно прошить кастомное рекавери, а через него zip с любым содержимым. Тем не менее, не думаю, что у пограничников или полицейских есть специалисты, способные сделать это, так что риск небольшой.
Лично я не представляю, как можно пользоваться телефоном без рут-прав, когда ты по сути не хозяин своему смартфону.
Вопрос к знатокам — можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки? Ну например, при первом включении вводим сложный пароль, который не получится подобрать, а при разблокировке экрана простой графический ключ?
Лично я не представляю, как можно пользоваться телефоном без рут-прав, когда ты по сути не хозяин своему смартфону.
Мне например не нужны root права на андроиде в их "классическом понимании", то есть мне не нужны приложение android запущенные c uid 0. Но я хочу запускать на смартфоне, то что хочу я владелец, а не его производитель.
можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки?
Стандартно пин(или пароль) для расшифровки и разблокировки экрана одинаковый, и не видел, что бы где-то было сделано по другому. Но технически это сделать очень легко (пару файлов по пять строк на вскидку поправить), поэтому подозреваю, что есть веские доводы почему это бесполезно.
Плюсану, хоть меня тут могут и закидать помидорами. Разумеется, это вопрос личных предпочтений, но для меня единственный инструмент работающий от рута, который я прям уважаю и никак не могу без него если всё-таки накатываю что-то на устройство это afwall, потому что это просто обёртка над iptables (хотя netguard тоже неплох если нужно обрубить доступ в сеть приложениям которым это явно не требуется для работы). Ещё раз, это ИМХО, но я могу для всех остальных задач использовать не требующие рута приложения
Del, прочитал ниженаписанное
Спасибо! Тема действительно очевидная, но почему-то довольно непопулярная. Я хотел привлечь внимание к тому что пользуясь рутом или альтернативной сборкой ОС нужно помнить о дополнительных возможностях которые появляются у атакующего с физическим доступом. Предупрежден — значит вооружен
Тем не менее, не думаю, что у пограничников или полицейских есть специалисты, способные сделать это, так что риск небольшой.
Забыл добавить такую мысль — разблокировкой загрузчиков занимается ничтожно малая часть пользователей смартфонов, так что вряд-ли где-то будут проверять каждый смартфон на предмет такого доступа, даже если будет техническая возможность.
Вопрос к знатокам — можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки? Ну например, при первом включении вводим сложный пароль, который не получится подобрать, а при разблокировке экрана простой графический ключ?
В LineageOS это делается одной командой в терминале (при наличии прав суперпользователя)
Для остальных прошивок есть github.com/nelenkov/cryptfs-password-manager
А команду подскажете?
vdc cryptfs changepw TYPEOFNEWPASSWORD OLDPASSWORD NEWPASSWORD
Where type of password can be:
password
pin
patternTYPEOFNEWPASSWORD — какую клавиатуру предоставлять при вводе пароля (полноценную, цифровую, либо графический ключ)
если выбрать pin, но задать пароль, содержащий не только цифры, то ввести его при загрузке вы не сможете :)
OLDPASSWORD — текущий пароль (обычно совпадает с паролем блокировки экрана)
перед этим следует, естественно, выполнить команду su
терминал сгодится любой, хоть встроенный в LOS, хоть из маркета
Спасибо!
А если стоит графический ключ, что вводить в OLDPASSWORD?
И нет ли риска сделать так, что потом не получится ввести этот пароль?
К тому же, утилита имеет больше «защит от дурака», чем команда в терминале.
Вот у меня есть древний Самсунг аж 2012 года i9260, на нем древний Андроид 4.1 что-ли. Он валялся у меня с 2015го. Неделю назад я расчехлил его и обнаружил, что не могу поставить на него даже актуальный 2gis — устанавливается что-то старое, без актуальных организаций. А куча приложений в сторе так вообще не отображается. Андроид видите-ли старый. Контроля над этой ситуацией у меня фактически нет. Я не профессионал какой-то. Телефон можно просто в мусор отправлять, потому-что на нем только мессенджеры актуальные запускаются, а из браузеров только китайский UCbrowser новый. C компьютерным железом это просто дикость бы была (ну кроме техники Apple).
Жду исков от Евросоюза.
Вот условно ноутбук. Я могу установить туда любой линукс или даже Windows XP, а то и хакинтош
Вроде было несколько ноутов (но и то это большая редкость), где можно запустить только ОС подписанную Microsoft и нет возможности управлять ключами SecureBoot. Но и то, я не слышал такого, что бы например на ноуте HP, можно было запустить только Windows от HP и никакую другую (даже на макбуках можно запускать и linux и windows). А на смартафонах это не то что норма, это поголовно сейчас, производитель, а не владелец решает, что можно запустить.
Что же касается макбуков, то после примерно 2015 года там всё нетривиально, если вообще возможно.
Боюсь чтобы выбраться из этой ситуации нам нужно куда больше популяризировать и развивать OpenHardware. В ближайшее время вряд ли что-то фундаментально изменится
del
свободы, которую android предоставляет пользователям, однако не все распоряжаются ей правильно
Власть машин пришла. Obey our iron will you filthy human.
Статья весьма познавательна в качестве обзора систем безопасности android, а за одно — и некоторые сведения про работу magisk. Автору огромный респект, хабр — торт!
При этом остаётся интересным момент — против чего именно все эти ухищрения со стороны Google? Во-первых, если данные остаются в расшифрованном виде после первой разблокировки — это же почти ни о чём (при изъятии устройства успеть его выключить?). Во-вторых — физический доступ к устройству не похож на типичный сценарий взлома для >99% пользователей, а тем, кому его стоит опасаться, всё равно нужно придерживаться правила "физический доступ к устройству означает его компрометирование".
Спасибо! Это много значит для меня. Хабр для меня всегда был ресурсом где люди делятся по настоящему интересными техническими статьями и любят погружаться в детали. Я постарался соответсвовать этому.
Данные действительно остаются расшифрованными всегда после первой разблокировки. Это может быть опасно если включён режим отладки и adb. В этом случае можно вытащить файлы из общего хранилища которое всегда доступно через adb shell. К слову, у наших коллег из iOS операционная система уничтожает ключи в памяти спустя некоторое время неактивности, а при вводе кода разблокировки расшифровка файловой системы будет произведена заново. Может быть и нам подобное завезут в грядущих обновлениях. Вообще, вход в систему нам защищает необходимость ввести код разблокировки, разблокировкой системы управляет сервис gatekeeper, который работает через аппаратный TEE, и запись флагов в RPMB. Gatekeeper ведёт счётчик неправильных последовательно введённых кодов разблокировки и увеличивает таймауты между попытками ввода, обмануть их ни через перезагрузки устройства, ни через брутфорс через рекавери не получится, всё реализовано очень надёжно. Я для интереса попробовал и не смог найти никаких подходов. Терморектальный криптоанализ в данном случае не рассматриваем.
Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.
Основной посыл статьи был не столько про реальность сценарий атаки, сколько про то что о пользе разблокировки загрузчика пишут много, а о минусах — мало. Хотелось разобрать ситуацию и с непопулярной точки зрения
Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.
Так в этом случае, как раз наоборот заблокированный загрузчик не дает возможность сделать точную копию критических данных.
Дабы положить эту копию в зашифрованный контейнер и потом добавить стеганографию, ну и например обозвать этот криптоконтейнер, как видеофайл «любимые кошечки». Или скопировать копию в облако.
А на телефоне минимальная копия с официальными контактами.
Нам нечего скрывать=).
А заблокированный загрузчик вынуждает все критические данные хранить на телефоне.
Очистка ключей после блокировки уже есть как минимум на Huawei и Samsung, у обоих зовётся SDP, принцип работы — один в один как в iOS (очищаемый симметричный ключ + ECDH ключ для файлов, создаваемых после блокировки). У Samsung вот описание есть: https://docs.samsungknox.com/admin/whitepaper/kpe/sensitive-data-protection.htm
Вот только вопрос — сколько приложений умеют этим пользоваться? В общем случае нельзя просто очищать "традиционный" CE-ключ (приложения, не готовые к такому, упадут), в API вводится отдельный тип хранилища, и общего стандарта, как понимаю, пока нет.
Самсунги вообще крепко заморачиваются с безопасностью, и для многих нововведений являются локомотивом. Я читал про то что они используют отдельные расширения ядра для защиты от модификации и в установщике magisk даже есть отдельные патчи именно под самсунги, как раз видимо для подобных случаев. Именно с подачи самсунга в android был введён SELinux, Google перетащили его в основную кодовую базу именно посмотрев на самсунг
Информация интересная и полезная, но use case ИМХО надуман.
Спасибо. Ну, в некотором смысле наверное оно так. Все знают что разблокированный загрузчик несёт проблемы, но кейсов которые бы поясняли «на пальцах» что именно можно сделать в этом случае совсем немного
Теоретически, разблокированный загрузчик даёт преимущества и удалённому злоумышленнику. Если тот сможет получить root локальным эксплоитом (такое бывает очень редко, но всё таки), то он сможет вносить в систему изменения не боясь вызвать срабатывание verified boot и окирпичивания устройства, но всё же максимум возможностей получает локальный атакующий с физическим доступом к устройству
Автору спасибо за статью, интересная тема, сам являюсь обладателем смартфона от компании xiaomi, с разблокированным загрузчиком и мода ос от xiaomi.eu. Давно интересовал вопрос безопасности такой сборки и как оказалось не зря, вектор атаки понятен и очевиден.
Однако хочу предложить ещё один вариант решения, в копилочку. У меня на устройстве после обновления ос штатным приложением всегда остаётся полный образ последнего обновления, в разделе юзердата, с проверенным мд5, так что теперь, если кто-то изымет у меня утройство, сразу после возврата, грузимся в тврп и шьем последнее обновление, и вуаля, после загрузки у нас чистая система и можно без опаски разблокировать телефон. (появляется вектор атаки на тврп и его модификации, чтобы он в конце дошивал мидлварь, но в такой связке может помочь пароль на тврп)
Естественно перед тем как отдать телефон погранцам, зажимаем кнопку выключения, чтобы телефон ушел в ребут и не получилось считать ключи из памяти. Ну и выключаем отладку usb и тд
в такой связке может помочь пароль на тврп
Как уже выше неоднократно отметили — не поможет, ибо банальный fastboot через USB загрузит любой кастомный тврп без всяких паролей
Сразу видно, то вы не внимательно читали мой комментарий, я предлагаю комплекс мер, то есть, если грузится тврп без пароля, то аппарат скомпрометирован, не включаем до прошивки нового тврп, если тврп с вашим паролем, то накатываем систему из образа с раздела юзердата.
Между прочим в моём TWRP установка пароля в принципе отсутствует. Не подскажете откуда её взять?
Хотя в любом случае по-моему проще просто перепрошивать тврп каждый раз, а то иначе полумеры какие-то.
Спасибо! Похожий трюк с сохранением последней рабочей конфигурации делает, например, сам magisk. Только он так сохраняет лишь boot и dtb* разделы. При удалении — шьёт их на место чтобы всё было как на немодифицированной системе.
А ещё так делает сам андроид. Механизм который вы описываете очень похож на систему обновлений с A/B разделами, которая есть на большинстве современных устройств. Там разделы дублируются и обновление устанавливается только на один «слот» из двух, а второй остаётся неизменным, чтобы иметь возможность откатиться на него в случае если обновление поломает работу системы.
Теоретически, мы можем «откатиться» на резервный слот после того как устройство побывало у злоумышленников, однако злоумышленник может накатить нагрузку в оба слота сразу
Я может не правильно выразился, но в образе лежит полная система, 2.8гб в моем случае, мы ее накатываем после того как аппарат побывал у кого-то "не надежного" и попадаем в рабочую и чистую систему, следующее обновление затрет второй слот "скомпроментированной системы" в слоте B. (если были скомпрометированы оба слота)
У меня так после каждого обновления magisk исчезает)))
Наверное дурацкий и все же философский вопрос вертится на языке, что же, в данном случае, хуже-то с точки зрения секьюрности: такие вот свежие современные, но рутованные смартфоны с LineageOS и разблокированными загрузчиками или что половина страны все еще ходит со смартами купленными в бородатых годах (интернет, ватсап, вконтакте и Сбер работают, фоточки в инстаграм выкладываются, да и ладно). Которые до сих пор на 4х — 8х стоковых, но уже определенно устаревших версиях Андроида без каких-либо даже призрачных шансов на очередные critical security update?
Спасибо большое!
Современные устройства, на мой взгляд, однозначно будут менее подвержены разным зловредам, т.к. получают регулярные обновления безопасности. В общем-то, я не призываю отказываться от LineageOS, это отличная альтернативна стоковой прошивке для тех кто хочет большей приватности. Статья про то, что пользуясь ей нужно помнить о появлении дополнительного рода угроз и стараться не допускать попадания устройства в чужие руки
Вот будет там стоять сертификат от фсб, по аналогии с казахстаном, предустановленный.
И без рута хрен выпилишь.
Так что только рут, в новых телефонах, только полная зачистка.
Честно говоря, не слышал о том что по вышеупомянутому закону планируется устанавливать дополнительные корневые сертификаты, но не удивлюсь если им очень сильно захочется попытаться это сделать.
Я видел патч для сорцов андроида, который удаляет из системного хранилища некоторые корневые сертификаты китайского происхождения, автор уверяет что они используются для МИТМов. Уверен, что если кто-то подкинет эту идею нашим органам, то она им очень понравится и они постараются её претворить в жизнь
Я правильно понял, что даже после первого ввода пароля при включенном шифровании памяти и отключенном usb adb, разблокированным загрузчиком, установленными всевозможными рутами и пр. злоумышленник «прямо сейчас» не получает доступа к данным, если не взломает экран блокировки?
А то что дальше по статье, как я понимаю, фиксится достаточно просто: после получения телефона обратно, нужно не разблокируя перезагрузить в свой образ twrp через fastboot, зашить свой twrp, вдруг его тоже заменили. Затем загрузиться в него, зашить заново ту же ОС, что и стояла ранее (перезапишутся /system и /boot), поставить magisk и вроде как все…
А то что дальше по статье, как я понимаю, фиксится достаточно просто: после получения телефона обратно, нужно не разблокируя перезагрузить в свой образ twrp через fastboot, зашить свой twrp, вдруг его тоже заменили. Затем загрузиться в него, зашить заново ту же ОС, что и стояла ранее (перезапишутся /system и /boot)
Да, такой подход решает проблему, но требует ковыряния руками, что не каждому захочется делать. Как я упоминал, суть статьи не в том, чтобы не пользоваться альтернативными сборками ОС, а в том, чтобы не забывать что их использование несёт дополнительные риски, о которых необходимо помнить.
Да, злоумышленник получает доступ только после того как владелец сам введёт код разблокировки устройства. Без этого никак — хранилище будет зашифровано до первого ввода кода
Ну и замечательно. То есть выходит по факту не все так плохо.
Даже если хранилище расшифровано предстоит как-то поломать экран блокировки (причем не перезагружая телефон), чтобы добраться до данных.
Заглянул вот в документацию:
https://source.android.com/security/encryption/file-based?hl=en
Пишут вот такое:
For new devices running Android 10 and higher, file-based encryption is required.
Спустя больше года, вспомнил вашу статью, решил перечитать. У вас написано, что при включенной отладке ADB в состоянии "после ввода пароля" нет сложности подключить к ПК и достать данные, но что по поводу защиты самого ADB от несанкционированного доступа?
При подключении к новому ПК телефон всегда запрашивает разрешение отладки с открытым ключом ПК, пока запрос не подтвержден и если его отклонить/проигнорировать, то девайс будет висеть в состоянии "не авторизован" без доступа к нему.
Это не всегда. к примеру на redmi note 4x такой защиты ещё небыло.
Привет. Спасибо за интерес к теме. В целом да, на современных устройствах adb будет требовать подтверждения взаимной аутентификации по ключам, но я бы сказал, что оставлять открытым adb - всё равно плохая идея. Думаю что это можно обыграть, по крайней мере в части случаев.
На ум сразу пришёл как минимум один сценарий. Допустим владельцу устройства устроили "маски-шоу". В подобных ситуациях изымаются для следствия абсолютно все личные устройства в которых физически может храниться информация - компьютеры, ноутбуки, планшеты, телефоны, и т.д. Ключи adb хранятся в домашней директории пользователя (~/.android/adbkey, ~/.android/adbkey.pub). Соответственно, если получить доступ к этим директориям на машине с которой подключались, то можно их закинуть на машину атакующего и устройство будет считать что adb shell запрашивает уже знакомый компьютер. А дальше вступают в работу стандартные инструменты для форензики.
Xiaomi Redmi Note 8T. До этой статьи я плевался из-за того, что телефон до ввода пароля разблокировки ничего не принимает и никаких уведомлений не показывает. Похоже, FBE и BFU-AFU в этом устройстве тоже организованы.
В системе существует API DirectBoot, которое позволяет запускать приложения до расшифровки хранилища. Это нужно для будильников, звонилок, и т.д, но все обычные приложения до расшифровки файловой системы работать не могут
Но есть одно «НО», если злоумышленник (на той же границе) получил телефон в руки, кто ему мешает установить root, да займет времени чуть больше, го если процесс налажен (а возможно и автоматизирован " спецами", ведь не сами же таможенники это придумали), то процесс установки рута может так же занять считанные минуты.
Спасибо большое за статью!
У меня есть два вопроса:
1) Что, если мы ломаем возможность корретной работы TWRP? Разработчик OrangeFox (форк TWRP) делал такую фичу. Но! У меня только черный экран был. ADB я не проверял. И OrangeFox имеет в себе возможность установки пароля. Но при условии, что TWRP спокойно грузится из-под Fastboot и ADB в сломанном варианте работать будет… То беда.
2) Что делать, если TWRP может быть загружено без разблокировки? Или по факту это не дает возможность взлома?
И спасибо за методы защиты. Единственное, что получается последним железным вариантом защиты это написания кастомного загрузчика (aboot), в который каждый раз при загрузке надо вводить пароль как на BIOS/UEFI?
И еще.
Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.
Я бы с удовольствием прочитал про это. И если б была возможность, я бы попробовал сделать это у себя. Жаль, что у меня это работать вероятно не будет… Бедный мой mido)
Еще раз спасибо за статью!
P. S. Прошивка CarbonROM, которую в данный момент времени я сопровождаю, не собирает userdebug. Только user.
1. Увы, разблокированный загрузчик даёт злоумышленнику возможность не полагаться на текущее установленное рековери. Он просто загружает и использует своё.
2. В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно. К тому же, наличие заблокированного загрузчика не даст загрузить систему после внесённых изменений, aboot будет падать в «red state» и откажется загружаться.
Насколько я понимаю, повлиять на aboot мы не можем, он зашивается в девайс и его целостность проверяется при загрузке ключом из TEE, мы можем начинать устраивать какие-то махинации, но только с запуска ядра, aboot работает раньше.
По поводу user-settable root of trust. Это точно возможно на пикселях, ванплюсах, и, как подсказывают камрады в комментариях, яндексофонах, на остальных — маловероятно.
В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно
В природе встречались телефоны от Xiaomi приходящие из Китая с заблокированным загрузчиком и кастомной сборкой тврп вместо стокового рекавери (иногда там ещё был кривой мод китайской прошивки с недоруссификацией). Ну и в качестве исторической справки, сейчас наверное неактуально, какое то время назад рекавери интегрировалось или в ядро, или в /system ввиду отсутствия родного раздела под него (или невозможности записи в него, ввиду закрытого загрузчика)
написания кастомного загрузчика (aboot)
Нет практически не одного современного смартфона, где вы сможете запустить свой загрузчик, SecureBoot не даст. А так у того же квалкома, исходный код загрузчика открыт, можно править.
сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.
Подписать своим ключем нет нечего сложного(по сравнению со сборкой прошивки вцелом).
https://wiki.lineageos.org/signing_builds.html
Как минимум надо производить реверс для написания загрузчика. Дело, с моей точки зрения, дико сложное (я только отдельные моменты вычленял для написания кастомного инита для Z00ED/RD). Плюс есть только один шанс зашить загрузчик, потом если хана, то хана. На сколько мне известно. Может мои знания устарели.
Но я запускал вторичный загрузчик (lk2nd), который был написан энтузиастами из Postmarket OS.
github.com/msm8953-mainline
И оно даже загрузило бут, который используется прошивкой. Вопрос в чем. А нужно ли это вообще?
И как полноценная замена стокового загрузчика оно не работает. Один человек как-то раз зашил себе lk2nd в aboot, поднял ли он устройство — без понятия, я дальше историю сообщений не читал.
Как минимум надо производить реверс для написания загрузчика.
У квалкома код загрузчика открыт, на нем и основан lk2nd. Точнее lk2nd это загрузчик поправленный, что бы работать после загрузчика. Поэтому и получилось его запустить после "родного" разлоченого, а вот заменить его SecureBoot не даст. Раньше, до повального включения SecureBoot, энтузиасты запускали собствееноручно собранный aboot.
А нужно ли это вообще?
В таком виде нет, нужна возможность запускать свой код, в том числе и загрузчик.
Плюс есть только один шанс зашить загрузчик, потом если хана, то хана.
У квалкомов есть EDL режим в котором можно перепрошить флеш почти в любом случае. Но во первых тут опять нужен firehorse-программер подписанный производителем(очень не многие его выкладывают). И второй момент, экспериментами с загрузчиками можно "попортить": фьюзы secureboot'а или antirollback'а.
Если у кого есть какие то рабочие альтернативы, пожелитесь пожалуйста.
Отличная статья! Спасибо!
Теперь аргументы почему с безопасностью все плохо:
1. Современные смартфоны на Android — закрытые системы. 100% открытых телефонов я вообще не видел, у большинства vendor специфичная часть закрыта наглухо, а ведь она занимает половину прошивки. Количество блобов можете посчитать сами, начиная с огромного блоба модема. У некоторых моделей даже ядро невозможно пересобрать, хотя вроде какие-то исходники даже есть, а те производители, которые частично что-то выкладывают — обычно не следят за актуальностью (привет почти всем китайцам). В закрытой системе говорить о безопасности как минимум странно — вы сами не можете не то что исправить ошибки в vendor части, в модеме и много где еще, но даже контролировать что там происходит; гарантированных обновлений от производителя вы тоже можете не получить или получать очень недолго. Cyanogen/Lineage не помогает — там vendor/modem и прочие закрытые части тупо копируются из оригинала.
2. Большинство производителей опять же закрывают телефоны наглухо через AVB/DM-Verity. Если загрузчик можно разблокировать, то обратно заблокировать его с модификациями уже нельзя (у подавляющего большинства). Это открывает проблемы, описанные в статье — люди, вносящие нужные им модификации не могут получить поддержку со стороны железа от других злонамеренных действий. Пользователя вынуждают абсолютно доверять производителям, а любые ультиматумы — это плохо с точки зрения безопасности.
3. Замена FDE на FBE это шаг назад, потому что метаданные файлов не шифруются — это приводит к куче утечек. При этом зашифровать внешнюю sd-карту по прежнему без сильных танцев нельзя, а кое-где и вообще нельзя. Почему вообще нельзя опционально шифровать весь телефон, включая разделы system/vendor/boot и др. — это бы сильно затруднило внедрение трояна описанного в статье? На компьютере же можно что хочешь шифровать, а тут нельзя.
4. Ужасная схема ввода пароля: из коробки не более 16 символов (почему?), нет пароля для сброса данных (против дампа прошивки не спасет, но иногда может выручить), нет настраиваемого учета числа неверных попыток, нельзя вместо пароля использовать ключи, включая внешние, нет возможности выгружать ключи из памяти во время работы (хотя вот в iOS есть), ну и т.д. В системе даже хранится вид пароля, чтобы правильную клавиатуру показывать (буквы, цифры, язык) — шикарная подсказка для взломщиков.
5. Реализация системы разрешений тоже недоработана. Во-первых у части приложений разрешения «неотзывные», т.е. мы вроде как уходили от суперпользователей, но вернулись к ним же. Вроде как все равны, но некоторые равнее. Это не может быть безопасно. Во-вторых, вторичные разрешения вообще не контролируются, т.е. получив доступ к чему-то, приложение может спокойно передать эти данные другому приложению, у которого таких прав нет и в системе никто этого даже не заметит. Подделать данные для приложений впрочем тоже нельзя из коробки, хотя сторонние решения какие-то есть. В третьих, гранулярность разрешений по прежнему очень высокая. Ну что такое «неограниченный доступ в интернет»? Это же дыра огромных размеров, но никто затыкать ее даже не собирается. Надо выдавать разрешения на доступ только к конкретным адресам и по конкретным протоколам как минимум.
Да вобщем, писать можно много, тут на целую статью наверное потянет.
Как итог, система в текущем виде ставит пользователю ультиматум: либо ты доверяешь мне на 100% и тебе при этом будет запрещены многие действия (включая полезные), либо твой телефон превращается в решето и система в этом только поможет и углубит это решето. Вообще, тот факт что людям нужен root-доступ для многих вещей и они готовы его получать жертвуя чем-то, уже говорит о том, что с архитектурой у системы большие проблемы, а значит проблемы и с безопасностью.
Спасибо за вдумчивый комментарий. Всё прям в точку. Практически нечего добавить.
На мой взгляд немало проблем растёт из того, что всё касающееся безопасности очень сильно завязано на пропиетарные компоненты, и даже при желании не может быть исправлено сообществом. Либо проблемы заложены в изначальном дизайне системы и пытаться их исправить ничего не сломав во взаимодействии фреймворка и приложений близко к невозможному (пермишены, подход «всё или ничего»). В итоге, сообщество кастомщиков и радо бы усилить механизмы безопасности, но не может.
Тем не менее, там где это возможно гугл и вендоры стараются подкручивать гайки и это хорошо.
был на руках телефон K30 5G. там DYNAMIC_PARTITIONS_PARTITION_LIST (похоже это сейчас становится модным, oneplus nord тоже такой)
и это не дает монтировать в twrp на запись разделы, которые в этот список входят. только RO. и прошить можно только полностью раздел.
т.е. изменить system, например, из twrp путем добавления файлов не получится.
Присоединяюсь к поблагодарившим, спасибо! Прочитал с огромным интересом.
Скажите пожалуйста, какие главные минусы у рута с заблокированным загрузчиком?
П.с. в слове "нЬюансы" опечатка.
Спасибо большое. Главный минус — имея рут доступ можно изменить что-нибудь в системном разделе и вызвать срабатывание dm-verity, что соответственно приведёт к невозможности загрузиться. Это легко сделать неосторожным изменение hosts файла например. Тем не менее вполне можно использовать afwall, т.к. всё для чего ему нужен root — это вызов бинарника iptables. Я бы сам лично не стал бы пользоваться root доступом в системе с заблокированным загрузчиком просто чтобы случайно не наломать дров.
П.С: не только в нём, мне нужно сесть и поправить немало орфографических ошибок
Благодарю, да, afwall замечательная программа, я без неё уже не могу + логирование крайне удобное, недавно заблочил кучу рекламы в hosts, время от времени заглядываю в тёмные комнаты андройда, получается, не первый год хожу по грани, надо что-то с этим делать, скоро оступлюсь.
Скажите, какая ситуация у новейших андройдов с обновлениями и рут доступом, после установки свежих обновлений придётся ломать эксплойтом каждый раз? Если да,
с разблокированным загрузчиком таких проблем можно избежать?
П.п.с. В целом, текст написан весьма достойно, совсем уж незначительные опечатки я не стал указывать.(раза 2 заметил, что нет пробела между словами)
Про iOS знаю, но тот же кингрут занимается тем же самым по сути, т.е. взломом через эксплойт, ну и троянца своего тоже не забудут подсунуть, но это совсем другая история. Мне интересно понять, как ведут себя при обновлении новые устройства, рутованные разными способами(зловред kingroot и его аналоги или же полноценная разблокировка). В любом случае, спасибо за отзывчивость.
Вставлю свои 5 копеек. Недавно восстановливпал прошивку на разлоченом сто лет назад xiaomi mi5s. Переходил с кастома на 10 Андроиде на miui на 7м. Полный формат всего, и все равно без ввода предыдущего аккаунта Гугла даже не пройти процедуру первоначальной настройки.
(и это причина, по которой я предпочитаю доверить авторизацию BitLocker-у, а не экрану входа в систему… к этому времени уж больно много всего запущено, соответственно увеличивается число таких вот потенциальных приложений, которые можно использовать для обхода авторизации)
В Android вендоры с этим борются… если устройство ещё получает обновления, конечно.
Спасибо за статью, очень познавательная.
А есть рабочее решение по проверке хэша через twrp?
Также интересует вопрос антивирусов на телефоне, в каких случаях рекомендуется использовать и какие будут рекомендации?
Решение — просто делать проверки через шелл (можно при желании заавтоматизировать всё через python и subprocess). Загружаемся в TWRP. Образ TWRP содержит многие утилиты для работы с файловыми системами, сбора информации о системе, и т.д. Среди них есть и утилиты для подсчёта хэшей, воспользуемся sha256sum:
$ adb shell // подключаемся через adb
# sha256sum /dev/block/by-name/boot // проверяем хэш boot раздела
# sha256sum /dev/block/by-name/system // проверяем хэш system раздела
...
Насчёт антивирусов — даже не знаю имеет ли это смысл, и что можно посоветовать. Я попробовал прогнать тесты на нескольких популярных антивирусных продуктах при установленном бэкдоре, и похоже что большинство из них не пытается прогонять сложные проверки на то что система на устройстве была скомпрометирована, или хотя бы просто попробовать прогнать проверку SafetyNet. Я не пытался глубоко анализировать механику работы антивирусов на android. Судя по всему они пытаются получать информацию о пакетах и искать подозрительные данные в манифестах или что-то вроде того. В любом случае, если устройство не предполагает использования аппаратного ТЕЕ в процессе аттестации (такое кажется есть только на пикселях), то на скомпрометированной системе с помощью рантайм-хуков злоумышленник сможет при необходимости обмануть любую проверку, поэтому наверное никто очень сильно и не пытается
В общем, при правильном подходе можно заменить в стоковой системе практически всё и получить устройство, которое будет практически так же хорошо как и на альтернативной прошивке, при этом иметь заблокированный загрузчик и все плюсы использования немодифицированного устройства, такие как работающий Google Pay и платежи касанием по NFC, беспроблемно работающие приложения банков и иные полагающиеся на проверки SafetyNet, нормально работающая камера и т.д.
С удовольствием прочитал бы статью о том, как это сделать, отключив по максиму гуглософт, и минимизировать таким образом отправку данных в корпорацию добра.
представим ситуацию, мы – злоумышленник, получивший на некоторое время в свои руки смартфон.
Можно ещё представить ситуацию, что я усилием мысли переместился на Альфу Центавра. Но зачем?
Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым