Когда вендор не защитил — защищаем вашу Станцию, Капсулу и A113X
Красавчики
Приветствую!
В нашем несовершенном мире «умных домов» и повсеместного IoT с относительно недавних пор стало модным производить (да и покупать домой) очередного разговорчивого электронного друга, а именно: Яндекс Станции, VK Капсулы, SberBoom и тому подобные девайсы.
К сожалению для разработчиков (не путать с вендорами) этих устройств, некоторые из них содержат уязвимости, позволяющие пользователям с нужными навыками локально получить полный контроль над железкой, прочитать те данные, которые пользователь не должен уметь читать, да и в целом иметь возможность изучить прошивку, найти в ней уязвимости и так далее.
Конечно, как можно понять из названия, речь пойдёт об устройствах на базе SoC от Amlogic — A113X. В данном материале я расскажу о том, как можно защитить ваши устройства на базе этого чипа от описанных выше вещей, почему Amlogic не смог предложить эту защиту разработчикам, и другие интересные детали. Программисты умных колонок, и просто интересующиеся — добро пожаловать под кат.
A113X уязвим?
Возможно, некоторые разработчики устройств «умного дома», работавшие с Amlogic A113X сейчас сильно удивились, узнав, что камень, который они выбрали для разработки, подвержен какой-то уязвимости (к тому же, её внесли не они сами).
Так вот, ещё в 2020 году в другом чипе от Amlogic — S905D3 была найденая критическая уязвимость на уровне Bootrom, позволяющая исполнять любой неподписанный код, которую, очевидно, невозможно исправить. Уязвимой оказалась одна из команд протокола Amlogic USB Download, используемого утилитой от вендора Aml Burning Tool v3 для прошивки и обновления устройств. К тому же, был публично опубликован эксплоит, позволяющий воспользоваться данной уязвимостью локально и выполнить нужные команды. Например, можно вычитать ключи шифрования из защищённой области чипа (фьюзов) и расшифровать содержимое некоторых областей прошивки, либо просто сдампить сам Bootrom и изучить его детальнее.
Казалось бы, при чём тут A113X? Дело в том, что указанный протокол обновления используется и в герое данной статьи, и содержит ту же самую уязвимость. Только вот публичного эксплоита вроде как нет (на самом деле автор не искал). К тому же, внимательные читатели, которые уже прочитали об уязвимости по ссылке, заметили, что защититься от уязвимости можно!
Согласно материалу, можно воспользоваться «password protection», встроенной в Bootrom, и всё — уязвимость будет неэксплуатабельной. Изучив код бутрома, я могу с уверенностью сказать — парольная защита правда закрывает найденную багу.
Парольная защита
Капсула от VK, на которую я накатил защиту паролем
Защита паролем подразумевает запись хэша необходимого вам пароля во фьюзы и установку там же соответствующего бита. Проверка будет происходить каждый раз, когда по USB к устройству кто-то подключается и пытается отправлять команды, срабатывая до выполнения основных его команд, типа уязвимой AM_REQ_WR_LARGE_MEM. И всё бы хорошо, но есть одно НО.
Инструменты разработчика (SDK), предоставляемые Amlogic, действительно содержат утилиту, которая позволяет при сборке прошивки задать необходимый пароль и создать файл, который будет включать в себя прошиваемые в устройство фьюзы. Данный файл с фьюзами (включающий также и ключи шифрования прошивки) может иметь названия в стиле secureboot_set/secure_boot_set/amlogic_set и так далее, и используется утилитой, упомянутой ранеее — Aml Burning Tool.
Прежде чем упомянуть то самое НО, стоит рассказать, что у Amlogic существует разделение своих чипов на так называемые «семейства», и у них есть вот такие названия:
Для каждого представленного семейства в SDK имеется свой собственный вариант утилиты для создания Secure Boot Set. Это сделано потому, что у всех из них реализован собственный Bootrom со своей структурой хранения флагов и ключей во фьюзах.
Так вот, НО заключается в том, что не для всех семейств в списке утилита создания файла фьюзов позволяет этот самый пароль на USB задать. А в ответ на запросы вендор утверждает, что возможности установить пароль на таких семействах нет в принципе.
Столкнувшись с этим, разработчики, которые хотели как-то защитить своё устройство от незапланированного использования (иногда даже не подозревая об уязвимости), начинают идти на различные хитрости (либо не идти), лишь бы не дать исследователю поковыряться в прошивке:
Используют USB-пины, но не выводят их наружу, при этом скрывая распиновку на плате
Продолжают использовать USB-порт, защищая уровень повыше (RH, U-Boot bootdelay)
Используют USB-порт (защита отсутствует)
Конечно, все эти защиты упираются только во время, необходимое исследователю, чтобы их обойти:
распиновку можно прозвонить
защиты уровня выше Bootrom не имеют смысла, если цепочка доверия нарушена
Amlogic говорит правду?
Давайте же выясним, правду ли говорит вендор, утверждая, что на чипах типа A113X парольной защиты нет. Для этого нам потребуется сдампить сам Bootrom камня. Тем, кто разрабатывает под данный чип, провернуть такое проще простого — главное написать код, который сдампит содержимое памяти по адресу 0xFFFF0000 в UART.
Ну, а для тех, у кого возможности разрабатывать (или хотя бы подписывать) код для A113X нет (условный исследователь безопасности устройств) вариант только один — изучать возможности запуска своего кода на устройстве. И этот вариант фактически содержит единственное решение:
Я не хотел бы приводить здесь адаптированный эксплоит по разным причинам. Скажу лишь, что после детального изучения сдампленного Bootrom от S905D3 процесс модификации становится сильно проще. Ну, а остальное — тупо брутфорс неизвестных адресов.
Как бы то ни было, получив код бутрома A113X, убеждаемся в наличии в протоколе USB функции проверки пароля:
Наличие в протоколе команды проверки пароля
Проверка установленного бита проверки пароля USB
Добавляем поддержку пароля для axg (A113X)
Отлично, мы выяснили, что пароль таки проверяется, но специально созданная для этого утилита даже не имеет нужного флага, чтобы этот пароль прописался в файл фьюзов. Не беда, давайте запишем в него нужные байтики и дело в шляпе, да?
На самом деле, не всё так просто! Если присмотреться к самому файлу фьюзов, можно заметить некоторую «кашу» (назовём это «высокой энтропией»). Это может означать как использование какого-то шифрования, так и сжатия (а возможно и того, и другого).
Кусок файла secure_boot_set
Сразу забегу вперёд и скажу, что это таки шифрование. Если покопаться в утилите для создания файла фьюзов для других платформ (название у неё aml_encrypt_xxx, где xxx — имя платформы), в которых поддержка пароля реализована, можно обнаружить много интересных деталей.
Во-первых, можно найти саму команду задания пароля mkpsd. Во-вторых, обнаружить и алгоритм шифрования файла фьюзов. Неделя отладки — и вот, мы уже можем расшифровывать secure_boot_set (в том числе и для платформы axg). Осталось понять, как в этот файл запихнуть флаг USB_PD_CHK_ENABLE и сам хэш пароля от USB.
Для этого придётся ещё немного поизучать код Bootrom. Там, внутри функции check_password можно обнаружить следующий код:
Чтение структуры с фьюзами
Видим, что нужный нам хэш находится по смещению 0x60. Ещё у хэша рядом лежит «соль»:
Поле с «солью» располагается сразу за хэшем
Ну, а необходимое расположение бита для проверки пароля USB_PD_CHK_ENABLE удалось выяснить по расположению других флагов в том же secure_boot_set, и оно оказалось равно 0xB4. То есть алгоритм получается следующий:
Расшифровываем
secure_boot_setЗаписываем хэш пароля USB и соль по смещению
0x60Устанавливаем бит номер
15в единицу в дворде по смещению0xB4Шифруем файл обратно
Прошиваем его через UBoot команду
efuse amlogic_set, предварительно записав в нужный адрес памяти содержимое файла фьюзов с паролем (можно и содержащего только информацию о пароле, без ключей шифрования AES и тому подобного)Вуаля, эксплоит больше не работает!
Заключение
Почему вендор не смог включить всё то же самое в утилиты для платформы axg (A113X), что было проделано в данной статье, имея при этом все исходные коды (все ли?), мне не понятно. Тем более, тот был уведомлен о том, что возможность установки пароля для axg есть.
Забавным также остаётся тот факт, что подавляющее большинство устройств на базе A113X не содержат включенной проверки пароля на USB и подвержены эксплуатации давно найденной уязвимости, возможности закрыть которую нет, кроме как установив данный пароль.
Для подтверждения написанного в данном материале потока мыслей я подверг пыткам через эксплоит устройства от Яндекса, VK и Сбера на базе этой платформы, и лишь у последнего данная защита оказалась включенной, не давая возможности запускать собственный код.
Поэтому, чтобы защитить всех перечисленных производителей умных колонок от эксплуатации уязвимости в Bootrom A113X и, соответственно, от запуска на них любого кода, поиска в колонках уязвимостей через дампинг прошивки с флеша, я решил поделиться скриптом, который закроет указанную дыру.
Скрипты
Набор для создания secure_boot_set с USB-паролем: https://gist.github.com/lab313ru/08ca90aaacc41f662d39861ceda5510d
Примеры использования:
python usb_password_a113x.py e usb_secureboot_set.bin -p password.binpython usb_password_a113x.py d usb_secureboot_set_dec.bin -i usb_secureboot_set.bin