https://forum.antichat.xyz/attachmen...f63a2b9eda.png

Современный автомобиль - это пять-семь одновременно работающих радиоинтерфейсов. Keyless entry на 125 кГц и 433 МГц, Bluetooth на 2.4 ГГц, Wi-Fi на 2.4/5 ГГц, LTE/5G-модем, приёмник GPS на 1.575 ГГц, датчики давления в шинах (TPMS) на 315/433 МГц и - у свежих моделей - модуль V2X на 5.9 ГГц. Каждый из этих каналов - точка входа для атакующего. При этом русскоязычные разборы обычно покрывают что-то одно: либо угон через relay, либо конкретную CVE в Bluetooth-стеке. А реальная цепочка атаки на автомобиль почти всегда мультиинтерфейсная - вход через один протокол, pivot через второй, выход на CAN-шину через третий.

Здесь я разберу каждый беспроводной вектор с привязкой к конкретным CVE, инструментарию и техникам MITRE ATT&CK. Фокус - на практике: что происходит в радиоэфире, какое железо нужно, как выглядит эксплуатация и чем закрывать каждый вектор.
Карта беспроводной поверхности атаки автомобиля
Прежде чем копать каждый интерфейс по отдельности, полезно увидеть картину целиком. Таблица ниже связывает беспроводные интерфейсы автомобиля с релевантными техниками MITRE ATT&CK и типичным инструментарием атакующего.

ИнтерфейсЧастотаТехника ATT&CKИнструментPKES / RKE125 кГц / 433 МГцAdversary-in-the-Middle (T1557)¹HackRF One, Yard Stick One, Proxmark3Bluetooth2.4 ГГцExfiltration Over Bluetooth (T1011.001)btlejack, Ubertooth One, ScapyWi-Fi2.4 / 5 ГГцEvil Twin (T1557.004), Wi-Fi Networks (T1669)hostapd, aircrack-ngCellular700–2600 МГцNetwork Sniffing (T1040)srsRAN, IMSI catcherV2X (DSRC/C-V2X)5.9 ГГцNetwork Sniffing (T1040)GNU Radio, USRPTPMS315 / 433 МГц- (маппинг приблизительный)¹RTL-SDR, Yard Stick OneGPS1.575 ГГц-HackRF One (spoofing)

¹ MITRE ATT&CK Enterprise неполностью покрывает RF-атаки на автомобили; маппинг приблизительный. Для более точной классификации см. Auto-ISAC threat matrix.

Каждый интерфейс - отдельная история со своими протоколами, дырами и контрмерами. Пойдём по порядку: от самого массового вектора (keyless entry) к самому перспективному (V2X).
Relay-атаки на keyless entry: оборудование за $50 и дальность 100 метров
Система бесключевого доступа (Passive Keyless Entry and Start, PKES) работает просто: автомобиль постоянно шлёт LF-запрос на частоте 125 кГц в радиусе 1–2 метров. Если брелок оказывается в зоне действия, он отвечает UHF-сигналом на 433 МГц (Европа) или 315 МГц (Северная Америка). Автомобиль верифицирует ответ и разблокирует двери.

Проблема в том, что протокол не проверяет расстояние до ключа - только валидность криптографического ответа. Relay-атака бьёт именно сюда. Два злоумышленника с парой приёмопередатчиков: один стоит рядом с автомобилем и ретранслирует LF-запрос на UHF-частоте, второй - рядом с владельцем (в кафе, у входа в дом) и передаёт запрос ключу на 125 кГц. Ключ отвечает, ответ летит обратно к машине. Всё - меньше секунды.

На практике я собирал relay-стенд из двух модулей: Proxmark3 на стороне ключа для работы с LF-сигналом на 125 кГц, и Yard Stick One на стороне автомобиля для UHF-ретрансляции на 433/315 МГц. Стоимость комплекта - $50–150 за б/у оборудование. Рабочая дальность ретрансляции - до 100 метров на открытом пространстве, чего за глаза хватает для большинства сценариев угона на парковке. Proxmark3 заодно позволяет анализировать и воспроизводить низкочастотные сигналы с высокой точностью - штука универсальная.

Помимо relay, есть атака RollJam, которую Сэми Камкар показал на DEF CON 23 (упомянута и в исследовании PMC NIH). RollJam обходит скользящий код (rolling code) в системах Remote Keyless Entry: устройство глушит и одновременно записывает первый сигнал от брелока, затем записывает второй, а первый проигрывает для легитимного открытия. В итоге у атакующего остаётся неиспользованный валидный код. Красиво и подло.

https://forum.antichat.xyz/attachmen...7201571899.png

Почему UWB решает проблему лишь частично
Производители внедряют Ultra-Wideband (UWB) для измерения time-of-flight между ключом и автомобилем - ретрансляция добавляет задержку, которую UWB детектирует. Но UWB-реализации различаются между вендорами, а Bluetooth LE-фаза установления соединения (как в протоколе CCC Digital Key) всё ещё может быть атакована до перехода на UWB-канал. Это не панацея, а слой defence-in-depth.
Уязвимости Bluetooth автомобиля: цепочка PerfektBlue в 350 млн машин
Bluetooth в автомобиле - это не только hands-free и стриминг музыки. Это полноценный стек протоколов, работающий на head unit с операционной системой (чаще Linux или Android). Один из самых распространённых Bluetooth-стеков в автомобильной индустрии - OpenSynergy BlueSDK, который, по данным разработчиков, стоит в 350 млн автомобилей. Ford, Mercedes-Benz, Volkswagen, Skoda - все тут.

Каждая уязвимость работает как звено в цепи эксплуатации:

CVEОписаниеCVSSCWECVE-2024-45431Отсутствие валидации remote L2CAP channel ID (CID) - атакующий создаёт канал с null-идентификатором. Самостоятельный impact низкий (C:L/I:N/A:N), используется как primitive для цепочки с CVE-2024-454345.3 (MEDIUM)CWE-20 (Improper Input Validation)CVE-2024-45433Некорректная обработка потока управления после обнаружения аномалии - входящие данные проходят без проверки безопасности6.5 (MEDIUM)CWE-705 (Incorrect Control Flow Scoping)CVE-2024-45432Использование некорректной переменной как аргумента функции - утечка чувствительных данных7.5 (HIGH)CWE-284 (Improper Access Control - broad category; технически ближе к CWE-628, Incorrect Function Argument)CVE-2024-45434Use-After-Free - удалённое выполнение кода в контексте процесса Bluetooth9.8 (CRITICAL)CWE-416 (Use After Free)

Посмотрите на вектор CVE-2024-45434:
- сетевой доступ, низкая сложность, никаких привилегий, никакого взаимодействия пользователя. Максимально злая комбинация. Атакующий шлёт вредоносные команды через протокол управления аудиоплеером (AVRCP) и получает выполнение кода с привилегиями Bluetooth-процесса. Формально PR:N - привилегии не нужны; на практике PCA Cyber Security указывают, что pairing обычно необходим, но в некоторых конфигурациях head unit принимает соединения без предварительного сопряжения. То есть кто-то на парковке может зайти в вашу магнитолу без «разрешите представиться».
Что доступно после эксплуатации
Исследователи продемонстрировали эксплуатацию на Volkswagen ID.4 (MEB ICAS3), Mercedes-Benz с NTG6 и Skoda Superb с MIB3. После получения RCE на head unit атакующий может: отслеживать GPS-координаты, записывать аудио через встроенные микрофоны, вытягивать контакты из синхронизированной телефонной книги. В зависимости от архитектуры конкретной модели, через CAN-шину, подключённую к infotainment, возможен доступ к управляющим ECU - вплоть до тормозной системы.

При тестировании Bluetooth-стеков автомобильных head unit я использую связку btlejack для перехвата BLE-соединений и Scapy для конструирования кастомных L2CAP-пакетов. Начальная разведка:

Bash:


Главная рекомендация: обновить прошивку head unit до версии с патчем OpenSynergy (выпущен в сентябре 2024), а если нет возможности - вырубить Bluetooth. Заодно убедитесь, что head unit не принимает сопряжения без подтверждения водителя.
Атаки на автомобильный Wi-Fi: Evil Twin на парковке
Многие современные автомобили раздают Wi-Fi-хотспот для пассажиров или подключаются к домашней/корпоративной сети для загрузки OTA-обновлений. Этот интерфейс - вектор для классической атаки Evil Twin (T1557.004).

Сценарий: атакующий разворачивает точку доступа с SSID, идентичным ранее запомненной сети автомобиля (например, домашней Wi-Fi владельца). Infotainment-система автоматически цепляется к знакомому SSID. Дальше весь трафик head unit идёт через контролируемую точку - атакующий перехватывает DNS-запросы, HTTP-трафик, и при наличии дыр в ПО head unit может доставить payload.

Используя
для создания Evil Twin и
для MITM, я не раз видел, как тестовые head unit на базе Android автоматически подключались к поддельной точке без какого-либо уведомления водителю. Ни звука, ни иконки - тишина. Корневая проблема - Wi-Fi-клиент в автомобиле не проверяет сертификат точки доступа и не предупреждает о смене MAC/BSSID.

Техника Wi-Fi Discovery (T1016.002) позволяет пассивно перечислить сохранённые SSID автомобиля через probe request frames - head unit регулярно «ищет» знакомые сети, транслируя их имена в открытом виде. Сбор этой информации предшествует активной фазе атаки и занимает минуты с Wi-Fi-адаптером в режиме мониторинга.

После компрометации Wi-Fi-интерфейса дальнейшее продвижение зависит от архитектуры SoC. Если Wi-Fi и CAN-gateway сидят на одном процессоре приложений (что характерно для бюджетных платформ), латеральное движение к CAN-шине требует только повышения привилегий внутри одной ОС. Один SoC - один хоп до CAN.
Эксплуатация cellular-модуля: IMSI Catching и RCE через модем
Cellular-интерфейс - самый «дальнобойный» вектор атаки на беспроводные системы авто: он работает постоянно, его нельзя отключить без ковыряния прошивки, и он связан с backend-серверами производителя.
IMSI Catching: слежка за автомобилем через поддельную базовую станцию
Исследователи Northeastern University продемонстрировали атаку IMSI Catching на Tesla Model 3 и Cybertruck (модели 2024 года). IMSI (International Mobile Subscriber Identity) - уникальный идентификатор, по которому модем автомобиля аутентифицируется в сотовой сети. При первом подключении или реаттаче к сети модем может передать IMSI в открытом виде.

Атакующий разворачивает поддельную базовую станцию (fake eNB) через srsRAN или OpenBTS. Автомобильный модем подключается к ней, раскрывая IMSI. Дальше: отслеживание местоположения автомобиля, перехват телеметрии, принудительный downgrade до 2G, а также DoS - блокирование связи с серверами производителя. По данным исследования Northeastern, проблема не специфична для Tesla: модемы на базе Qualcomm и Quectel, которые стоят в большинстве подключённых автомобилей, подвержены тем же атакам.
RCE на модеме Unisoc: от радиоэфира до ядра Android
Исследование Kaspersky (2025) детально описывает взлом головного устройства автомобиля через модем Unisoc UIS7862A со встроенным 2G/3G/4G-радио. Этот чип используется в головных устройствах китайских автомобилей и ряде мобильных устройств.

CVSS 8.3 (HIGH), CWE-787. Вектор:
- атака из смежной сети (Adjacent), высокая сложность, но без привилегий и взаимодействия пользователя. Scope Changed означает, что компрометация модема позволяет добраться до других компонентов SoC.

• CVE-2024-39432 - out-of-bounds read в том же драйвере, CVSS 8.3. NVD присвоил CWE-787 (Out-of-bounds Write), хотя по описанию это out-of-bounds read (CWE-125). Расхождение - но NVD не переспоришь.

Обе уязвимости сидят в обработчике SDU-пакетов протокола RLC - уровень 2 модели OSI, ниже шифрования NAS. По данным Kaspersky, эксплуатация может происходить до установления защищённого канала связи: стандартные механизмы защиты 3G/LTE потенциально не спасают. При этом NVD в текстовом описании указывает, что необходимы привилегии System execution, а CVSS-вектор содержит PR:N - расхождение между текстом advisory и метрикой; на практике эксплуатация из радиоэфира требует дополнительных условий.

Технически: парсер SDU-заголовков последовательно обрабатывает необязательные заголовки (по 2 байта каждый), пока E-bit равен 1, записывая их на стек глубиной 0xB4 байт. Стековая канарейка отсутствует. Отправляем пакет с более чем 90 заголовками - стек переполняется, адрес возврата перезаписан. Согласно NVD, обе CVE официально классифицированы как приводящие к удалённому DoS с необходимостью привилегий System. Но исследователи Kaspersky в расширенном сценарии построили ROP-цепочку (Return Oriented Programming) в прошивке модема и продемонстрировали выполнение произвольного кода на Communication Processor - это выходит за рамки официального advisory. Заявлен DoS, но реально — RCE.

Дальше - самое интересное: горизонтальное перемещение с модемного процессора на Application Processor через скрытое DMA-устройство (Direct Memory Access). Это аппаратная уязвимость архитектуры SoC, позволяющая обойти изоляцию между CP и AP. Результат - патч ядра Android на лету и выполнение кода с наивысшими привилегиями. Firmware Corruption (T1495) в чистом виде.
Уязвимости DSRC и C-V2X: атаки на V2X-коммуникации
V2X (Vehicle-to-Everything) - технология обмена данными между автомобилями и инфраструктурой на частоте 5.9 ГГц. Два поколения: DSRC (на базе 802.11p) и C-V2X (Cellular V2X, на базе LTE/5G). Основной тип сообщений - BSM (Basic Safety Message), содержащий скорость, координаты, направление движения, статус тормозной системы и идентификатор автомобиля.

Согласно исследованию VicOne (на основе работы Raashid, Petit, Monteuuis и Chen), три основных сценария атак на V2X:

Ghost Node - атакующий создаёт фантомный автомобиль в V2X-сети через SDR. Фантом имитирует правдоподобные паттерны движения. Для первого поколения DSRC атака наиболее реалистична: DSRC на базе IEEE 802.11p в первоначальной реализации не имеет обязательной аутентификации сообщений на уровне MAC; PKI-подпись (IEEE 1609.2) применяется на уровне приложения и не всегда строго проверяется. C-V2X требует подписи сообщений перед отправкой, хотя LTE-V2X использует слабые криптографические ключи. 5G-V2X использует ECDSA (P-256/brainpoolP256r1) согласно IEEE 1609.2 / ETSI TS 103 097 - подделать существенно сложнее.

Self-telemetry manipulation - скомпрометированный автомобиль фальсифицирует собственные телеметрические данные (скорость, координаты, статус торможения). Приложения V2X на соседних машинах принимают ложные данные - например, система электронного экстренного торможения (EEBL) может спровоцировать резкое торможение у следующего сзади транспорта на основе поддельного BSM. Представьте: фантомная машина перед вами «давит на тормоз» - и ваш ADAS реагирует.

Channel DoS - глушение каналов V2X. Более вероятно для DSRC и LTE-V2X: C-V2X использует SC-FDMA/OFDM с координированным распределением ресурсов через PC5-интерфейс, что усложняет селективное глушение, но узкополосные помехи всё ещё могут нарушить связь.

Вывод: перехват сигнала автомобиля в V2X-сети реален уже сейчас. Даже в 5G-V2X в перспективе остаётся уязвимость к квантовым атакам. Для текущей генерации транспорта критически важно не полагаться только на V2X-данные при принятии решений системой ADAS - водительский контроль остаётся необходимым.

https://forum.antichat.xyz/attachmen...7201603620.png

Практика: от радиоэфира до CAN-шины за три шага
Этот раздел описывает полную цепочку атаки на безопасность беспроводных систем авто, объединяющую несколько интерфейсов. Подход типичен для пентеста автомобильных систем.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше


Получить доступ просто — достаточно проявить активность на форуме

Матрица митигаций по автомобильным беспроводным протоколам

ИнтерфейсОсновная атакаМитигацияСтатус внедренияPKESRelay attackUWB time-of-flightЧастично (Apple CarKey, BMW)RKERollJam / replayAES-128 rolling code + таймаутДа, в новых моделяхBluetoothPerfektBlue (CVE-2024-45434)Обновление BlueSDK, отключение auto-pairingПатч OpenSynergy доступен с сентября 2024Wi-FiEvil TwinПроверка сертификата AP, отключение auto-connectНет в большинстве head unitsCellularIMSI CatchingПереход на 5G (SUPI encryption), отключение 2G/3G fallbackЧастично (зависит от оператора)CellularModem RCE (CVE-2024-39431)Обновление прошивки модема, MPU-изоляция CP/APЗависит от OEMV2X (DSRC)Ghost Node, BSM spoofingМиграция на C-V2X с PKI-подписьюВ процессеV2X (C-V2X 5G)Квантовые атаки (перспектива)Post-quantum cryptographyИсследованияTPMSSpoofing давленияАутентификация сенсоров (Bluetooth LE с PAwR)В разработке

Главная структурная боль автомобильной кибербезопасности - длинный цикл от обнаружения уязвимости до доставки патча конечному пользователю. OpenSynergy выпустила патч для BlueSDK в сентябре 2024, но производитель head unit должен интегрировать его, автопроизводитель - валидировать, а затем распространить через дилерскую сеть или OTA. Для уязвимостей уровня модема (Unisoc) цепочка ещё длиннее: производитель чипа → производитель head unit → OEM → дилер. На каждом этапе - месяцы. Это значит, что прямо сейчас на дорогах ездят миллионы автомобилей с известными, но незакрытыми уязвимостями в беспроводных интерфейсах.

Безопасность автомобильных беспроводных протоколов требует подхода defence-in-depth: сегментация сетей (infotainment отдельно от vehicle domain), secure gateway между CAN и внешними интерфейсами, мониторинг аномалий на CAN-шине, и - в перспективе - архитектуры, где компрометация одного компонента не ведёт к каскаду. Регуляции UN R155 и R156 обязывают производителей внедрять именно такой подход, но между требованием на бумаге и реализацией в железе - дистанция в годы.
Вопрос к читателям
Кто из вас собирал стенд для тестирования automotive Bluetooth на реальных head unit (VW MIB3, Mercedes NTG6 или аналогах)?Интересуют детали: хватит ли Ubertooth One для перехвата BR/EDR-трафика AVRCP-сессий, или для воспроизведения цепочки PerfektBlue нужен полноценный Bluetooth Classic-адаптер с
и кастомными L2CAP-пакетами через Scapy? Если тестировали фаззинг BlueSDK - на какой версии прошивки head unit и каким фреймворком (Defensics, boofuzz, собственный)? Поделитесь конфигом стенда и версией BlueSDK, на которой удалось получить crash.