|
https://forum.antichat.xyz/attachmen...8a7633521d.png
В июле 2022 года у исследователя безопасности Иана Табора угнали Toyota RAV4. Не через ретранслятор брелока, не через дыру в Bluetooth - через разъём левой фары. Два провода CAN High и CAN Low, устройство стоимостью в десятку долларов по компонентам, корпус от JBL-колонки для маскировки. Инцидент получил идентификатор CVE-2023-29389 и вскрыл то, о чём в автомобильной индустрии предпочитали молчать: протокол CAN, спроектированный в 1980-х, безоговорочно доверяет каждому фрейму на шине. Никакой аутентификации отправителя. Вообще. Здесь разберём полный kill chain атак на CAN bus автомобиля - от лабораторного стенда и сниффинга трафика до инъекции фреймов, fuzzing ECU и принудительного отключения узлов через Bus-Off. Каждый этап - с конкретными командами, hex-значениями и объяснением на уровне протокола. Почему CAN bus - идеальная мишень для атакующего Controller Area Network создавался под инженерную задачу: заменить десятки килограммов медной лапши единой двухпроводной шиной. По данным VicOne, CAN bus экономит до 50 фунтов проводки в типичном автомобиле, где суммарная длина кабелей подбирается к миле. Приоритет - надёжность и экономия, а не защита от злоумышленника. Из-за этого automotive cybersecurity CAN остаётся больной темой для всей отрасли. Архитектурные свойства протокола, которые делают возможными атаки на CAN bus автомобиля: Broadcast-среда без адресации отправителя. Каждый фрейм на шине виден всем ECU разом. Поле Arbitration ID задаёт приоритет сообщения и тип данных, но не идентифицирует источник. Любой узел - легитимный или воткнутый атакующим - может послать фрейм с произвольным ID, и все ECU проглотят его как штатный. На этом принципе и строится CAN-инъекция. Арбитраж как вектор атаки. Когда два узла начинают передачу одновременно, побеждает фрейм с меньшим числовым значением ID - доминантные биты (логический 0) подавляют рецессивные (логическую 1). Исследование CANAttack (PMC, 2023) экспериментально показало: атакующий с высокоприоритетным ID стабильно выигрывает арбитраж и вытесняет легитимные сообщения. Латентность скомпрометированного узла - минимальна, а легитимные ECU стоят в очереди и страдают. Механизм обработки ошибок. Стандарт CAN предусматривает счётчики ошибок (TEC и REC) для каждого узла. При накоплении ошибок узел последовательно переходит из Error Active в Error Passive и затем в Bus-Off - полное отключение от шины. Атакующий может спровоцировать этот переход искусственно, подменяя отдельные биты в чужих фреймах (подробности - в исследовании на OpenNet). Множество физических точек доступа. OBD-II порт - самый известный, но далеко не единственный вход. Проводка CAN шины тянется к фарам, зеркалам, датчикам парковки, дверным модулям. В случае CVE-2023-29389 угонщики зашли через разъём левой фары Toyota RAV4 - хватило отогнуть бампер. Эксплуатация OBD-II атаки и подобных точек входа не требует хакерской квалификации - только физического доступа к машине. https://forum.antichat.xyz/attachmen...7202434611.png Собираем стенд для пентеста автомобильных систем Прежде чем лезть к реальному автомобилю, всё тестирование - на изолированном стенде. Это не перестраховка: без стенда невозможно понять семантику конкретных Arbitration ID и корректно декодировать сигналы для эксплуатации CAN протокола. Требования к окружению Операционная система: Linux (Ubuntu 22.04 LTS или Kali Linux). Критична поддержка SocketCAN - нативной подсистемы ядра для работы с CAN-интерфейсами. На Windows придётся возиться с отдельным стеком вроде PCAN-View, что убивает автоматизацию. CAN-адаптер (на выбор): АдаптерЦена (примерно)SocketCANПрименениеMCP 2515 + MCP2551 (Arduino/RPi)Менее 15 USDЧерез драйвер spi-canБюджетный стенд, обучениеCANable (open-source, STM32)25–40 USDНативно (candleLight)Компактный USB-адаптерKvaser Leaf Light v2300+ USDНативноПромышленный, высокая стабильность Я для домашнего стенда начинал с Arduino + MCP2551 E/P - дёшево и воспроизводимо (такой же вариант описан в исследовании на OpenNet). Для серьёзного automotive penetration testing лучше Kvaser или аналогичный промышленный адаптер - на высоких скоростях бюджетные решения иногда чудят. Софт:
После подключения адаптера поднимаем интерфейс: Код:
sudo ip link set can0 up type can bitrate 500000Код:
candump can0https://forum.antichat.xyz/attachmen...7202576147.png Инъекция фреймов CAN bus: от CVE-2023-29389 до собственного PoC Инъекция фреймов CAN bus - базовая и самая распространённая атака. Суть предельно проста: атакующий втыкается в шину и шлёт фреймы, неотличимые от легитимных, потому что протокол не проверяет источник. Через инъекцию и реализуется ECU спуфинг - подмена сообщений от конкретного блока управления. CVE-2023-29389: анатомия реальной CAN-инъекции Согласно NVD, уязвимость CVE-2023-29389 затрагивает Toyota RAV4 2021 года: автомобиль безоговорочно доверяет сообщениям от других ECU на CAN шине, что позволяет физически находящемуся рядом атакующему завести двигатель. Достаточно добраться до управляющей CAN шины через разъём фары (отогнув бампер) и закинуть поддельные сообщения «Key is validated» через CAN-инъекцию. Эксплуатация зафиксирована в дикой природе начиная с июля 2022 года. CVSS 3.1: 6.8 (MEDIUM). Вектор: Код:
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Хронология атаки по данным расследования Кена Тинделла (Canis Automotive Labs) и анализа VicOne:
Пишем инжектор на python-can: пошаговая инструкция На лабораторном стенде воспроизведём принцип инъекции. Допустим, через предварительный сниффинг ( Код:
candump can0 -lPython: Код:
importКод:
arbitration_id=0x620Код:
cantoolsЧастота 20 фреймов в секунду ( Код:
time.sleep(0.05)Для проверки на втором терминале запускаем Код:
candump can0 -tdFuzzing CAN шины: поиск скрытых уязвимостей в ECU Если инъекция фреймов - воспроизведение известной атаки с конкретными ID и данными, то fuzzing CAN шины - поиск неизвестных реакций ECU на неожиданный ввод. Цель - найти необработанные состояния: зависание ECU, перезагрузку, переход в недокументированный диагностический режим, утечку данных через ответные фреймы. Для vehicle network security fuzzing - основной метод обнаружения zero-day в прошивках ECU. 🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей. Зарегистрироваться или Войти Виды fuzzing и выбор стратегии Random fuzzing - генерация фреймов со случайными Arbitration ID и данными. Запускается одной командой: Код:
cangen can0 -g 1 -I r -L 8 -D rTargeted fuzzing - куда эффективнее. Сначала через Код:
candumpUDS-directed fuzzing - самый целенаправленный вариант для взлома внутренней сети автомобиля. Протокол UDS (ISO 14229) использует CAN как транспорт и определяет стандартные диагностические сервисы: Код:
0x10Код:
0x27Код:
0x31Код:
0x23Python: Код:
importКод:
0x7DFКод:
0x7E8Код:
0x7EFКод:
candump can0,7E8:7F8Код:
0x06, 0x50, ...Код:
0x10Техника безопасности при fuzzing: отправка случайного фрейма на шину работающего автомобиля может отключить ABS, деактивировать подушки безопасности или заблокировать руль. Все эксперименты - только на изолированном стенде или на машине с выключенным двигателем, поднятой на подъёмнике, с отключённой тормозной системой от CAN. Это не паранойя - это здравый смысл. Bus-Off атака: эксплуатация CAN протокола на уровне спецификации Bus-Off - отдельный класс CAN bus уязвимостей, эксплуатирующий не отсутствие аутентификации, а штатный механизм обработки ошибок. Именно поэтому проблему невозможно закрыть обновлением прошивки - она заложена в саму спецификацию протокола CAN. Тут нужна переработка стандарта, а не патч. Каждый ECU поддерживает два счётчика: Transmit Error Counter (TEC) и Receive Error Counter (REC). При ошибке в передаваемом фрейме TEC увеличивается на 8, при успешной передаче уменьшается на 1. Асимметрия - ключ к атаке. Переход состояний: TECСостояниеПоведение узла0–127Error ActiveНормальная работа, отправляет Active Error Flags128–255Error PassiveМожет передавать, но с ограничениямиБолее 255Bus-OffПолное отключение от шины Атакующий вызывает каскадный рост TEC у целевого ECU, подменяя отдельные биты в его фреймах прямо во время передачи. Не целые фреймы подставляются - точечная модификация: один бит превращает легитимный фрейм в ошибочный (подробности - в исследовании на OpenNet). Целевой ECU «считает», что его собственные сообщения содержат ошибки, инкрементирует TEC и через несколько десятков итераций уходит в Bus-Off. Всё, узел мёртв. Практические сценарии, описанные исследователями: отключение ECU автоматического торможения перед препятствием, нарушение контроля дроссельной заслонки (двигатель продолжает ускоряться при отпущенной педали газа), деактивация модуля подушек безопасности, отключение ABS. В терминах MITRE ATT&CK - Endpoint Denial of Service (T1499, Impact). Существенное ограничение: Bus-Off технически сложнее простой инъекции. Побитовая модификация требует точной синхронизации с передачей целевого ECU на физическом уровне, что невозможно через стандартный SocketCAN - нужен прямой доступ к CAN-трансиверу через FPGA или кастомную прошивку микроконтроллера с аппаратным CAN-контроллером. Протокол CAN, кстати, живёт далеко за пределами автомобилей. Bus-Off уязвимость актуальна для лифтов, автоматических дверей, железнодорожного транспорта и промышленной автоматики - везде, где крутится Controller Area Network. Маппинг атак на CAN bus в терминах MITRE ATT&CK Automotive cybersecurity всё чаще рассматривается через призму MITRE ATT&CK. Фреймворк создавался для корпоративных сетей, но его тактики на удивление точно ложатся на kill chain атак на внутреннюю сеть автомобиля. Этап атаки на CAN busТактикаТехникаIDПодключе ие устройства к шинеInitial AccessHardware AdditionsT1200Запись трафика для реверс-инжинирингаDiscovery, Credential AccessNetwork SniffingT1040Подавление легитимных ECU (dominant-override)Credential Access, CollectionAdversary-in-the-MiddleT1557Инъекция поддельных фреймовImpactTransmitted Data ManipulationT1565.002Bus-Off атака на конкретный ECUImpactEndpoint Denial of ServiceT1499Перепрошивка ECU для закрепленияDefense Evasion, PersistenceComponent FirmwareT1109 Маппинг полезен не только для отчётов по пентесту, но и для построения матрицы детектирования: каждой технике сопоставляется источник данных (трафик CAN, логи Gateway ECU, аппаратные датчики) и правило обнаружения. Обнаружение и защита от атак на внутреннюю сеть автомобиля Защита CAN bus - задача нетривиальная: протокол не предусматривает аутентификации на уровне стандарта. Но рабочие подходы существуют, и все они - комбинация нескольких уровней. Timing-based IDS. Каждый ECU шлёт фреймы с характерной периодичностью: модуль ABS - каждые 10 мс, климат-контроль - каждые 100 мс. Инъекция дополнительных фреймов с тем же ID ломает эту периодичность. IDS, анализирующая интервалы между фреймами одного ID, ловит ECU spoofing с высокой точностью. По данным CANAttack (PMC, 2023), при DoS-атаке через арбитраж латентность легитимных сообщений резко прыгает - надёжный индикатор компрометации. Entropy-based detection. Нормальный трафик CAN предсказуем: фиксированный набор ID, ограниченный диапазон значений в полях данных. Fuzzing-атака резко поднимает энтропию - появляются нетипичные комбинации. Исследователи из журнала «Защита информации. Инсайд» предложили визуальную аналитику на основе радиальных гистограмм для мониторинга DoS, Fuzzy и Spoofing атак по дампам трафика - подход, полезный и при разборе инцидентов постфактум. Перепрограммирование Gateway ECU. CVE-2023-29389 показала: Gateway ECU Toyota RAV4 тупо ретранслировал фреймы между шинами без проверки. Временное решение от Тинделла: перепрограммировать Gateway так, чтобы он пересылал сообщения о валидации ключа только при отсутствии ошибок на шине в течение заданного окна. Логика: CAN-инжектор с dominant-override неизбежно генерирует ошибки при подавлении других узлов. Нет ошибок за окно времени - можно пересылать. Есть - блокируем. Zero Trust для CAN. Постоянное решение, описанное VicOne: ECU должны прекратить доверять сообщениям по умолчанию. Каждый фрейм проходит криптографическую валидацию - ECU получают секретные ключи и привязываются к конкретному автомобилю. На практике это CAN FD с дополнительными байтами для MAC (Message Authentication Code) или перевод критичных сегментов на Automotive Ethernet. Сегментация шин. Вместо единой шины - топология с центральным коммутатором, фильтрующим трафик по правилам. Фрейм от модуля фар физически не попадает на шину управления двигателем. При такой архитектуре атака через разъём фары, как в CVE-2023-29389, невозможна: даже получив доступ к одному сегменту, атакующий не может инъецировать фреймы в критичный. Вопрос к читателям Bus-Off атака упирается в точную синхронизацию с битовым потоком целевого ECU. На стандартном SocketCAN-адаптере типа CANable с прошивкой candleLight задержка между user-space и физическим уровнем делает побитовую модификацию фреймов практически невозможной. У кого есть опыт реализации Bus-Off на стенде - какое оборудование использовали для побитового доступа: FPGA на Xilinx Zynq с IP-ядром CAN, кастомная прошивка на STM32 с прямым управлением аппаратным CAN-контроллером, или коммерческий анализатор вроде CANalyzer с CAPL-скриптом? Поделитесь конфигурацией стенда и достигнутой точностью синхронизации в наносекундах. |
Отличная статья! Благодарю
|
| Время: 03:39 |