1. Введение
В последние годы мы стали свидетелями широкого распространения сотовых сетей 5G как для потребительских устройств, так и для IoT и критической инфраструктуры. Оценка количества устройств, подключенных к сети 5G, разнится, но все они огромны [1]. Каждое из этих устройств для подключения к сети 5G должно быть оснащено модемом 5G, отвечающим за модуляцию сигнала и реализацию протоколов радиосвязи. Этот компонент также обычно называют «основной полосой». Защита этих компонентов имеет первостепенное значение, поскольку они обрабатывают недостоверные данные из радиосети, что делает их особенно привлекательными для удаленного злоумышленника. В нашей предыдущей работе [2] мы исследовали безопасность этих модемов в сетях предыдущего поколения, таких как 2G, 3G или 4G, и добились полного удаленного выполнения кода по радиоканалу. Это было 3 года назад, а 5G уже запущен. В этой статье мы рассмотрим, что изменилось, что улучшилось, а что нет. Мы продемонстрируем, что по-прежнему можно полностью скомпрометировать модем по радиоканалу, преднамеренно пытаясь найти ошибку в стеке 5G и использовать ее по радиоканалу, получая удаленное выполнение кода на смартфоне 5G.
2. Описание
Безопасность сетей 5G и основной полосы частот — это темы, которые не были полностью освещены на протяжении многих лет. В нашей предыдущей работе изучалась безопасность сетей старого поколения и изучалась реализация модема Huawei [2]. Исследователь безопасности Амат Кама также опубликовал исследование сетей старого поколения, показывающее, как можно было успешно скомпрометировать основную полосу частот Samsung Shannon на конкурсе pwn2own [3]. Наконец, исследование Comsecuris проанализировало аспекты безопасности как Samsung [4], так и Intel [5]. Мы настоятельно рекомендуем эти ресурсы в качестве справочного материала для понимания этого документа и ознакомления с темой. Чтобы полностью понять это исследование, мы рассмотрим некоторые базовые понятия и опишем новые понятия сетей 5G.
3. Подготовка исследования и методология
Итак, требования и цели нашего исследования:
- Идентификация цели: мы приобрели основные устройства 5G, доступные на момент исследования.
- Область применения: найти подходящую уязвимость в компоненте 5G, которую можно запустить удаленно и надежно для удаленного выполнения кода.
- Исполнение: найти способ активировать нашу уязвимость, не имея доступа к какой-либо коммерческой базовой станции 5G. На момент проведения исследования не существовало работающего проекта базовой станции 5G с открытым исходным кодом.
4. Идентификация цели
Мы приобрели несколько потребительских смартфонов 5G, доступных в то время. Все приобретенные нами устройства могли, по крайней мере, использовать так называемое «Новое радио» 5G.
Мы должны различать устройства 5G:
Неавтономный режим (NSA): этот режим сочетает в себе New Radio 5G и использует другие компоненты сети 4G.
Автономный режим (SA): этот режим полностью реализует и использует спецификацию 5G New Radio и сети 5G.
Поскольку мы считаем, что автономный режим (SA) будет использоваться в качестве стандарта в будущем, мы решили сосредоточиться на этом режиме.
Нашим исследовательским устройством будет VivoS65G, устройство с автономным режимом работы 5G.
Это устройство поставляется с SoC Exynos 980 и имеет базовую полосу частот Samsung Shannon [3] [4].
Базовая полоса запускает собственную прошивку с операционной системой реального времени на собственном ядре ARM Cortex, отделенном от процессора приложений (AP), на котором работает ОС Android. Точка доступа и основная полоса могут, например, взаимодействовать с PCI-e, общей памятью или другими способами [2]. Мы восстановили прошивку модема с полного ОТА устройства. Микропрограмма основной полосы находится в моде м. b в двоичном файле. Распаковав его и найдя адреса загрузки, мы можем загрузить его в IDA Pro и начать поиск уязвимостей.
5. Объем аудита и поиск уязвимостей
После некоторого времени аудита кода, связанного с 5G, мы собрали наши уязвимости и выбрали лучшего кандидата для этого исследования, чтобы поделиться им.
Благодаря обилию уязвимостей мы смогли выбрать одну очень надежную.
Мы надеемся, что вы также найдете её интересным и это описшет текущее состояние безопасности модемов.
При проверке прошивки модема мы быстро заметили, что в ней по-прежнему отсутствуют cookie для стека.
Таким образом, использование традиционного переполнения стека упростило бы нашу эксплуатацию, учитывая отсутствие возможностей отладки в этой среде.
Как вы понимаете, ошибка, которую мы выбрали для этой статьи, — это переполнение стека.
Интересно то, что это не только переполнение стека, но и переполнение стека в синтаксическом анализаторе XML внутри основной полосы частот.
Этот синтаксический анализатор XML отвечает за разбор сообщений IMS из сети на модем устройства.
5.1. Векторный фон атаки
IMS — это выбранная архитектура для сетей 4G и 5G, поверх которой построен интерактивный вызов, и позже мы увидим, почему это важно для данного исследования.
Основная частота — это клиент IMS, отвечающий за обработку сообщений VoLTE, VoNR, поэтому он должен иметь возможность обрабатывать сообщения SIP, которые сервер IMS использует для связи с модемом.
Далее пример сообщения:
SIP — это текстовый протокол, похожий на HTTP, включая заголовки и контент. Получатель (в данном случае основная полоса частот) должен проанализировать сообщение с сервера. Для разных сообщений содержимым могут быть не только пары ключ-значение, но и текст в формате XML. XML — гораздо более сложный формат данных, который обычно обрабатывается специальной библиотекой. Все вышеперечисленное представляет новую поверхность атаки для базовых полос.
5.2. Уязвимость
Наша ошибка удаленного выполнения кода OTA находится в части основной полосы частот IMS. При анализе XML-содержимого сообщения протокола SIP вызывается функция IMSPL_XmlGetNextTagName.
Этот модем не имеет отладочных символов или информации, поэтому все имена функций, типы и сигнатуры функций восстанавливаются либо вручную из строк журнала, либо путем обратного проектирования.
Здесь мы приводим реконструированную и декомпилированную версию с опущенными комментариями и некоторым кодом.
Эта функция будет анализировать тег XML из src и копировать его имя в dst , например. <metaname = ”viewport”
content = ”width = device - width , initial - scale = 1 ” > скопирует “meta” в буфер назначения.
Далее мы представляем декомпилированную функцию find_tag_end (произвольно выбранное имя) и объясняем, как она работает:
Функция ищет конец тега, пропуская специальные символы, например. пробел, '/', '>', '?'. Разобравшись, как работает вся эта функция, мы заметили, что проверок безопасности нет вообще. Функция не знает, какова длина буфера назначения, равно как и исходный буфер. Таким образом, все вызывающие функции могут быть использованы с традиционным переполнением буфера.
С помощью перекрестных ссылок на функцию IMSPL_XmlGetNextTagName мы нашли сотни мест вызова. Большинство из них уязвимы, поскольку исходный буфер извлекается из сообщения OTA, которое полностью контролируется злоумышленником.
6. Эксплуатация
Мы выбрали переполнение стека из-за простоты эксплуатации и надежности. Как мы уже говорили ранее, cookie стека нет, поэтому мы можем просто переполнить буфер, управлять обратным адресом, хранящимся в стеке, и получить выполнение кода.
Наконец мы нашли хорошего кандидата с помощью реверс-инжиниринга:
Мы можем легко подтвердить, что переменная v11 является буфером в стеке размером 100. Здесь может произойти потенциальное переполнение стека. Подобные проблемы были обнаружены в ближайших функциях, таких как IMSPL_XmlParser_ContElemChildNodeDecode и т. д.
По названию функции мы можем сделать вывод, что запускающий тег должен находиться внутри элемента Contact List. Нетрудно обобщить стеки вызовов, обратившись к функции вверх.
Эти имена функций просты для понимания. Мы можем быстро определить, что искаженная полезная нагрузка может быть доставлена с помощью сообщения NOTIFY в протоколе SIP. Простой PoC может быть создан из обычного сообщения NOTIFY для сбоя основной полосы частот.
Поскольку полезная нагрузка доставляется в формате XML, на нее накладываются ограничения. Помните функцию find_tag_end, упомянутую выше, она заносит в черный список следующие символы в имени тега: ”\x00\x09\x0a \x0d\x20\x2f\x3e\х3”. Таким образом, мы не можем использовать все доступные гаджеты при написании ROP-цепочек и шелл-кода.
Осталось только традиционное испытание на платформе ARM.
Вот аварийный PoC, который повредит стек в функции IMSPL_XmlParser_REgLstDecode:
Чтобы избежать проблем с исправлением стека и оставить основную частоту еще живой после выполнения ROP, лучше выбрать более глубокое место для переполнения стека.
Структура полезной нагрузки в деталях:
6.2. Визуальная демонстрация эксплойта
Чтобы проверить, получили ли мы RCE на целевом устройстве, мы можем проверить журнал ADB телефона. Он покажет информацию о том, как происходит сбой сотового процессора (CP). Однако это не удобный способ и не хороший визуальный эффект. Таким образом, мы решили изменить IMEI устройства, выполнив шелл-код внутри основного диапазона.
Предполагается, что IMEI не должен изменяться после прошивки телефона. Это также рассматривалось как проблема, когда мы сообщали о всей цепочке.
IMEI — это элемент, хранящийся в NVRAM, но для изменения его значения необходимо сначала знать его индекс. NVRAM — энергонезависимая память, в которой хранится постоянная информация, относящаяся к модему.
В основной памяти есть несколько мест, вызывающих функцию для получения IMEI. Индекс можно получить, обратив функции Get_Imei_[12] . В нашем случае индексы для IMEI1/2 — 0x39a4/0x39a5.
С помощью индекса мы можем изменить IMEI в шеллкоде, вызвав API
7. Исполнение
7.1. Настройка среды
Чтобы вызвать ошибку, нам нужно сначала построить сеть, которая предоставляет услуги IMS, а затем отправить искаженное текстовое сообщение в память. Для нашей тестовой среды требуется как минимум сеть LTE. Хотя технически это уязвимость, затрагивающая как 4G, так и 5G, к началу 2020 года инфраструктура 5G еще не была завершена для поддержки независимых исследователей, таких как мы, тестирующих ее безопасность. Мы приняли решение настроить сеть LTE с поддержкой VoLTE для тестирования устройства.
7.1.1. Выбор СДР
В качестве аппаратного обеспечения для установки базовой станции мы выбрали Ettus US RPB210 , очень популярную среди исследователей SDR-радиостанцию.
SDR — это программно определяемое радио. Обычно он содержит программируемую ПЛИС и аналоговую часть для модуляции и демодуляции сигнала. Это аппаратное обеспечение, ответственное за передачу и прием наших сигналов, когда мы настраиваем базовую станцию.
7.1.2. настройка LTE-сети
Для завершения теста мы использовали множество компонентов и оборудования с открытым исходным кодом. Далее, важные.
- srsENB: это реализация eNodeB от srsLTE. Он подключается к сети мобильных телефонов, которая напрямую связывается по беспроводной сети с мобильными телефонами (UE). [6]
- Open5GS: мы использовали его реализацию EPC в сети LTE. Это hss, mme, pcrf,
pgw, sgw. [7]
- sysmo-usim-tool & pysim: Инструменты для программирования SIM-карт. [8] [9]
- CoIMS и CoIMS_Wiki: инструменты для переопределения настроек IMS телефона. [10] [11]
- docker_open5gs: файлы Docker для запуска open5gs с поддержкой VoLTE в контейнере Docker.
UE может подключиться к сети после правильной настройки сети LTE, после чего мы можем перейти к настройкам сервера IMS.
Во время нашего теста почти все базовые полосы от разных производителей были чрезвычайно чувствительны к частоте eNodeB. Можно проверить официальную информацию об устройстве, чтобы узнать о поддерживаемых диапазонах. Затем выберите правильный EARFCN нисходящего канала для srsENB.
Например, мы использовали DL-EARFCN 1825 для Samsung Galaxy S9 и 1575 для Vivo S6 5G.
После успешного подключения телефона вносить какие-либо изменения для этого номера не рекомендуется.
7.2. Настройка и взлом сервера IMS
Поскольку уязвимость может быть вызвана только вредоносным сервером IMS, предоставляющим услугу VoIP, базовой сети LTE недостаточно, чтобы вызвать ошибку. К сожалению, инфраструктура для этого спроса далека от зрелости. Существующий проект с открытым исходным кодом Kamailio удовлетворяет наши потребности, но он еще недостаточно протестирован на всех видах устройств, в том числе и на нашем. Потребовались огромные усилия, чтобы заставить его работать и успешно доставить полезную нагрузку.
Основными компонентами сервера VoLTE являются Rtpengine, FHOSS, P-CSCF, I-CSCF и S-CSCF. Далее топология сети:
Сообщение IMS (SIP) передается в виде данных IP через сокет TCP или UDP. Таким образом, клиенты предпочитают безопасность на уровне IP (IPSec) для транзакций IMS/SIP. Полезная нагрузка XML может быть передана только сообщением NOTIFY, поэтому наш клиент должен успешно ЗАРЕГИСТРИРОВАТЬСЯ и ПОДПИСАТЬСЯ.
После первоначальной настройки мы смогли подключиться к услуге VoLTE с нескольких устройств, например. OnePlus 6 (без IPSec), Google Pixel 3 (IPSec), что означает, что пакет хорошо работает с базовыми частотами Qualcomm. Однако, когда речь идет об устройствах Samsung, процесс регистрации не удастся.
Устройства смогли зарегистрировать VoLTE с обычной SIM-картой местных операторов, и это дало нам надежду на взлом конфигураций и кода Kamailio. Первым шагом была фиксация удачной регистрации трафика на телефоне. К счастью, в Samsung Sysdump Utility есть встроенный инструмент отладки IMS под названием IMS Logger, который позволяет нам просматривать трафик IMS из приложения [13]. Далее показан обычное регистрационное сообщение и его ответ:
Есть несколько различий между Kamailio и местным оператором. Мы действительно не знаем, какое поле является ключом к неудачной регистрации. Наш подход заключался в том, чтобы сделать их максимально похожими.
После внесения некоторых изменений в Kamailio мы получили небольшой прогресс и получили второе регистрационное сообщение. Затем проблема переходит на сторону сервера, ответ STATUS 200 не предоставляется.
Исследования показывают, что IPSec между сервером и клиентом несовместим. Мы решили принудительно отключить IPSec со стороны сервера. Далее набор патчей, которые мы применили:
7.2.1. References
7.3. Доставка полезной нагрузки
Как только UE будет зарегистрировано и подписано на SIP-сервере, сервер отправит сообщение NOTIFY, чтобы предоставить важную информацию в сети, такую как контактные данные других UE. Полезная нагрузка находится в сообщении NOTIFY в формате XML.
Единицей, ответственной за это сообщение, является S-CSCF.
Это функция, которую нужно изменить для создания произвольного содержимого полезной нагрузки:
8. Демонстрация экслпоита
Мы записали видео эксплойта на этом устройстве, которое мы загрузили здесь [14].
9. Выводы
В этом исследовании мы представили состояние безопасности базовой полосы 5G, которой оснащены Android-устройства следующего поколения. Несмотря на то, что с точки зрения функционирования сети произошла эволюция, мы увидели, что с точки зрения безопасности все еще нет прогресса. Как мы показали на самом деле, в некоторых моделях полностью отсутствуют самые основные меры безопасности, такие как cookie стека, что позволяет использовать простые атаки, такие как переполнение буфера, для их компрометации по радиоканалу.
После нашего предыдущего исследования, проведенного 3 года назад, кажется, что особых улучшений не произошло. Мы надеемся, что через 3 года мы сможем снова представить некоторые исследования, но в более жесткой среде.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: Marco Grassi (@marcograss)1, Xingyu Chen (@0xKira233)1
В последние годы мы стали свидетелями широкого распространения сотовых сетей 5G как для потребительских устройств, так и для IoT и критической инфраструктуры. Оценка количества устройств, подключенных к сети 5G, разнится, но все они огромны [1]. Каждое из этих устройств для подключения к сети 5G должно быть оснащено модемом 5G, отвечающим за модуляцию сигнала и реализацию протоколов радиосвязи. Этот компонент также обычно называют «основной полосой». Защита этих компонентов имеет первостепенное значение, поскольку они обрабатывают недостоверные данные из радиосети, что делает их особенно привлекательными для удаленного злоумышленника. В нашей предыдущей работе [2] мы исследовали безопасность этих модемов в сетях предыдущего поколения, таких как 2G, 3G или 4G, и добились полного удаленного выполнения кода по радиоканалу. Это было 3 года назад, а 5G уже запущен. В этой статье мы рассмотрим, что изменилось, что улучшилось, а что нет. Мы продемонстрируем, что по-прежнему можно полностью скомпрометировать модем по радиоканалу, преднамеренно пытаясь найти ошибку в стеке 5G и использовать ее по радиоканалу, получая удаленное выполнение кода на смартфоне 5G.
2. Описание
Безопасность сетей 5G и основной полосы частот — это темы, которые не были полностью освещены на протяжении многих лет. В нашей предыдущей работе изучалась безопасность сетей старого поколения и изучалась реализация модема Huawei [2]. Исследователь безопасности Амат Кама также опубликовал исследование сетей старого поколения, показывающее, как можно было успешно скомпрометировать основную полосу частот Samsung Shannon на конкурсе pwn2own [3]. Наконец, исследование Comsecuris проанализировало аспекты безопасности как Samsung [4], так и Intel [5]. Мы настоятельно рекомендуем эти ресурсы в качестве справочного материала для понимания этого документа и ознакомления с темой. Чтобы полностью понять это исследование, мы рассмотрим некоторые базовые понятия и опишем новые понятия сетей 5G.
3. Подготовка исследования и методология
Итак, требования и цели нашего исследования:
- Идентификация цели: мы приобрели основные устройства 5G, доступные на момент исследования.
- Область применения: найти подходящую уязвимость в компоненте 5G, которую можно запустить удаленно и надежно для удаленного выполнения кода.
- Исполнение: найти способ активировать нашу уязвимость, не имея доступа к какой-либо коммерческой базовой станции 5G. На момент проведения исследования не существовало работающего проекта базовой станции 5G с открытым исходным кодом.
4. Идентификация цели
Мы приобрели несколько потребительских смартфонов 5G, доступных в то время. Все приобретенные нами устройства могли, по крайней мере, использовать так называемое «Новое радио» 5G.
Мы должны различать устройства 5G:
Неавтономный режим (NSA): этот режим сочетает в себе New Radio 5G и использует другие компоненты сети 4G.
Автономный режим (SA): этот режим полностью реализует и использует спецификацию 5G New Radio и сети 5G.
Поскольку мы считаем, что автономный режим (SA) будет использоваться в качестве стандарта в будущем, мы решили сосредоточиться на этом режиме.
Нашим исследовательским устройством будет VivoS65G, устройство с автономным режимом работы 5G.
Это устройство поставляется с SoC Exynos 980 и имеет базовую полосу частот Samsung Shannon [3] [4].
Базовая полоса запускает собственную прошивку с операционной системой реального времени на собственном ядре ARM Cortex, отделенном от процессора приложений (AP), на котором работает ОС Android. Точка доступа и основная полоса могут, например, взаимодействовать с PCI-e, общей памятью или другими способами [2]. Мы восстановили прошивку модема с полного ОТА устройства. Микропрограмма основной полосы находится в моде м. b в двоичном файле. Распаковав его и найдя адреса загрузки, мы можем загрузить его в IDA Pro и начать поиск уязвимостей.
5. Объем аудита и поиск уязвимостей
После некоторого времени аудита кода, связанного с 5G, мы собрали наши уязвимости и выбрали лучшего кандидата для этого исследования, чтобы поделиться им.
Благодаря обилию уязвимостей мы смогли выбрать одну очень надежную.
Мы надеемся, что вы также найдете её интересным и это описшет текущее состояние безопасности модемов.
При проверке прошивки модема мы быстро заметили, что в ней по-прежнему отсутствуют cookie для стека.
Таким образом, использование традиционного переполнения стека упростило бы нашу эксплуатацию, учитывая отсутствие возможностей отладки в этой среде.
Как вы понимаете, ошибка, которую мы выбрали для этой статьи, — это переполнение стека.
Интересно то, что это не только переполнение стека, но и переполнение стека в синтаксическом анализаторе XML внутри основной полосы частот.
Этот синтаксический анализатор XML отвечает за разбор сообщений IMS из сети на модем устройства.
5.1. Векторный фон атаки
IMS — это выбранная архитектура для сетей 4G и 5G, поверх которой построен интерактивный вызов, и позже мы увидим, почему это важно для данного исследования.
Основная частота — это клиент IMS, отвечающий за обработку сообщений VoLTE, VoNR, поэтому он должен иметь возможность обрабатывать сообщения SIP, которые сервер IMS использует для связи с модемом.
Далее пример сообщения:
SIP — это текстовый протокол, похожий на HTTP, включая заголовки и контент. Получатель (в данном случае основная полоса частот) должен проанализировать сообщение с сервера. Для разных сообщений содержимым могут быть не только пары ключ-значение, но и текст в формате XML. XML — гораздо более сложный формат данных, который обычно обрабатывается специальной библиотекой. Все вышеперечисленное представляет новую поверхность атаки для базовых полос.
5.2. Уязвимость
Наша ошибка удаленного выполнения кода OTA находится в части основной полосы частот IMS. При анализе XML-содержимого сообщения протокола SIP вызывается функция IMSPL_XmlGetNextTagName.
Этот модем не имеет отладочных символов или информации, поэтому все имена функций, типы и сигнатуры функций восстанавливаются либо вручную из строк журнала, либо путем обратного проектирования.
Здесь мы приводим реконструированную и декомпилированную версию с опущенными комментариями и некоторым кодом.
Эта функция будет анализировать тег XML из src и копировать его имя в dst , например. <metaname = ”viewport”
content = ”width = device - width , initial - scale = 1 ” > скопирует “meta” в буфер назначения.
Далее мы представляем декомпилированную функцию find_tag_end (произвольно выбранное имя) и объясняем, как она работает:
Функция ищет конец тега, пропуская специальные символы, например. пробел, '/', '>', '?'. Разобравшись, как работает вся эта функция, мы заметили, что проверок безопасности нет вообще. Функция не знает, какова длина буфера назначения, равно как и исходный буфер. Таким образом, все вызывающие функции могут быть использованы с традиционным переполнением буфера.
С помощью перекрестных ссылок на функцию IMSPL_XmlGetNextTagName мы нашли сотни мест вызова. Большинство из них уязвимы, поскольку исходный буфер извлекается из сообщения OTA, которое полностью контролируется злоумышленником.
6. Эксплуатация
Мы выбрали переполнение стека из-за простоты эксплуатации и надежности. Как мы уже говорили ранее, cookie стека нет, поэтому мы можем просто переполнить буфер, управлять обратным адресом, хранящимся в стеке, и получить выполнение кода.
Наконец мы нашли хорошего кандидата с помощью реверс-инжиниринга:
Мы можем легко подтвердить, что переменная v11 является буфером в стеке размером 100. Здесь может произойти потенциальное переполнение стека. Подобные проблемы были обнаружены в ближайших функциях, таких как IMSPL_XmlParser_ContElemChildNodeDecode и т. д.
По названию функции мы можем сделать вывод, что запускающий тег должен находиться внутри элемента Contact List. Нетрудно обобщить стеки вызовов, обратившись к функции вверх.
Эти имена функций просты для понимания. Мы можем быстро определить, что искаженная полезная нагрузка может быть доставлена с помощью сообщения NOTIFY в протоколе SIP. Простой PoC может быть создан из обычного сообщения NOTIFY для сбоя основной полосы частот.
Поскольку полезная нагрузка доставляется в формате XML, на нее накладываются ограничения. Помните функцию find_tag_end, упомянутую выше, она заносит в черный список следующие символы в имени тега: ”\x00\x09\x0a \x0d\x20\x2f\x3e\х3”. Таким образом, мы не можем использовать все доступные гаджеты при написании ROP-цепочек и шелл-кода.
Осталось только традиционное испытание на платформе ARM.
Вот аварийный PoC, который повредит стек в функции IMSPL_XmlParser_REgLstDecode:
Чтобы избежать проблем с исправлением стека и оставить основную частоту еще живой после выполнения ROP, лучше выбрать более глубокое место для переполнения стека.
Структура полезной нагрузки в деталях:
6.2. Визуальная демонстрация эксплойта
Чтобы проверить, получили ли мы RCE на целевом устройстве, мы можем проверить журнал ADB телефона. Он покажет информацию о том, как происходит сбой сотового процессора (CP). Однако это не удобный способ и не хороший визуальный эффект. Таким образом, мы решили изменить IMEI устройства, выполнив шелл-код внутри основного диапазона.
Предполагается, что IMEI не должен изменяться после прошивки телефона. Это также рассматривалось как проблема, когда мы сообщали о всей цепочке.
IMEI — это элемент, хранящийся в NVRAM, но для изменения его значения необходимо сначала знать его индекс. NVRAM — энергонезависимая память, в которой хранится постоянная информация, относящаяся к модему.
В основной памяти есть несколько мест, вызывающих функцию для получения IMEI. Индекс можно получить, обратив функции Get_Imei_[12] . В нашем случае индексы для IMEI1/2 — 0x39a4/0x39a5.
С помощью индекса мы можем изменить IMEI в шеллкоде, вызвав API
7. Исполнение
7.1. Настройка среды
Чтобы вызвать ошибку, нам нужно сначала построить сеть, которая предоставляет услуги IMS, а затем отправить искаженное текстовое сообщение в память. Для нашей тестовой среды требуется как минимум сеть LTE. Хотя технически это уязвимость, затрагивающая как 4G, так и 5G, к началу 2020 года инфраструктура 5G еще не была завершена для поддержки независимых исследователей, таких как мы, тестирующих ее безопасность. Мы приняли решение настроить сеть LTE с поддержкой VoLTE для тестирования устройства.
7.1.1. Выбор СДР
В качестве аппаратного обеспечения для установки базовой станции мы выбрали Ettus US RPB210 , очень популярную среди исследователей SDR-радиостанцию.
SDR — это программно определяемое радио. Обычно он содержит программируемую ПЛИС и аналоговую часть для модуляции и демодуляции сигнала. Это аппаратное обеспечение, ответственное за передачу и прием наших сигналов, когда мы настраиваем базовую станцию.
7.1.2. настройка LTE-сети
Для завершения теста мы использовали множество компонентов и оборудования с открытым исходным кодом. Далее, важные.
- srsENB: это реализация eNodeB от srsLTE. Он подключается к сети мобильных телефонов, которая напрямую связывается по беспроводной сети с мобильными телефонами (UE). [6]
- Open5GS: мы использовали его реализацию EPC в сети LTE. Это hss, mme, pcrf,
pgw, sgw. [7]
- sysmo-usim-tool & pysim: Инструменты для программирования SIM-карт. [8] [9]
- CoIMS и CoIMS_Wiki: инструменты для переопределения настроек IMS телефона. [10] [11]
- docker_open5gs: файлы Docker для запуска open5gs с поддержкой VoLTE в контейнере Docker.
UE может подключиться к сети после правильной настройки сети LTE, после чего мы можем перейти к настройкам сервера IMS.
Во время нашего теста почти все базовые полосы от разных производителей были чрезвычайно чувствительны к частоте eNodeB. Можно проверить официальную информацию об устройстве, чтобы узнать о поддерживаемых диапазонах. Затем выберите правильный EARFCN нисходящего канала для srsENB.
Например, мы использовали DL-EARFCN 1825 для Samsung Galaxy S9 и 1575 для Vivo S6 5G.
После успешного подключения телефона вносить какие-либо изменения для этого номера не рекомендуется.
7.2. Настройка и взлом сервера IMS
Поскольку уязвимость может быть вызвана только вредоносным сервером IMS, предоставляющим услугу VoIP, базовой сети LTE недостаточно, чтобы вызвать ошибку. К сожалению, инфраструктура для этого спроса далека от зрелости. Существующий проект с открытым исходным кодом Kamailio удовлетворяет наши потребности, но он еще недостаточно протестирован на всех видах устройств, в том числе и на нашем. Потребовались огромные усилия, чтобы заставить его работать и успешно доставить полезную нагрузку.
Основными компонентами сервера VoLTE являются Rtpengine, FHOSS, P-CSCF, I-CSCF и S-CSCF. Далее топология сети:
Сообщение IMS (SIP) передается в виде данных IP через сокет TCP или UDP. Таким образом, клиенты предпочитают безопасность на уровне IP (IPSec) для транзакций IMS/SIP. Полезная нагрузка XML может быть передана только сообщением NOTIFY, поэтому наш клиент должен успешно ЗАРЕГИСТРИРОВАТЬСЯ и ПОДПИСАТЬСЯ.
После первоначальной настройки мы смогли подключиться к услуге VoLTE с нескольких устройств, например. OnePlus 6 (без IPSec), Google Pixel 3 (IPSec), что означает, что пакет хорошо работает с базовыми частотами Qualcomm. Однако, когда речь идет об устройствах Samsung, процесс регистрации не удастся.
Устройства смогли зарегистрировать VoLTE с обычной SIM-картой местных операторов, и это дало нам надежду на взлом конфигураций и кода Kamailio. Первым шагом была фиксация удачной регистрации трафика на телефоне. К счастью, в Samsung Sysdump Utility есть встроенный инструмент отладки IMS под названием IMS Logger, который позволяет нам просматривать трафик IMS из приложения [13]. Далее показан обычное регистрационное сообщение и его ответ:
Есть несколько различий между Kamailio и местным оператором. Мы действительно не знаем, какое поле является ключом к неудачной регистрации. Наш подход заключался в том, чтобы сделать их максимально похожими.
После внесения некоторых изменений в Kamailio мы получили небольшой прогресс и получили второе регистрационное сообщение. Затем проблема переходит на сторону сервера, ответ STATUS 200 не предоставляется.
Исследования показывают, что IPSec между сервером и клиентом несовместим. Мы решили принудительно отключить IPSec со стороны сервера. Далее набор патчей, которые мы применили:
7.2.1. References
7.3. Доставка полезной нагрузки
Как только UE будет зарегистрировано и подписано на SIP-сервере, сервер отправит сообщение NOTIFY, чтобы предоставить важную информацию в сети, такую как контактные данные других UE. Полезная нагрузка находится в сообщении NOTIFY в формате XML.
Единицей, ответственной за это сообщение, является S-CSCF.
Это функция, которую нужно изменить для создания произвольного содержимого полезной нагрузки:
8. Демонстрация экслпоита
Мы записали видео эксплойта на этом устройстве, которое мы загрузили здесь [14].
9. Выводы
В этом исследовании мы представили состояние безопасности базовой полосы 5G, которой оснащены Android-устройства следующего поколения. Несмотря на то, что с точки зрения функционирования сети произошла эволюция, мы увидели, что с точки зрения безопасности все еще нет прогресса. Как мы показали на самом деле, в некоторых моделях полностью отсутствуют самые основные меры безопасности, такие как cookie стека, что позволяет использовать простые атаки, такие как переполнение буфера, для их компрометации по радиоканалу.
После нашего предыдущего исследования, проведенного 3 года назад, кажется, что особых улучшений не произошло. Мы надеемся, что через 3 года мы сможем снова представить некоторые исследования, но в более жесткой среде.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: Marco Grassi (@marcograss)1, Xingyu Chen (@0xKira233)1
Последнее редактирование:
