Безопасность Open RAN: атаки на RIC и E2

Одно кривое E2AP-сообщение - и E2 Terminator в Near-RT RIC падает. Без аутентификации, без привилегий, с сетевым вектором. CVE-2023-41628 (CVSS 7.5, HIGH - DoS, воздействие только на доступность, C:N/I:N) нашли в O-RAN Software Community E2 G-Release. Затронут компонент, через который идёт весь управляющий трафик между RIC и базовыми станциями. Вектор: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - атакующему не нужны ни учётные данные, ни взаимодействие пользователя. В русскоязычном сегменте до сих пор нет ни одного технического разбора конкретных атак на O-RAN - все ограничиваются архитектурой и рыночными прогнозами. Для SOC-команд операторов, которые тестируют или планируют внедрение Open RAN, этот пробел - проблема.

O-RAN уязвимости: что создаёт новую поверхность атаки​

Традиционный RAN - закрытый вертикально интегрированный стек от одного вендора. Один поставщик, один интерфейс управления, минимум точек входа. O-RAN ломает эту модель, разделяя базовую станцию (gNB) на компоненты от разных производителей: O-RU (Radio Unit), O-DU (Distributed Unit), O-CU (Centralized Unit). Над ними появляются два контроллера радиоинтеллекта - Near-RT RIC и Non-RT RIC - и целое семейство открытых интерфейсов: E2, A1, O1, O2, Open Fronthaul.

С точки зрения атакующего это зоопарк, где каждый зверь - отдельная точка входа:

• Новые сетевые интерфейсы - каждый из них потенциальная дверь внутрь. В терминах MITRE ATT&CK - T1190, Exploit Public-Facing Application, Initial Access.
• Контейнерная инфраструктура - Near-RT RIC и Non-RT RIC крутятся в Kubernetes. Escape из контейнера, кривой RBAC, торчащий наружу API - все знакомые проблемы O-Cloud безопасности теперь сидят в ядре мобильной сети.
• Сторонний код - xApps (приложения для Near-RT RIC) и rApps (для Non-RT RIC) приходят от разных вендоров. Каждое приложение - потенциальный вектор insider threat.
• Open Fronthaul - интерфейс между O-RU и O-DU, раньше закрытый и проприетарный, теперь стандартизирован. Атакующий с физическим доступом к fronthaul-сегменту может перехватывать и модифицировать IQ-данные.

Немецкий регулятор BSI совместно с Secunet провёл анализ рисков O-RAN и сформулировал пять моделей атакующего: от внешнего злоумышленника, эксплуатирующего уязвимости интерфейсов, до «оператора RAN», контролирующего всю инфраструктуру включая подсистемы безопасности. Ключевой вывод отчёта - и он болезненный: меры безопасности в спецификациях O-RAN Alliance до сих пор описаны как опциональные, а не обязательные. Конкретная реализация может не включать ни mTLS на интерфейсах, ни аутентификацию API - и формально оставаться «совместимой» со стандартом. Заявлено «совместимость» - реально открытые ворота. Для операторов это означает: соответствие спецификациям O-RAN не равно защищённости сети радиодоступа 5G.

Безопасность RIC контроллера: атаки через E2 интерфейс и xApp​

RIC - центральный элемент архитектуры O-RAN, через который проходит управление радиоресурсами. Компрометация Near-RT RIC даёт атакующему контроль над работой базовых станций в реальном времени: перераспределение ресурсов, деградация качества обслуживания, перехват управляющего трафика. Исследователи из Trend Micro и Penthertz продемонстрировали несколько практических атак на эталонную реализацию O-RAN SC. Аналогичные угрозы со стороны xApp описаны в 5G-ориентированных threat-моделях - MITRE FiGHT.

CVE-2023-41628: отказ E2Term через out-of-order сообщения​

E2 Terminator (E2Term) - шлюз для всех E2AP-сообщений между Near-RT RIC и E2-узлами (O-DU, O-CU). Нормальный поток: xApp отправляет RIC Subscription Request → E2-узел возвращает RIC Subscription Response. CVE-2023-41628 срабатывает при некорректной инициации процедуры обмена сообщениями между E2Node и E2Term. По данным Trend Micro, предполагаемый триггер - E2Term получает RIC Subscription Response без предшествующего Request, и компонент просто падает. Официальное описание NVD указывает на некорректную инициацию процедуры обмена сообщениями без детализации конкретного типа сообщения.

Тут самое интересное: по публикациям Trend Micro (серия отчётов по безопасности O-RAN SC), спровоцировать эту ситуацию может не только E2-узел, но и скомпрометированный xApp. Любой процесс с доступом к внутренней сети RIC способен отправить одно сообщение и уронить весь E2-уровень. Одно сообщение. В терминах MITRE ATT&CK - T1499 (Endpoint Denial of Service, Impact) / T1499.001 (OS Exhaustion Flood). Начальный доступ зависит от сценария: для внешнего атакующего - T1190 (Exploit Public-Facing Application), для скомпрометированного xApp - доступ уже получен изнутри RIC.

Что мониторить: аномальные последовательности E2AP-сообщений - Subscription Response без предшествующего Request. Рестарты контейнера e2term в Kubernetes-кластере. Каждый такой рестарт - повод для расследования (NIST CSF DE.AE-01: baseline of network operations and expected data flows).

Неавторизованный доступ к management API E2Mgr​

Помимо документированных E2AP-сообщений, E2 Manager (E2Mgr) в O-RAN SC предоставляет HTTP API для управления и отладки. По отчётам Trend Micro, этот API доступен из любого xApp без аутентификации и авторизации. Среди функций API - полная остановка всех E2-сервисов Near-RT RIC. Просто HTTP-запрос - и RIC лёг.

Классика: недокументированные management endpoints без access control. Скомпрометированный или вредоносный xApp вызывает HTTP-запрос на внутренний endpoint E2Mgr и гасит E2-сервисы. Привилегированные учётные данные не нужны - хватает сетевого доступа к порту E2Mgr из контейнера xApp.

Что мониторить: HTTP-запросы к management-портам E2Mgr от контейнеров xApp. Любой вызов shutdown/restart API - алерт уровня critical. В идеале - полная блокировка доступа к management API через network policy в Kubernetes.

ARP Spoofing E2Term: перехват трафика между компонентами​

По серии отчётов Trend Micro по безопасности O-RAN SC (2023–2024, trendmicro.com, раздел research), xApp может выполнить ARP Spoofing (T1557.002, ARP Cache Poisoning, Credential Access / Collection), подменив MAC-адрес E2Term. После этого весь E2-трафик идёт через контролируемый атакующим xApp - включая данные подписок других xApps, к которым у атакующего нет авторизации.

Для V2X-сценариев (Vehicle-to-Everything) это означает перехват и модификацию управляющих решений для транспортных систем. Для обычной сотовой сети - перехват данных о распределении радиоресурсов и UE-метрик.

Что мониторить: изменения в ARP-таблицах на сетевом сегменте RIC. Дублирование MAC-адресов. Аномальный объём трафика через отдельные xApp-контейнеры.

По тем же отчётам Trend Micro, исследователи собрали все обнаруженные атаки в единый «6-in-1 attack xApp» - один вредоносный xApp, способный выполнить шесть различных атак на O-RAN. Один скомпрометированный контейнер - и управляющий уровень RAN под полным контролем. Масштаб проблемы стоит осознать: это не теоретическая модель, а рабочий PoC.

Уязвимости xApp и rApp: скомпрометированный инсайдер внутри RIC​

xApps - функционально независимые программные модули, расширяющие Near-RT RIC. Они приходят от десятков вендоров и решают задачи от оптимизации трафика до V2X-коммуникаций. Мультивендорная природа делает xApp главным вектором атаки в O-RAN.

Пути компрометации:

• Supply chain (T1195.002, Compromise Software Supply Chain, Initial Access): внедрение вредоносного кода на этапе разработки или сборки контейнерного образа. Бэкдор активируется после onboarding xApp в RIC.
• Перехват onboarding: при развёртывании через dms_cli install атакующий подменяет легитимный образ xApp. Без верификации целостности подмена пройдёт незамеченной.
• Легитимный, но кривой xApp: даже без злого умысла - некорректная реализация, отправляющая аномальные E2AP-сообщения, ломает RIC.

В публикациях Penthertz описан сценарий постэксплуатации (конкретный PoC публично не верифицирован): атакующий, получивший доступ к контейнеру xApp, запускает nmap -A для сканирования внутренней сети RIC (T1046, Network Service Discovery, Discovery), находит открытые порты компонентов и загружает агент для закрепления (T1105, Ingress Tool Transfer, Command and Control). Типовой паттерн постэксплуатации в контейнерных средах - ничего нового, но в телеком-контексте последствия другие.

