Уязвимость UNICOS: Новые возможности для атак на мобильные устройства.

21 июня 2022 г. 15:34
 558

Команда CPR провела анализ модема UNISOC и обнаружила способ удаленной атаки на устройства.

Исследователь: Слава Маккавеев.

Введение.

Помните кнопочные телефоны? Многие из них были основаны на чипах Spreadtrum Communications Inc. - китайского производителя, основанного в 2001 году. В 2011 году более половины всех телефонов в Китае работали на чипах Spreadtrum.

В 2018 году Spreadtrum провела ребрендинг и стала известна как UNISOC. Сегодня данный производитель выпускает бюджетные чипсеты, которые обеспечивают работу устройств 2/3/4/5G - от смартфонов до смарт-телевизоров. Чипы UNISOC чрезвычайно популярны в Африке и Азии благодаря своим низким ценам. К концу 2021 года UNISOC прочно заняла четвертое место среди крупнейших производителей чипов для смартфонов в мире (после MediaTek, Qualcomm и Apple) с долей в 11% мирового рынка.

Несмотря на то, что UNISOC уже давно присутствует на рынке, прошивка чипов UNISOC, используемых в мобильных телефонах Android, включая радиомодем (baseband), не была подробно изучена. В Интернете нет ссылок на какие-либо уязвимости модемов UNISOC.

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

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

Обзор LTE.

Место модема смартфона в сети LTE.

Сеть Long-Term Evolution (LTE) состоит из десятка компонентов и протоколов. Подробное описание стандарта LTE можно легко найти в Интернете. Давайте рассмотрим некоторые базовые концепции, чтобы понять, что такое модем UNISOC.

Группа телекоммуникационных стандартов 3GPP представила концепцию развитой пакетной системы (Evolved Packet System, EPS), которая является высокоуровневой архитектурой технологии LTE. Такая архитектура состоит из трех ключевых компонентов: пользовательского оборудования (UE), развитой наземной сети радиодоступа UMTS (E-UTRAN) и развитого пакетного ядра (EPC), которые взаимосвязаны между собой.

 

Рис. 1: Архитектура EPS сети LTE.

 

Компонент E-UTRAN имеет только один стек - станцию eNodeB, которая управляет радиосвязью между UE и EPC. UE может быть подключен к одной eNodeB одновременно.

Компонент EPC состоит из четырех стеков, одним из которых является организация управления мобильностью (MME). MME управляет высокоуровневыми операциями мобильных устройств в сети LTE. Он отправляет сигнальные сообщения, связанные с управлением безопасностью, управлением зоной слежения, поддерживает мобильность между различными сетями доступа 3GPP, а также управление поднесущими EPS.

Для нас UE - это смартфон с модемом UNISOC. В нашем исследовании мы сосредоточились на обмене сообщениями между стеком MME и стеком UE, который происходит через протоколы EPS session management (ESM) и EPS mobility management (EMM).

На рисунке 2 показан стек протоколов модема. На уровне non-access stratum (NAS) размещаются сигнальные сообщения EPS и EMM.

 

Рис. 2: Стеки протоколов LTE.

 

Протокол NAS оперирует высокоуровневыми структурами. Поэтому злоумышленнику не потребуется много усилий, чтобы создать деформированный пакет EMM и отправить его на целевое устройство. Когда приходит новое сообщение NAS, модем UNISOC анализирует его и создает внутренние объекты на основе полученных данных. Ошибка в коде разбора может быть использованпрпп а злоумышленником для удаленного выхода модема из строя, что может привести к отказу в обслуживании (DoS) или удаленному выполнению кода (RCE).

 

Обмен сообщениями между модемом и MME.

Полную техническую спецификацию протокола NAS можно найти в документе 3GPP TS 24.301. Чтобы получить представление о протоколе, давайте рассмотрим процедуру добавления устройства в сеть LTE. Она охватывает наиболее распространенные сообщения EMM. На рисунке 3 показан фрагмент трафика NAS при подключении смартфона к сети LTE.

 

Рис. 3: Поток подключения к сети.

 

В примере IP-адрес модема - 10.90.10.1, а IP-адрес MME - 10.201.150.41. Обмен сообщениями происходит по схеме, показанной на рисунке 4.

 

Рис. 4: Схема обмена сообщениями.

 

Как вы видите, когда устройство подключается к сети LTE, сервер MME заботится об аутентификации устройства, установлении несущей и многом другом. Для подключения к сети модем смартфона должен поддерживать (предоставлять обработчики) десятки сообщений NAS. Мы хотим проанализировать эти обработчики на предмет ошибок.

Прежде чем мы изучим реализацию обработчиков сообщений NAS в модеме UNISOC, мы посмотрим на эти обработчики в популярном проекте LTE с открытым исходным кодом, таком как srsRAN, потому что проще иметь дело с исходным кодом, чем с дизассемблированием. Стек UE не менялся уже долгое время, и все его реализации очень похожи друг на друга. Кроме того, некоторые функции обработчика NAS, реализованные в проекте srsRAN, уязвимы, и эти уязвимости теоретически могут быть воспроизведены в модеме смартфона.

 

UE-стек с открытым исходным кодом.

srsRAN является наиболее популярной реализацией компонентов EPS с открытым исходным кодом, включая интересующий нас стек UE. Модуль srsue/src/stack/upper/nas.cc представляет уровень NAS. В нем вы можете найти функции, которые обрабатывают сообщения NAS.

 

Рис. 5

 

Каждая функция-обработчик получает сообщение в виде блока данных, который должен быть разобран на внутренние структуры, прежде чем система сможет на него отреагировать. Функции разбора реализованы в модуле lib/src/asn1/liblte_mme.cc.

На рисунке 6 показан пример EMM-сообщения ATTACH_ACCEPT. Это сообщение содержит список идентификаторов зон слежения, таймер GPRS, контейнер сообщения ESM и десяток необязательных объектов, таких как идентификатор мобильного телефона, номера экстренных служб, параметры конфигурации протокола и т.д.

 

Рис. 6: Сообщение Attach Accept.

 

Таким образом, мы имеем большое количество разнородной информации, которую необходимо десериализовать. Модуль liblte_mme.cc содержит отдельную функцию распаковки (парсинга) для каждого типа содержимого. Код модема UNISOC имеет аналогичные функции.

Обработчик сообщений ATTACH_ACCEPT проекта srsRAN имеет несколько уязвимостей. Рассмотрим одну из них в качестве примера.

Функция liblte_mme_unpack_emergency_number_list_ie извлекает номера экстренных служб из данных сообщения.

 

Рис. 7

 

Максимальная длина списка экстренных номеров - 12. Однако проверка того, что значение idx меньше 12, была опущена. MME может установить значение sent_length достаточно большим, чтобы вызвать более 12 циклов цикла while и таким образом перезаписать массив emerg_num_list->emerg_num произвольными значениями. Эта проблема приводит к переполнению стека.

Аналогичная уязвимость существует в функции liblte_mme_unpack_protocol_config_options_ie, которая анализирует опции конфигурации протокола, используемые для передачи дополнительной информации о сети. Максимальное количество поддерживаемых опций - 83, но нет проверки, что количество опций, передаваемых MME, не превышает этот максимум. Переполнение массива опций приводит к переполнению стека.

Мы знаем, что представляют собой функции разбора сообщений NAS, и у нас также есть код для ссылок. Теперь нам нужно найти функции разбора данных NAS в прошивке модема UNISOC.

Модемная прошивка UNICOS.

В нашем исследовании в качестве тестового устройства мы использовали Motorola Moto G20 (XT2128-2) с обновлением Android January 2022 (RTAS31.68.29). Устройство основано на чипе UNISOC T700.

Заводское обновление Moto G20 можно загрузить из Интернета, что избавляет от необходимости рутовать устройство.

В файле обновления прошивка модема представлена образом SC9600_sharkl5pro_pubcp_modem.dat.

Образ имеет проприетарную структуру, но ее можно легко восстановить. Он начинается с «магии», за которой следуют заголовки блоков данных. Заголовок блока имеет следующую структуру:

 

Рис. 8

 

Значение offset - это смещение в байтах начала блока в файле образа, а длина - это размер блока.

На рисунке 9 видно, что образ модема нашего тестового устройства содержит два блока данных. Первый блок имеет тип 0x402, что предположительно означает «библиотека парсинга». Второй блок имеет тип 0x301, который является двоичным кодом модема.

 

Рис. 9: Заголовок образа модема.

 

Мы можем легко вырезать оба блока данных из изображения. Блок библиотеки парсинга - это 7-zip архив, который содержит библиотеки для тестирования (парсинга и трассировки) сетевых сообщений с внешней машины. Например, библиотека lteps_air_msg_dll.dll (скомпилированная для x86) реализует функции для упаковки и распаковки сообщений NAS.

Двоичный блок модема представляет собой файл с проприетарным форматом. Размер заголовка составляет 0x600 байт. После заголовка начинается код модема (инструкции ARM). Мы обернули этот код заголовком ELF32 и указали 0x8B000600 в качестве базового адреса сегмента кода. Кроме того, мы добавили пустой сегмент данных, начинающийся с адреса 0x8D0C0000. Полученный двоичный файл можно легко декомпилировать.

Сообщения журнала, реализованные в микропрограмме модема, содержат имя текущего исходного модуля. Это дает нам возможность быстро найти обработчики сообщений NAS. Имена модулей, связанных с NAS, начинаются с «lnas_air_msg».

Например, модуль PS/stack/nas/emm/msg_codec/msg_emm/lnas_air_msg_emm_att_acc.c анализирует сообщение ATTACH_ACCEPT.

 

Поиск уязвимостей в обработчиках NAS.

Подавляющее большинство обработчиков сообщений NAS имеют три аргумента: выходной буфер, который является объектом соответствующей структуры сообщения, блоб данных сообщения NAS для декодирования и текущее смещение в блобе сообщения. Унифицированный формат функций позволяет нам легко реализовать обвязку для фаззинга функций разбора NAS. В нашем исследовании мы использовали классическую комбинацию AFL и QEMU, чтобы проверить двоичный файл модема на ПК. Мы исправили двоичный файл модема, чтобы перенаправить вызовы malloc на эквивалент libc. Фаззер изменял данные сообщения NAS и передавал их в качестве входного буфера функции синтаксического анализа.

Одним из необязательных полей ATTACH_ACCEPT является идентификатор мобильного телефона. Микропрограмма модема реализует функцию распаковки, подобную liblte_mme_unpack_mobile_id_ie из srsRAN, для извлечения идентификатора мобильного телефона из сообщения NAS. Блок данных идентификатора начинается с длины идентификатора. Если устройство представлено международным идентификатором мобильного абонента (IMSI), длина-2 байта данных сообщения копируется в выходной буфер как номер IMSI.

Проверка на то, что предоставленное значение length больше единицы, опускается. Поэтому, если значение поля length равно нулю, из сообщения NAS в память кучи копируются байты 0-2 = 0xFFFFFFFE, что приводит к DoS.

 

Рис. 10: Деформированное сообщение NAS.

 

На рисунке 11 показано сообщение ATTACH_ACCEPT, которое вызывает переполнение.

 

Рис. 11: Деформированное сообщение NAS.

 

Выделенное значение 0x23 указывает на то, что следующие данные являются блоком идентификации сообщения, где первый 0x01 - длина, а второй 0x01 - тип IMSI.

UNISOC присвоил этой уязвимости номер CVE-2022-20210. Кроме того, мы обнаружили несколько проблем с чтением out-of-bound, когда функции обработчика NAS считывали данные из-за пределов сообщения NAS.

Заключение.

В данном исследовании мы впервые рассмотрели модем UNISOC в качестве объекта атаки. Мы просканировали обработчики сообщений NAS за короткий промежуток времени и обнаружили уязвимость, которая может быть использована для нарушения связи устройства с помощью неправильно сформированного пакета. Хакеры или разведывательные службы могут использовать такую уязвимость для нейтрализации связи в определенной локации.

Компания CPR ответственно сообщила об этих находках компании UNISOC в мае 2022 года, которая признала наличие уязвимости, присвоив ей рейтинг 9,4 балла (критическая). После этого UNISOC исправила уязвимость CVE-2022-20210 в мае 2022 года.

Клиенты Check Point остаются полностью защищенными от подобных угроз при использовании Harmony Mobile Security.

Мы рекомендуем пользователям мобильных устройств всегда обновлять ОС своего телефона до последней версии. Компания Google сообщила, что патч будет опубликован в ближайшем бюллетене Android Security.

Источник: https://research.checkpoint.com

Системы Информационной Безопасности