Исследование безопасности модема Cinterion EHS5 3G UMTS/HSPA

Модем является неотъемлемой частью различных программно-аппаратных решений, которые должны оставаться на связи. Среди них как бытовые приборы и классические мобильные устройства, которыми мы привыкли пользоваться каждый день, так и телекоммуникационные блоки автомобилей, банкоматы, компоненты АСУ ТП.

При разработке конечных устройств производители зачастую не уделяют должного внимания их защите от компрометации модема. А захватив модем, злоумышленник может не только контролировать информационный поток между устройством и внешним миром, но и получить практически неограниченный доступ к наиболее важным компонентам конечного устройства. Например, при компрометации модема, используемого в электронном блоке автомобиля (ЭБУ), злоумышленник может получить удаленный доступ к тормозной системе. Получив контроль над модемом, используемом в медицинском оборудовании, — создать реальную угрозу человеческой жизни. А управляя модемом, используемым в АСУ ТП химического производства, — вызвать техногенную катастрофу.

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

В связи с этим нас заинтересовали модемы производства компании Telit Cinterion. Мы решили провести аудит безопасности такого модема в рамках масштабного проекта по анализу защищённости популярной модели грузовика. Единственной известной зарегистрированной уязвимостью на момент начала исследования была уязвимость CVE-2020-15858, более подробное описание которой можно найти в сети Интернет.

Объектом исследования был выбран модем серии Cinterion EHS5-E. Данное семейство модемов изначально производилось компанией Thales, но в 2022 году это бизнес-подразделение было выкуплено компанией Telit. Некоторые другие семейства модемов этого производителя имеют схожее программное обеспечение и аппаратную архитектуру, поэтому результаты проведенного исследования относятся к устройствам нескольких модельных рядов:

• Cinterion BGS5
• Cinterion EHS5/6/7
• Cinterion PDS5/6/8
• Cinterion ELS61/81
• Cinterion PLS62.

Программные компоненты модема

Согласно программной модели, модем состоит из четырех программных компонентов:

• Firmware (FW)
• Application (App)
• Java Remote Control (JRC)
• Service LWM2M Agent (SLAE).

Модем поставляется разработчику устройства вместе с SDK для разработки программных компонентов, выполняющих бизнес-логику, — мидлетов. Компоненты FW и App являются частью низкоуровневого кода модема. Они содержат в себе операционную систему модема и среду исполнения пользовательских мидлетов. Мидлет представляет собой программу на языке Java. Поддерживается специальная подсистема Java ME (Micro Edition). Эта подсистема характеризуется ограниченным набором поддерживаемых команд Java. Компоненты JRC и SLAE являются специальными мидлетами, разработанными производителем.

Пользователю предоставляется возможность самостоятельной установки мидлетов и настройки безопасности их исполнения. В качестве механизмов безопасности мидлетов используются:

• проверка байт-кода Java на этапе установки (всегда включено);
• цифровая подпись мидлета (настраивается разработчиком конечного устройства).

По умолчанию в модеме установлен только сертификат производителя для проверки мидлетов с привилегиями исполнения уровня производителя (manufacturer). Установка и настройка сертификатов для пользовательских мидлетов лежит на разработчике конечного устройства. Подробнее об этом описано в EHSx Java User’s Guide.

Виды мидлетов

Исходя из нашего анализа, все мидлеты на модеме по уровню привилегий можно разделить на две категории:

• мидлеты производителя (manufacturer)
• пользовательские мидлеты (подписанные и неподписанные).

К мидлетам производителя относятся только мидлеты JRC и SLAE. Этот уровень привилегий является максимальным и не накладывает никаких ограничений на исполняемый код на уровне Java.

Второй категорией привилегий наделяются пользовательские мидлеты. На мидлеты этой категории накладываются ограничения, касающиеся их функциональных возможностей. То есть ограничивается взаимодействие с внешними программными и аппаратными компонентами: работа с файловой системой (ФС), работа с GSM-модулем и т. п. Например, пользовательский мидлет не может читать всю ФС модема, а модуль JRC может.

Однако если установлен пользовательский сертификат, то на модеме будут выполняться только подписанные пользовательские мидлеты с привилегиями User Signed. По сути пользовательская подпись мидлетов используется только для того, чтобы защитить модем от выполнения мидлета нелегитимного пользователя — злоумышленника или исследователя безопасности.

Установка мидлетов на модем

Установка мидлетов возможна как локально, так и удаленно. Локальная установка мидлетов реализована через компонент JRC. Удаленная установка возможна через специальный механизм OTAP или, в случае M2M-использования, через компонент SLAE.

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

