Современный автомобиль - это пять-семь одновременно работающих радиоинтерфейсов. 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 / RKE | 125 кГц / 433 МГц | Adversary-in-the-Middle (T1557)¹ | HackRF One, Yard Stick One, Proxmark3 |
| Bluetooth | 2.4 ГГц | Exfiltration Over Bluetooth (T1011.001) | btlejack, Ubertooth One, Scapy |
| Wi-Fi | 2.4 / 5 ГГц | Evil Twin (T1557.004), Wi-Fi Networks (T1669) | hostapd, aircrack-ng |
| Cellular | 700–2600 МГц | Network Sniffing (T1040) | srsRAN, IMSI catcher |
| V2X (DSRC/C-V2X) | 5.9 ГГц | Network Sniffing (T1040) | GNU Radio, USRP |
| TPMS | 315 / 433 МГц | - (маппинг приблизительный)¹ | RTL-SDR, Yard Stick One |
| GPS | 1.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: устройство глушит и одновременно записывает первый сигнал от брелока, затем записывает второй, а первый проигрывает для легитимного открытия. В итоге у атакующего остаётся неиспользованный валидный код. Красиво и подло.
Почему 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 | Описание | CVSS | CWE |
|---|---|---|---|
| CVE-2024-45431 | Отсутствие валидации remote L2CAP channel ID (CID) - атакующий создаёт канал с null-идентификатором. Самостоятельный impact низкий (C:L/I:N/A:N), используется как primitive для цепочки с CVE-2024-45434 | 5.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-45434 | Use-After-Free - удалённое выполнение кода в контексте процесса Bluetooth | 9.8 (CRITICAL) | CWE-416 (Use After Free) |
Посмотрите на вектор CVE-2024-45434:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - сетевой доступ, низкая сложность, никаких привилегий, никакого взаимодействия пользователя. Максимально злая комбинация. Атакующий шлёт вредоносные команды через протокол управления аудиоплеером (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:
# Сканирование Bluetooth Classic-устройств в радиусе
# (hcitool deprecated в BlueZ 5.x; используйте bluetoothctl)
bluetoothctl scan on
# Перечисление сервисов на обнаруженном head unit
bluetoothctl info <BD_ADDR>
# Фаззинг L2CAP с кастомным CID (концептуальный пример - НЕ готов к запуску как есть)
# Требует: 1) предварительного ACL-соединения (hcitool cc <BD_ADDR>), 2) корректного ACL handle,
# 3) CAP_NET_RAW (sudo), 4) rfkill unblock bluetooth. Без ACL-handshake head unit отбросит пакет.
# Для практического L2CAP-фаззинга используйте:
# bluez/test/l2test -r <BD_ADDR> (встроенный в BlueZ)
# или boofuzz с Bluetooth Classic harness
# Предварительно: sudo systemctl stop bluetooth && sudo hciconfig hci0 upАтаки на автомобильный Wi-Fi: Evil Twin на парковке
Многие современные автомобили раздают Wi-Fi-хотспот для пассажиров или подключаются к домашней/корпоративной сети для загрузки OTA-обновлений. Этот интерфейс - вектор для классической атаки Evil Twin (T1557.004).Сценарий: атакующий разворачивает точку доступа с SSID, идентичным ранее запомненной сети автомобиля (например, домашней Wi-Fi владельца). Infotainment-система автоматически цепляется к знакомому SSID. Дальше весь трафик head unit идёт через контролируемую точку - атакующий перехватывает DNS-запросы, HTTP-трафик, и при наличии дыр в ПО head unit может доставить payload.
Используя
hostapd для создания Evil Twin и bettercap для 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. Вектор:
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H - атака из смежной сети (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-заголовков последовательно обрабатывает необязательные заголовки (по 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 - водительский контроль остаётся необходимым.
Практика: от радиоэфира до CAN-шины за три шага
Этот раздел описывает полную цепочку атаки на безопасность беспроводных систем авто, объединяющую несколько интерфейсов. Подход типичен для пентеста автомобильных систем.Матрица митигаций по автомобильным беспроводным протоколам
| Интерфейс | Основная атака | Митигация | Статус внедрения |
|---|---|---|---|
| PKES | Relay attack | UWB time-of-flight | Частично (Apple CarKey, BMW) |
| RKE | RollJam / replay | AES-128 rolling code + таймаут | Да, в новых моделях |
| Bluetooth | PerfektBlue (CVE-2024-45434) | Обновление BlueSDK, отключение auto-pairing | Патч OpenSynergy доступен с сентября 2024 |
| Wi-Fi | Evil Twin | Проверка сертификата AP, отключение auto-connect | Нет в большинстве head units |
| Cellular | IMSI Catching | Переход на 5G (SUPI encryption), отключение 2G/3G fallback | Частично (зависит от оператора) |
| Cellular | Modem RCE (CVE-2024-39431) | Обновление прошивки модема, MPU-изоляция CP/AP | Зависит от OEM |
| V2X (DSRC) | Ghost Node, BSM spoofing | Миграция на C-V2X с PKI-подписью | В процессе |
| V2X (C-V2X 5G) | Квантовые атаки (перспектива) | Post-quantum cryptography | Исследования |
| TPMS | Spoofing давления | Аутентификация сенсоров (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-адаптер сhciconfig и кастомными L2CAP-пакетами через Scapy? Если тестировали фаззинг BlueSDK - на какой версии прошивки head unit и каким фреймворком (Defensics, boofuzz, собственный)? Поделитесь конфигом стенда и версией BlueSDK, на которой удалось получить crash.
Последнее редактирование модератором:
