Привет, Хабр! Меня зовут Роман, я занимаюсь безопасностью IOT-устройств.

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

Представьте приемную крупной компании. Диван, низенький столик, подключенный к ТВ-приставке телевизор беззвучно крутит очередной выпуск новостей. Великолепный шанс для хакерской атаки. Нужно только получить доступ к устройству.

Мне предстояло найти способ отравить приставку и превратить ее в плацдарм для будущих атак на другие элементы сетевой инфраструктуры.

Разведка

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

В результате на мой рабочий стол попало устройство на платформе Amlogic S905X, очень похожее на Mecool M8S PRO+.

Блок-диаграмма Amlogic S905X. Это недорогой процессор с аппаратным видеодекодером, предназначенный для lzk-работы в потребительской медиаэлектронике: ТВ-приставках, умных колонках
Блок-диаграмма Amlogic S905X. Это недорогой процессор с аппаратным видеодекодером, предназначенный для lzk-работы в потребительской медиаэлектронике: ТВ-приставках, умных колонках

Большинство подобных приставок основано на референс-дизайне Droidlogic A95X. AliExpress завален такими устройствами. Они отличаются по внешнему виду, но почти идентичны в своей начинке. Варьируется разве что расположение элементов на плате.

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

Производители узкоспециализированных процессоров редко публикуют техническую документацию. Но на чип S905X утекло некоторое количество документации. К тому же, на этом чипе основаны Khadas VIM1 и одна из плат ODROID.

Одноплатник Khadas VIM1
Одноплатник Khadas VIM1

Это платформы типа Raspberry Pi, только ориентированные на медиафункционал. В сети по ним много информации.

Выяснилось, что на платы этого типа устанавливается либо eMMC, либо NAND-память. Причем пины eMMC подключаются к той же линии, что идет к посадочному месту для NAND-памяти. Поэтому удалять чип вовсе не обязательно. Вместо этого, я подпаялся программатором на место NAND-памяти и снял дамп с eMMC. Так что трафарет в итоге не пригодился.

С помощью документации Khadas мне удалось найти чип сброса контроллера на плате приставки. Параллельно я подпаял хардварную кнопку Reset. Затем нашел отладочный интерфейс JTAG.

Плата нашей приставки. Желтым цветом подписаны штатные элементы, красным ― точки подключения отладочных интерфейсов и дополнительно установленные элементы

В инструкциях нашлось описание процесса загрузки чипа. Оказалось, что, если eMMC по какой-то причине не работает, загрузчик ищет альтернативу ― SD-карточку или USB-флешку.

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

Пришло время переходить к софту.

Исследование загрузчика

В Amlogic S905X встроено расширение ARM Trust Zone. Оно нужно, чтобы выделить защищенную область памяти, которая доступна только для доверенного кода.

Описание работы референсной реализации ARM Trusted Firmware
Описание работы референсной реализации ARM Trusted Firmware

Trust Zone работает следующим образом.

Производитель подписывает легитимный загрузчик закрытым ключом. Масочный загрузчик (RomBOOT) при каждом запуске считывает код из основной энергонезависимой загрузочной памяти и проверяет корректность подписи. Если подпись корректна ― код выполняется.

Открытые ключи прошиваются в eFUSE. Эта область памяти представляет собой набор перемычек, которые пережигаются еще во время производства. Такой подход защищает RomBOOT от подмены ключей.

Довольно надежная штука, так что столкнувшись с ней я решил сначала изучить загрузчик нулевого уровня.

Бинго! Оказалось, что в приставке использован U-Boot. Это проект с открытым исходным кодом, который используют повсюду от продуктов Cisco до безымянных китайских датчиков.

Вот только популярность U-Boot не означает, что все понимают, как правильно его сконфигурировать.

U-Boot не просто загрузчик, в него встроены инструменты для отладки. Они доступны через консоль на одном из портов UART сразу после прерывания загрузки. По-хорошему, перед выходом на прод разработчикам необходимо заблокировать доступ к прерыванию загрузки и перевести консоль в режим Read-Only, а также исключить большую часть команд, которые позволяют работать с памятью на низком уровне.

Это стоило проверить. Я нашел контакты UART-порта по надписям RX/TX на плате, подключил консольный кабель, подобрал скорость и увидел стандартное приглашение:

Hit Enter or space or Ctrl+C key to stop autoboot -- : 0

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

Тем не менее загрузка прерывалась, если сразу при старте слать в консоль большое количество <CR>.

Прервав загрузку, я получил доступ к командной строке. По запросу «?» она выдала длинный список доступных сервисных команд.

Среди них нашелся еще один способ создать полный дамп eMMC, но главное, там была команда efuse read. На проверку, область efuse оказалась пуста ― все значения skb равны 0x00.

Так я понял, что доверенная загрузка просто не работает. На приставке выполняется произвольный код, любые загрузчики. Хорошая новость для энтузиастов с XDA, и не очень хорошая для производителя. Оригинальный софт сносится по мановению руки.

Чтобы проверить гипотезу на практике, я взял образ Ubuntu, предназначенный для установки на Khadas и записал на SD-карту, как есть. Затем заблокировал работу eMMC кнопкой и вынудил RomBOOT загрузиться с SD-карты.

Вместо Android запустилась Ubuntu.

Еще, ради интереса, я собрал из исходников U-Boot и также загрузил с SD-карты. Он стартовал, но падал на этапе BL2=>BL3. Вероятно, мне попалась сборка с некорректными конфигами DDR-памяти.

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

Получаем привилегии

На приставке крутился AOSP сборка Android 9 без сервисов Google. Вместо лаунчера запускается фирменное приложение, собранное таким образом, что оно выдает себя за лаунчер. Такой подход должен препятствовать установке сторонних приложений, но это было бессмысленно, так как на UART обнаружилась открытая консоль. Причем сразу c правами администратора и без аутентификации.

Кстати, SELinux работал в permissive-режиме, то есть, не обеспечивал защиту
Кстати, SELinux работал в permissive-режиме, то есть, не обеспечивал защиту

Чтобы не тратить время на ручную модификацию файлов, я получил Root с помощью Magisk, а затем настроил удаленную отладку. Производитель отключил ее вместе со всем меню разработчика, но ADB-интерфейс поднимается и руками:

setprop persist.sys.usb.config mtp,adb

/system/bin/mount -o rw,remount /

sed -i 's/ro.debuggable=0/ro.debuggable=1/g' /system/etc/prop.default

sed -i 's/ro.secure=1/ro.secure=0/g' /system/etc/prop.default

sed -i 's/ro.adb.secure=1/ro.adb.secure=0/g' /system/etc/prop.default

settings put global development_settings_enabled 1

/system/bin/mount -o ro,remount /

reboot

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

Исследуем файловую систему

Пришло время посмотреть на файловую систему. Хорошая новость ― пользовательский раздел зашифрован. Плохая ― все остальное ― нет. Разделы, относящиеся к системным, полностью открыты и даже не подписаны, хотя для этого существует Android Verified Boot.

Из-за этого все изменения, которые я провел через консоль или ADB, без проблем проделываются через прямую модификацию файловой системы и заливаются снаружи через U-Boot. Это готовый вектор для атаки, однако здесь нужен физический доступ. Мне же хотелось найти вектор для удаленной атаки. Надо было посмотреть трафик.

Подслушиваем за приставкой

Приставка осуществляет обмен с инфраструктурой провайдера при помощи HTTP запросов поверх SSL. Для снятия SSL необходимо было направить трафик приставки на proxy-сервер и подменить корневые сертификаты.

В качестве инструмента для мониторинга HTTP я использовал Charles. Основной сценарий использования Charles ― мониторинг SSL трафика на локальной машине, но ничто не мешает перенаправить на нее трафик с удаленной машины, то есть, с приставки. В Android корневые сертификаты хранятся в папке /system/etc/security/cacerts/. Название файла должно соответствовать хэшу сертификата.

Подготовленный сертификат необходимо скопировать на флешку и далее записать в соответствующую директорию.

/system/bin/mount -o rw,remount /

cp /mnt/media_rw/6539-6535/9a5ba575.0 /system/etc/security/cacerts/

chmod 644 /system/etc/security/cacerts/9a5ba575.0

chown root:root /system/etc/security/cacerts/9a5ba575.0

/system/bin/mount -o ro,remount /

Проконтролировать корректность установки сертификата можно, вызвав системные настройки

am start -a android.settings.SETTINGS

и далее проверить наличие добавленного сертификата в меню «Security & location» => «Encryption & credentials» => Tap «Trusted credentials».

Перенаправить трафик можно либо на маршрутизаторе, либо задав системный прокси командой

settings put global http_proxy 10.2.100:8888

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

Обновление ОС запрашивается корректно, через SSL, а запросы на приложения отправляются без шифрования. Это возможность для MiTM-атаки.

Векторы атак

В итоге найденные уязвимости сложились в два вектора атак:

1. Установка отравленного системного обновления

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

Затем ему придется прийти в фойе, вставить флешку в приставку и зажать на 10 секунд стандартную кнопку перезагрузки.

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

2. MiTM атака через обновление приложения

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

Главное — перехватить запрос на обновление софта от приставки и залить на нее отравленное приложение. А оно уже выполнит работу по повышению привилегий в ОС, поднимет VPN и настроит удаленный доступ, даже если приставка находится за роутером или NAT.

В обоих случаях приставка превращается в настоящий зомбоящик ― полноценный плацдарм для атак на сетевую инфраструктуру компании.

Вместо заключения: почему так вышло

Хочется найти конкретного виновника всех проблем, но, обычно уязвимость подобных устройств объясняется целым набором факторов. Этот случай ― не исключение.

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

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

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

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

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

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

Хотелось бы, чтобы бизнес обращал на это больше внимания. Да, за защиту надо платить, но за ее отсутствие приходится расплачиваться. Зачастую, простым пользователям.


Что может изменить сложившуюся ситуацию? Какие технологии и подходы к разработке способны обеспечить безопасность IoT? Давайте обсудим это в комментариях.

Комментарии (17)


  1. vilgeforce
    03.11.2021 11:10

    А "settings put global http_proxy" работает вообще для всего траффика, даже если приложение не поддерживает прокси?


    1. donovanrey Автор
      03.11.2021 16:00
      +1

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


  1. latonita
    03.11.2021 11:56

    Спасибо. Хорошая статья. Но вот изначальный посыл у меня не укладывается. В моем мире все представляется по-другому: "Представьте приемную крупной компании. На стене висит samsung/LG телевизор одно-двухлетней давности и играет ролики с флешки или из сети".

    Как дела обстоят с секурити с такими ребятами, как Samsung? Спасибо


    1. donovanrey Автор
      03.11.2021 16:06

      Именитые производители ТВ более внимательно относятся к защите от выполнения недоверенного кода. Поэтому атаки в лоб с полной сменой прошивки скорее всего не пройдут. Тем не менее загрузчик нулевого уровня это тоже софт, в котором возможны ошибки. Например, такие уязвимости были обнаружены в ранних версиях загрузчика Amlogic, где эксплуатируя переполнение буфера было возможно пропустить процедуру проверки ЭЦП.


  1. MinimumLaw
    03.11.2021 12:19
    +1

    Хм... Прям журнал Хакер из моей юности.

    https://libreelec.tv/downloads/ - открытый проект медиабокса с исходниками на github'е содержащий в документации все, что есть в статье. Только меньше пафоса и больше дела.

    По факту вопрос хороший. Мне кажется, что все "ошибки" и "утечки" сделаны преднамеренно. Этакий скрытый "OpenSource". И да - они сработали ровно так, как задумывалось. Благодаря им сформировалось сообщество "ковырятелей" прошивок разной степени подготовленности. И ваш покорный слуга S905W поковырял в свое время.

    Жалко что до kernel.org и denx.de не все дошло. Впрочем, опять все упирается в вопрос про общество потребления... А это уже политика. А с ней я не связываюсь.


    1. CodeRush
      03.11.2021 21:35
      +5

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

      На самом деле, только когда производитель достаточно именитый, чтобы уязвимости в его устройствах начали портить ему имидж и продажи, вот только тогда этот самый производитель начинает заставлять своих инженеров что-то делать кроме «отключил и не трогаешь», искать на рынке специалистов по безопасности, деньги им платить, вот это все. Что говорить, если даже крупные производители десктопных плат (Asus, Asrock, MSI и Gigabyte) на безопасность своих прошивок и софта кладут свои огромные таёжные приборы, а уж китайским суньхуньвчаям это все до фонаря и подавно…


      1. MinimumLaw
        03.11.2021 22:29
        +1

        Да уж... Конкретно про ASUS даже мне есть чего сказать. Много лет назад присылал им весьма неприятную дырку, и... Пару месяцев назад проверил - жива до сих пор.

        И все же, и все же, и все же... Та же Microsoft более или менее по серьезному начала шевелиться только сейчас. И то, даже для Windows 11 SecureBoot не является строго обязательным. Да и ваш современный работадатель... Я прямо сейчас ответ с Hackintosh'а пишу. Правда до Monteray еще не обновился, но... Думаю шансы есть...

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


        1. CodeRush
          03.11.2021 22:53
          +6

          Хакинтош и UEFI SecureBoot — это не про то несколько, и я точно не призываю закрыть всю загрузку наглухо и никого не впускать и не выпускать, потому что это другая крайность, и я сам ее не люблю так же сильно, как и описанную в этой статье «гуляй-рванину».

          Тем не менее, многолетний практически опыт подсказывает, что любые технологии обеспечения безопасности, которые отключить проще, чем настроить, будут при первых сложностях с их настройкой или проблемах, вызванных неверной настройкой, отключены навсегда, зачастую прямо на заводе. А если они еще и по-умолчанию отключены — никто даже не пойдет их включать или тестировать, «нам тут работать надо, а не херней страдать». Это потом уже любой хакер Вася за 15 минут делает себе ботнет из 100500 машин, и идет ими майнить монеро или ддосить своего соседа Петю, но производителя это все не начинает волновать никак — его устройства уже на рынке, деньги он уже получил, а дальше все эти проблемы — это проблемы Васи и Пети.

          Именно поэтому любые подобного рода технологии нормально заработают только тогда, когда: а) они будут включены по умолчанию, б) пользоваться ими будет намного проще, чем отключить совсем. Именно так получилось сделать и на T2, на Apple Silicon, и я считаю последнюю итерацию своим самым большим достижением в карьере на данным момент — несложно настраиваемый SecureBoot, позволяющий загружать любой пользовательский код (после проверки пароля и доказательства физического присутствия), и при этом не отключаемый принципиально, и доставленный на миллионы машин простых пользователей, которые массово на него не жалуются. А UEFI SecureBoot как отключали, так и продолжат отключать при любом чихе, а потом страдать от загрузочных вирусов и перехватчиков паролей.


          1. MinimumLaw
            04.11.2021 10:10
            +4

            Да. Безусловно. И спорить с этим глупо. И не будем опять начинать священную войну Apple VS ... Тем более, что мне нравится как у них сделано очень многое.

            Однако уж очень сложный вопрос вот в чем - перевесит ли вред для Пети, пользу от того, что Вася окажется втянутым в индустрию и поработает на ее развитие. Все всегда начинается с простых вещей. Скин, plugin. Дальше замена компонентов и замена прошивки. А дальше их же разработка.

            Игрушки типа этой приставки или горы китайских телефонов на Андроиде от производителей второго эшелона плодят будущих разработчиков лучше, чем все институты и университеты вместе взятые. И это настолько заметно, что не заподозрить здесь умысел просто невозможно. Впрочем, и про замечательную бритву Хэнлона: «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью».


  1. SergeyMax
    04.11.2021 01:25
    +1

    Ничего не понимаю. Возможность вставить флешку и загрузить с неё вместо андроида линукс (OpenELEC/LibreELEC/etc) прямо декларируется производителем медиаприставки. В чём конкретно состояла атака?


    1. donovanrey Автор
      04.11.2021 12:15
      +1

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


  1. AndreiMoscow
    04.11.2021 10:10

    Колонку Алиса проверяли? Или такие же колонки?


    1. donovanrey Автор
      04.11.2021 12:13
      +2

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


  1. corvair
    04.11.2021 11:08
    +2

    Надо проверить одну из самых массовых приставок - IPTV от Ростелеком. Она ещё существует в нескольких ревизиях, отличающихся как железом, так и ПО. Производитель обеих моих приставок, уже не самых новых версий, заявлен как "Промсвязь" г. Уфа.


  1. Kalhoznik
    04.11.2021 11:26
    +1

    Классная статья))


  1. ValdikSS
    07.11.2021 18:54

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

    Не включённый secure/verified boot — не уязвимость, а штатная функция. Напротив, чтобы включить secure boot, производителю нужно совершать дополнительные действия, которые нужны далеко не всем — кто-то считает преимуществом возможность смены прошивки на устройстве.

    2. MiTM атака через обновление приложения

    Главное — перехватить запрос на обновление софта от приставки и залить на нее отравленное приложение.

    Если речь идёт про софт в виде apk-файлов, каким образом вы обойдёте проверку подписи файла? Или вы хотите сказать, что можно прогрузить произвольный .apk, и система не проверяет даже название (id) приложения? Вы сами это тестировали, или только теоретически рассуждали?


  1. orDIV
    16.11.2021 14:01
    +1

    Очень интересная статья!

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