Локальная установка мидлетов

Локальная установка производится через протокол обмена данными MES и специальные AT-команды. Сам интерфейс и обработка AT-команд реализованы в компоненте JRC. Протокол MES обеспечивает взаимодействие с пользовательской ФС (далее — ПФС) модема, в том числе запись на ПФС или удаление из нее файлов.

Если установить драйвер из поставки SDK, то можно увидеть содержимое ПФС объекта исследования (ОИ), которое смонтировано по пути «///a:/». Сам драйвер является пользовательской надстройкой над протоколом MES. При этом несмотря на то что формально MES предполагает работу с любым значением пути, кроме пути «///a:/» ни о каких других внутренних путях неизвестно, а попытка прочитать что-либо с другим корнем приводит к ошибке. Как мы выяснили в процессе исследования, это поведение обеспечивается фильтрацией параметров запроса в MES: все, что не относится к корню «а://», возвращает ошибку, хотя на самом деле валидных корней у ПФС несколько.

Локальная установка мидлета производится в два этапа. Вначале пользователю необходимо скопировать на ПФС модема файлы мидлета (.jar и .jad). Далее мидлет должен быть установлен на модем с помощью АТ-команды AT^SJAM=0. В результате выполнения этой команды файлы мидлета копируются в недоступную пользователю часть ФС модема, а затем удаляются из ПФС. Путь, по которому копируются мидлеты во время их установки, неизвестен, и этот факт является критическим для обеспечения конфиденциальности пользовательских мидлетов и мидлетов самого производителя. Запуск установленного мидлета производится из «секретного» места в ФС модема, в которое он был скопирован. Список всех установленных мидлетов можно также получить с помощью команды AT^SJAM. На рисунке 1 представлен пример вывода этой команды на модеме, получаемого разработчиком.

В документации на модем (см. рисунок 2) указано, что используемый для работы с ФС коннектор javax.microedition.io.file.FileConnection должен отфильтровывать запросы к файлам с расширением .jar.

Такое поведение подтверждается простым тестом: при попытке получения доступа к файлам с расширением .jar возвращается ошибка операции (см. рисунок 3).

При этом файлы с расширением .jad копируются, как и любые другие.

Установка мидлетов через OTAP

В протоколе OTAP данные передаются с помощью SMS-сообщений, имеющих специальные значения полей Class и PID (см. рисунок 4).

Сами OTAP-сообщения представляют собой ASCII-текст, который передается в теле SMS-сообщения. Пример такого сообщения приведен на рисунке 5.

Поддержку OTAP обеспечивают компоненты App и JRC. Процесс установки и обновления пользовательских мидлетов через OTAP подразумевает его предварительную активацию пользователем на стороне модема. При этом пользователь должен указать дополнительные атрибуты, которые будут использоваться для OTAP: JAD File URL, HTTP User, HTTP Password и т. д.

Если OTAP не был ранее активирован с помощью АТ-команды AT^SJOTAP, то полученное сообщение обрабатываться не будет (см. рисунок 6). Активация заключается в создании специального файла настроек OTAP_AtParams.bin на ПФС.

Фрагмент содержимого этого файла, созданного в результате наших тестов, представлен на рисунке 7.

Отладка исполнения мидлетов и модема

Согласно официальной документации на модем, для взаимодействия с ним доступно несколько интерфейсов, представленных на рисунке 8.

Среди них можно выделить интерфейсы, через которые доступно получение отладочной информации: ASC0, ASC1 и USB. В случае ASC0 или ASC1 по ним передается информация между модемом и отладочным хостом по протоколу UART. В случае USB происходит эмуляция UART-интерфейса.

В модеме предусмотрено несколько механизмов получения отладочной информации:

• через среду разработчика (IDE);
• через UART-интерфейс (логический или физический).

Среда разработчика позволяет производить полную отладку исполняемого мидлета на стороне модема. Для этого используется подсистема отладки Java-мидлетов, включающая их загрузку на модем, пошаговое выполнение и удаление. Взаимодействие с модемом в режиме отладки через среду разработчика происходит через специальное PPP-соединение, устанавливаемое через USB. Более подробно механизм отладки описан в EHSx Java User’s Guide.

Кроме отладки мидлетов, модем позволяет собирать логи работы своих подсистем, в том числе мидлетов. Что именно выводится пользователю, определяется командой AT+TRACE. Пример команды включения вывода отладочной информации на модеме представлен ниже.

at+trace=,115200,"st=0,pr=1,bt=0,ap=1,db=1,lt=0,li=0"

Параметры команды позволяют настроить, из каких именно подсистем модема следует собирать информацию. Информацию о том, из каких подсистем доступен сбор отладочной информации, можно узнать из подробного вывода справочных сведений на эту АТ-команду (см. рисунок 9).

Получение прошивки модема

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

Далее мы проанализировали аппаратную составляющую модема (см. рисунок 11). Было идентифицировано его ПЗУ, реализованное на базе NAND-памяти. На данном ПЗУ должны были храниться программные компоненты модема. Образ вышеуказанной NAND-памяти мы получали с помощью программатора ChipProg.

Мы столкнулись с определенными трудностями при извлечении информации из NAND-памяти из-за особенностей устройства хранения и алгоритмов равномерного распределения нагрузки на секторы при записи (Wear leveling). Подробное описание процесса восстановления образа NAND представлено в полной версии статьи.

В результате восстановления образа NAND нам удалось извлечь ПФС и получить из нее бинарные образы компонентов FW и APP (см. рисунок 12).

Анализ содержимого ПФС

Просмотрев полученное содержимое ПФС, мы установили, что в пространстве ПФС присутствуют скрытые от пользователя папки и файлы, недоступные через механизм MES: .cinterion.internal и .cinterion.service. Причем фильтрация доступа к ним осуществлялась напрямую в коде мидлета JRC по префиксу их имени. Пример кода из модуля JRC, который осуществляет фильтрацию доступа к этим папкам, представлен на рисунке 13.

Было установлено, что все мидлеты (как пользовательские, так и мидлеты производителя), хранятся на устройстве по пути /sys/.cinterion.internal/java. Каждый мидлет представлен на ФС в виде четырех файлов с расширениями: .ss, .ii, .ap и .jar.

После анализа содержимого папки с установленными мидлетами было обнаружено, что каждый мидлет в процессе установки переименовывается. Для того чтобы обеспечить пользователю возможность запускать мидлеты по их имени, в файле _suites.dat хранится соответствие между начальным названием мидлета и его псевдонимом (alias). Например, по бинарному содержимому этого файла легко идентифицируется, что файл 00000003.jar является файлом JRC.jar (см. рисунок 14).

Файл с расширением .ap является преобразованным в Unicode файлом .jad. Этот файл содержит информацию об оригинальном имени мидлета, используемых библиотеках, а также может содержать цифровую подпись. Пример содержимого такого файла для мидлета JRC представлен на рисунке 15.

Файл с расширением .ii содержит информацию о пути установки мидлета, разрешения, с которыми он был установлен, и другую служебную информацию (см. рисунок 16).

Наконец, файл с расширением .ss содержит описание разрешений уровня Java, доступных для этого мидлета. Пример описания разрешений мидлета JRC представлен на рисунке 17.

Важно отметить, что данный набор разрешений дает неограниченный доступ к членам системных классов виртуальной машины. Это и есть тот самый уровень привилегий manufacturer. Такими разрешениями обладают только два мидлета: JRC и SLAE. Любые пользовательские мидлеты обязаны перечислить в своем манифесте те классы и методы, к которым им требуется доступ в процессе работы. Фрагмент такого манифеста для разработанного нами тестового мидлета представлен на рисунке 18.

Изменение уровня привилегий пользовательского мидлета

Как было указано ранее, каждый установленный мидлет хранится в ФС модема по пути /sys/.cinterion.internal/java в виде четырех файлов. Во время запуска мидлета происходит проверка его уровня привилегий по данным из файла с расширением .ii. Затем, в зависимости от указанного уровня привилегий, назначаются права доступа из файла с расширением .ss. При этом отсутствует проверка наличия цифровой подписи у запускаемого мидлета, имеющего уровень привилегий manufacturer.

Поскольку любой пользовательский мидлет может использовать класс javax.microedition.io.file.FileConnection и в этом классе отсутствует запрет на доступ к файлам с расширениями .ii и .ss, разрешения и уровень безопасности мидлета могут быть повышены. Для этого установленный мидлет может заменить свои файлы .ii и .ss, чтобы этот мидлет начал исполняться с уровнем привилегий manufacturer (см. рисунки 19 и 20).

Анализ протокола ULP

В процессе исследования было обнаружено, что модем поддерживает возможность геопозиционирования с помощью подсистемы SUPL. Эта подсистема предусматривает обмен специальными сообщениями между H-SLP (Home SUPL Location Platform) и SET (SUPL Enabled Terminal). Модем в соответствии со спецификацией является объектом SET. Пример взаимодействия представлен на рисунке 21.