Зачем атакующему компрометировать xApp? Контроль над RIC даёт возможность влиять на распределение радиоресурсов, деградировать качество связи на уровне целого сектора базовой станции и перехватывать управляющий трафик. Для критической инфраструктуры - энергетики, транспорта, экстренных служб - это сценарий с прямым физическим воздействием. Монетизация: вымогательство (угроза отказа сети) или продажа доступа к инфраструктуре оператора на чёрном рынке.

Supply chain атаки на базовые станции​

Мультивендорная модель O-RAN расширяет цепочку поставок телеком оборудования. В традиционном RAN оператор работает с одним-двумя крупными вендорами. В O-RAN количество поставщиков растёт: отдельные вендоры для O-RU, O-DU, O-CU, xApps, rApps и платформы SMO.

Программный supply chain​

Компрометация программной цепочки (T1195.002) - наиболее вероятный вектор при виртуализации RAN. Цели: репозитории контейнерных образов для RIC-компонентов, зависимости xApp/rApp (Python-пакеты, Go-модули) и компоненты O-RAN SC с открытым исходным кодом. Форк на GitHub с инъекцией кода выглядит как легитимный upstream - попробуй отличи.

Контрмеры: сканирование образов перед деплоем, подпись образов (cosign/Notary), SBOM для каждого xApp. Верификация целостности - часть CI/CD-пайплайна, а не опциональный шаг, который «потом прикрутим».

Аппаратный supply chain​

Компрометация аппаратного supply chain (T1195.003, Compromise Hardware Supply Chain, Initial Access) бьёт прежде всего по O-RU - радиомодулям, которые в O-RAN поставляются от менее крупных и менее проверенных производителей. Распаковка прошивок O-RU через binwalk позволяет извлечь файловую систему, после чего с помощью firmwalker, strings и ручного анализа извлечённых бинарников ищутся встроенные бэкдоры, отладочные интерфейсы и hardcoded credentials. Статический анализ C/C++ кода gNB-компонентов через semgrep с правилами для CWE-119 (Buffer Overflow) и CWE-787 (Out-of-bounds Write) помогает поймать уязвимости до деплоя. Для более глубокого аудита - Coverity, особенно для компонентов обработки протоколов на уровне PHY и MAC.

Актуальный реестр аппаратного обеспечения (NIST CSF ID.AM-01, Asset Management) и физическая маркировка авторизованного оборудования (PR.AA-01) - базовые меры, но в мультивендорной среде O-RAN они приобретают критическое значение для защиты open fronthaul интерфейса и других точек подключения.

Detection и hardening для защиты сети радиодоступа 5G​

BSI в своём отчёте отдельно указал на необходимость отказа от устаревших протоколов (SSH2 в пользу TLS) и перехода на memory-safe языки (Rust) для новых компонентов. Это перекликается с реальным опытом: статический анализ C/C++ кода gNB-компонентов через Coverity регулярно выявляет классические buffer overflow, которых не было бы на Rust. Для существующих развёртываний - DPI-система, способная инспектировать протоколы O-RAN и применять горячие патчи на уровне трафика, компенсирует часть рисков без переписывания кода (RS.AN-01, RC.CO-01).

Три года работы с тестовыми стендами на базе srsRAN и OpenAirInterface убедили меня в одном: O-RAN безопаснее традиционного RAN ровно в той степени, в какой оператор готов вкладываться в detection и hardening открытых интерфейсов. Спецификации O-RAN Alliance (включая WG11 по безопасности) описывают нужные механизмы - mTLS, OAuth 2.0, xApp sandboxing. Но «описаны» и «внедрены» - два разных состояния. CVE-2023-41628 показывает обе стороны проблемы: архитектура O-RAN расширяет поверхность атаки, а конкретная реализация O-RAN SC не обработала базовый edge case в message flow. Таких edge cases в production будет больше.

Каждый новый xApp от стороннего вендора - потенциальный вектор, который SOC-команда оператора должна покрыть мониторингом до включения в боевую сеть, а не после первого инцидента. Операторы, которые внедряют O-RAN без параллельного развёртывания detection-стека под E2/A1/O1 трафик, повторяют ошибку раннего облачного adoption - когда компании мигрировали в AWS без CSPM и потом удивлялись утечкам через открытые S3-бакеты. Разница: здесь на кону не данные в бакете, а доступность мобильной связи для миллионов абонентов.

Регуляторы - BSI уже показал направление - будут спрашивать не «почему вы используете O-RAN», а «почему ваш RIC был скомпрометирован через xApp, о рисках которого предупреждали три года назад». Если у вашей команды другой стек детекции - адаптацию подобных правил под конкретные SIEM обсуждают на форуме codeby.net.