God Mode On: как мы атаковали модем в головном устройстве автомобиля

Введение

Представьте: вы едете на своем новеньком электромобиле, а на огромном мультимедийном дисплее вдруг вместо навигации запускается культовый 3D-шутер Doom, и кто-то пытается играть в него, управляя персонажем удаленно. Такая ситуация только кажется невероятной — мы наглядно доказали, что в современных условиях она более чем реальна.

Сегодня интернет используют не только гаджеты, но и заводы, автомобили, поезда. Как правило, они подключаются к мобильным сетям (3G/4G/5G) с помощью модемов. Все чаще эти модемы интегрированы в систему на кристалле (SoC), которая выполняет одновременно несколько функций, используя модемный процессор (Communication Processor, CP) для одних и процессор приложений (Application Processor, AP) для других.

Операционная система общего назначения, такая как Android, вполне может работать на AP, в то время как CP, предназначенный для взаимодействия с мобильной сетью, обычно реализуется на базе специализированных ОС. При этом взаимосвязь между AP, CP и RAM на этом кристалле на уровне микроархитектуры представляет собой «черный ящик» и известна только производителю, хотя напрямую влияет на безопасность всей SoC.

Считается, что обход механизмов безопасности 3G/LTE — чисто академическая задача. Ведь при подключении пользовательского устройства (User Equipment, UE) к базовой станции сотовой связи (Evolved Node B, eNB) создается безопасный канал связи. Даже если кто-то сможет обойти его защитные механизмы, обнаружить уязвимость в модеме и выполнить на нем свой код, это, скорее всего, не затронет бизнес-логику устройства. Эта логика (например, пользовательские приложения, история браузера, звонки и SMS на смартфоне) находится на АР и, как предполагается, не может быть доступна с модема.

Чтобы выяснить, так ли это, мы исследовали безопасность современной SoC Unisoc UIS7862A со встроенным 2G/3G/4G-модемом. Такие чипы встречаются в китайских и отечественных мобильных устройствах, а также в головных устройствах современных китайских автомобилей, количество которых на дорогах растет. Головное устройство — один из ключевых объектов автомобиля, и его компрометация угрожает не только сохранности пользовательских данных, но и безопасности дорожного движения.

В ходе этого исследования мы обнаружили несколько критических уязвимостей на разных уровнях стека сотовых протоколов модема Unisoc UIS7862A. В частности, уязвимость переполнения стека в реализации протокола 3G RLC (CVE-2024-39432). Она позволяет удаленно выполнять код на ранних этапах подключения, до активации каких-либо защитных механизмов. Однако получение возможности выполнения своего кода на модеме — лишь точка входа для полной удаленной компрометации всей SoC. Нам удалось найти несколько способов получить доступ к AP, в том числе с использованием аппаратной уязвимости в виде скрытого DMA-устройства (Direct Memory Access) для выполнения горизонтального перемещения внутри SoC. Это позволило нам установить собственный патч к работающему ядру Android и выполнить произвольный код на AP с наивысшими привилегиями.

Получение встроенного программного обеспечения модема

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

Плата головного устройства

Описание компонентов платы:

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

Удаленный доступ к модему (CVE-2024-39431)

Исследуемый модем реализует несколько стеков протоколов (2G, 3G, LTE), что увеличивает количество потенциальных точек входа (векторов атаки). При этом чем ниже в стеке сетевой модели OSI находится уязвимость, тем серьезнее последствия ее эксплуатации, поэтому мы решили провести анализ механизмов фрагментации пакетов данных на уровне доступа к среде передачи (протокол RLC).

Нас заинтересовал именно этот протокол, потому что он используется для установки безопасного зашифрованного канала передачи данных между базовой станцией и модемом. По нему, в частности, передаются данные протокола NAS (Non-Access Stratum), который представляет собой функциональный уровень протокольного стека 3G/UMTS, расположенный между пользовательским оборудованием (UE) и ядром сети (Core Network) и отвечающий за сигнализацию между ними. Таким образом, наличие уязвимости удаленного выполнения кода (Remote Code Execution, RCE) в RLC позволяет исполнить свой код на модеме в обход всех существующих механизмов защиты коммуникации в 3G.

Стек протоколов 3G

Протокол RLC использует три различных режима передачи: transparent mode (TM), unacknowledged mode (UM) и acknowledged mode (AM). Нас интересует только режим UM, потому что в нем стандарт 3G предусматривает как сегментацию данных, так и конкатенацию нескольких небольших фрагментов высокоуровневых данных (Protocol Data Unit, PDU) в один фрейм канального уровня. Это сделано для максимально эффективного использования канала передачи. На уровне RLC пакеты называются блоками служебных данных (Service Data Unit, SDU).