Обмен сообщениями производится с помощью бинарного протокола ULP. Данные по этому протоколу в сети GSM передаются через PUSH-сообщения с помощью протоколов стека WAP. Типичное ULP-сообщение на примере сообщения SUPL INIT представлено на рисунке 22.

На уровне PUSH-сообщений WSP в проколе ULP заложена возможность фрагментации передаваемого сообщения. Это сделано для того, чтобы можно было передавать большие бинарные сообщения через ограниченный канал передачи SMS-сообщений. На стороне SET WSP-протокол предусматривает индексацию для фрагментированной передачи SMS-сообщений. При этом SULP-сообщение в самом начале содержит размер передаваемого сообщения.

Пример первого SMS-сообщения представлен на рисунке 23. Пример последующих SMS-сообщений представлен на рисунке 24.

В ходе анализа работы драйвера, отвечающего за обработку фрагментации ULP-сообщений, мы обнаружили уязвимость переполнения кучи. В соответствии с протоколом передачи переменные ULPSizeFromPacket (размер всего ULP-пакета) и wapTpduLen (размер принятого WAP-сообщения) вычисляются независимо. Соответственно, принятый WAP-пакет размера wapTpduLen будет копироваться в буфер размера ULPSizeFromPacket (см. рисунок 25). Это классический пример переполнения буфера в куче.

Сформировав нужное SMS-сообщение, нам удалось вызвать ошибку переполнения кучи на стороне модема, которая привела к его полной перезагрузке. Чтобы выяснить причину перезагрузки, мы воспользовались АТ-командой для считывания ошибок AT+XLOG. Результат работы данной команды приведен на рисунке 26.

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

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

После преодоления большого количества технических сложностей, подробно описанных в полной версии статьи, всего несколькими специально сформированными SMS-сообщениями мы смогли запустить на стороне ОС модема разработанный нами драйвер, позволяющий:

• выделять память (malloc);
• освобождать память (free);
• создавать / открывать файлы в ПФС (createFile).

При помощи данного драйвера нам удалось создать нужные для активации OTAP файлы в ФС, установить на модем свой мидлет и присвоить ему максимальные привилегии уровня manufacturer (см. рисунок 27).

Заключение

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

В ходе исследования безопасности модема производителя Telit нами были обнаружены семь уязвимостей, для эксплуатации которых необходим локальный доступ, и одна — которую можно проэксплуатировать удаленно. Подробное описание данных уязвимостей представлено в полной версии статьи (PDF, 9 МБ). Совокупность найденных уязвимостей может позволить злоумышленнику полностью скомпрометировать модем. В ходе анализа защищённости исследуемого грузовика благодаря обнаруженным уязвимостям мы смогли получить удалённый контроль над модемом, а уже оттуда — контроль над основными системами автомобиля, такими как двигатель, коробка передач, тормозная система и др.

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

Поэтому чтобы уменьшить вероятность эксплуатации обнаруженных уязвимостей «Лаборатория Касперского» рекомендует:

• Ограничить на стороне сотового оператора передачу SMS-сообщений на устройство.
• Использовать частный APN со строгими настройками безопасности для ограничения последствий эксплуатации уязвимости.
• Включить проверку подписи для приложений для запрета установки недоверенных мидлетов.
• Контролировать физический доступ к устройству на всех этапах его поставки для защиты от встраивания программных закладок.
• При проектирования нового устройства, использующего модем, необходимо оценивать риск компрометации модема как высокий и выстраивать систему так, чтобы доступ модема к другим компонентам системы был ограничен.

Что касается производителей модемов и аналогичных устройств, то для снижения потенциальных рисков на этапе проектирования «Лаборатория Касперского» рекомендует:

• Внедрить дополнительные ограничения доступа к памяти в операционной системе ThreadX, используя доступные механизмы MCU или компонент Modules.
• Использовать инструменты статического анализа кода, чтобы определить ошибки при работе с указателями.
• Внедрить в процесс разработки фаззинг-тестирование для автоматизированного обнаружения ошибок, связанных с обработкой данных.
• Внедрить в процесс разработки периодический аудит кода на предмет запутанной логики и наличия логических ошибок.
• При выборе методологии разработки отдавать приоритет методологиям, использующим подход Secure by Design (подобный подход, например, реализован в KasperskyOS), а также платформам, позволяющим строить решения с разделением доменов безопасности.