В прошивке среди примерно 75 000 тысяч различных функций мы отыскали функцию обработки входящего SDU-пакета. При ее реализации происходит разбор полей заголовков SDU-пакета, который состоит из обязательного заголовка, необязательных заголовков и данных. Количество необязательных заголовков ничем не ограничено. Признаком их конца служит младший бит (E bit), равный 0. Алгоритм последовательно обрабатывает каждое поле, пока E bit в них равен 1. В процессе обработки данные записываются в переменную, находящуюся на стеке вызывающей функции. Глубина стека составляет 0хВ4 байт. Размер пакета, который можно парсить (количество заголовков, каждый заголовок — это запись двух байт на стек), ограничен размером SDU-пакета 0х5F0 байт.

В итоге для эксплуатации достаточно одного пакета, в котором количество заголовков превышает глубину стека (90 заголовков). Важно отметить, что именно в этой функции стековая канарейка отсутствует и при переполнении стека можно подменить адрес возврата и значения некоторых внутренних регистров. Однако подмена возможна только на значение, оканчивающееся на единицу в бинарном виде (младший бит равен 1). Примечательно, что исполнение происходит на ARM в режиме Thumb, поэтому все адреса возврата должны иметь младший бит, равный 1. Совпадение? Возможно.

Так или иначе, отправка первого же пакета-пустышки SDU с соответствующим количеством «правильных» заголовков привела к перезагрузке устройства. На тот момент у нас не было возможности получить информацию о том, где и почему произошел сбой. Однако мы предполагаем, что причиной стала попытка передачи управления по адресу 0хААВВССDD, взятому из нашего пакета.

Закрепление в системе

Мы знали, что указатель на только что полученный SDU-пакет хранится в регистре R2. Для выполнения своего кода на стороне модема мы выбрали технику возвратно-ориентированного программирования (Return Oriented Programming, ROP). Однако сначала следовало убедиться, что это в принципе возможно.

Мы воспользовались доступным обработчиком АТ-команд для перезаписи данных в области RAM. Нашли подходящую функцию среди доступных АТ-команд — SPSERVICETYPE.

Мы использовали ROP-гаджеты, чтобы переписать адрес 0х8CE56218, не нарушая при этом дальнейшую работу алгоритма обработки входящих SDU-пакетов. Для этого достаточно было обеспечить возврат в функцию, из которой был вызван обработчик SDU-пакета, потому что она вызывается как функция обратного вызова, а значит, ее данные не сохраняются на стеке. Учитывая, что эта функция добавила на стек всего 0х2С байт, важно было уложиться в этот размер.

Переполнение стека в контексте операционной системы

Найдя подходящую ROP-цепочку, мы запустили SDU-пакет, содержащий ее в качестве полезной нагрузки. В результате в консоли АТ-команды SPSERVICETYPE увидели вывод 0xAABBCCDD. Наш код сработал!

Далее по аналогии мы ввели адрес фрейма стека, на котором находились наши данные. Однако этот стек оказался неисполняемым. Соответственно, нужно было разобраться с настройкой MPU на модеме. Для этого, снова используя метод ROP-цепочек, мы сгенерировали код, который читал таблицу MPU, — по одному DWORD за раз. Спустя множество итераций мы получили следующую таблицу.

По ней видно, что нужная нам секция кода имеет права только на исполнение. Мы использовали еще одну ROP-цепочку, чтобы в другом месте таблицы указать эту же секцию с правами записи. Благодаря особенностям программирования MPU, а именно наличию механизма перекрытия (overlap) и тому факту, что регион с большим ID имеет более высокий приоритет, это фактически дало нам возможность записывать в нужную секцию свои данные.

Оставалось воспользоваться указателем на наши данные (он все еще лежит в R2) и пропатчить только что разблокированную на запись секцию кода. Самый простой путь — добавить свой код в обработчик протокола NAS. Для этого мы воспользовались одной из команд протокола — MM information. С ее помощью можно за один раз переслать большой объем данных, а в ответ получить один байт по команде MM status, подтверждающий, что код успешно пропатчен.

В итоге нам удалось не только получить возможность исполнения своего кода на стороне модема, но и установить с ним полноценную двухстороннюю связь, используя высокоуровневый протокол NAS в качестве способа доставки сообщений. В данном случае это пакет MM Status с полем cause, равным 0хАА.

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

Полную версию материала с подробным описанием разработки эксплойта для АР и запуском DOOM на головном устройстве автомобиля читайте на сайте ICS CERT.