На аудите REST API одного европейского автопроизводителя был подменён VIN в
GET /vehicles/{vin}/status - и получены GPS-координаты, уровень топлива и статус замков чужого автомобиля. Один HTTP-запрос, один изменённый параметр. Backend просто не проверял, принадлежит ли VIN аутентифицированному пользователю. В 2024 году группа Curry et al. опубликовала исследование критических API-уязвимостей в системах Kia (samcurry.net) - и класс ошибок ровно тот же. Ниже - конкретная методика тестирования automotive API для пентестеров, которые работают с Burp и знают, что такое IDOR, но ещё не сталкивались со спецификой connected vehicle.В статье использованы материалы из зарубежных источников.
Kill chain automotive API: от мобильного приложения до fleet-wide control
[Применимо: внешний пентест, grey box с учётной записью OEM-сервиса]Архитектура connected vehicle: мобильное приложение -> OEM cloud backend (REST API) -> Telematics Control Unit (TCU) в автомобиле -> CAN-шина с десятками ECU. Мобильное приложение - самый доступный элемент: APK лежит в Google Play, декомпиляция занимает минуты, контроль над трафиком через proxy - полный. IVI-системы (In-Vehicle Infotainment) и мобильные приложения сидят на одном backend - это подтверждено публичными исследованиями. Уязвимость, найденная через мобильный клиент, часто эксплуатируема и через головное устройство.
Kill chain position. Мобильное приложение - Exploit Public-Facing Application (T1190, Initial Access). Через него атакующий получает foothold на уровне API: OAuth-токен, endpoint'ы управления автомобилем, привязку VIN к аккаунту. Дальше - эскалация: BOLA (API1:2023 - Broken Object Level Authorization, OWASP API Security Top 10) даёт доступ к чужим автомобилям, а Steal Application Access Token (T1528, Credential Access) позволяет генерировать токены программно, минуя UI-flow.
Принципиальное отличие от стандартного web-пентеста: одна BOLA в automotive API - не утечка данных одного пользователя. Это физический доступ к автомобилю. Масштаб fleet-wide: не один аккаунт, а все машины на платформе.
Три сценария с реальным импактом:
- Угон. IDOR в vehicle API даёт
unlock+start engineна произвольном VIN. Атакующий не вскрывает замок - TCU исполняет HTTP-команду как легитимную. - Ransomware на колёсах. Блокировка запуска двигателя через API endpoint. Если
POST /vehicles/{vin}/commands/immobilizeдоступен через BOLA - шантаж владельца fleet становится реальностью. - Продажа данных. GPS-треки, маршруты, контакты из Bluetooth-синхронизации. По данным исследователей, раскрывших уязвимости осенью 2022 года, они могли определять местоположение автомобилей, используя только VIN или email-адрес владельца (Cisco Security Blog).
Recon и перехват трафика: подготовка к пентесту automotive API
Требования к окружению:
- ОС: Kali Linux / Ubuntu 22.04+ / macOS
- RAM: минимум 8 ГБ (jadx на крупных automotive APK съедает 1–2 ГБ, плюс эмулятор Android и Burp одновременно)
- Инструменты: jadx 1.5+ (активно поддерживается, ~42k звёзд на GitHub), apktool 2.9+, MobSF 4.x, Frida 16.x+ (активно поддерживается), objection 1.11+, Burp Suite Pro/Community
- Рутованное Android-устройство или эмулятор (Android 10–13; для 14+ могут потребоваться дополнительные патчи)
- APK: из Google Play через
apkeepили зеркала (apkpure, apkmirror) - Бесплатная учётная запись OEM (регистрация обычно не требует привязки к реальному автомобилю)
Статический анализ APK
Запускаемjadx -d output_dir target.apk и целенаправленно ищем четыре класса артефактов.API endpoint'ы. Строки вида
https://mal-1a.vendor.de/api/, https://b2vapi.vendor.com/webapi/. В automotive-приложениях URL захардкожены в Retrofit-клиентах или OkHttp-interceptor'ах. grep -r "https://" output_dir/ даёт начальную карту. Проверяем res/raw/ и assets/ - там нередко валяются конфигурационные JSON с URL backend-сервисов.OAuth-параметры.
client_id, client_secret, redirect_uri, scope. Если client_secret лежит прямо в APK - это Credentials In Files (T1552.001, Credential Access). Через него можно генерировать токены программно, без UI-flow.Deprecated API-версии. OEM поддерживают
/v1/, /v2/, /v3/ для обратной совместимости. Устаревшие версии нередко лишены rate limiting, device binding и дополнительной авторизации - Improper Inventory Management (API9:2023, OWASP API Security Top 10). Ищем все версионные prefixes в декомпилированном коде и проверяем, отвечают ли endpoint'ы. Как правило - отвечают.Захардкоженные секреты. API-ключи для картографии (Google Maps, HERE), Firebase-конфигурации, push-notification tokens. Firebase с открытыми правилами доступа - прямой путь к пользовательским данным всего fleet.
MobSF 4.x автоматизирует часть рутины: загружаете APK - получаете endpoint'ы, небезопасные хранилища, hardcoded secrets. Но для анализа OAuth-flow и vehicle-специфичной логики авторизации ручной разбор через jadx незаменим. Автоматика слепа к бизнес-логике привязки VIN к аккаунту - а именно там живут самые жирные баги.
SSL Unpinning для automotive-приложений
Практически все automotive-приложения реализуют certificate pinning. Стандартный Burp CA-сертификат в системном хранилище не пропустит трафик - в proxy будет пусто.Базовый подход:
objection -g com.vendor.mycar explore -> android sslpinning disable -> proxy в Wi-Fi настройках -> Burp. Работает, когда приложение использует стандартный Network Security Config без кастомных проверок.Когда стандартный метод не срабатывает - а на свежих automotive-приложениях крупных OEM это норма - нужен кастомный Frida-скрипт. OEM часто используют OkHttp CertificatePinner с дополнительными callback'ами:
JavaScript:
// Frida: обход OkHttp 3.x CertificatePinner
// Для OkHttp 4.x - дополнительный hook на check$okhttp
Java.perform(function() {
var CertPinner = Java.use('okhttp3.CertificatePinner');
CertPinner.check.overload('java.lang.String', 'java.util.List')
.implementation = function(hostname, peerCerts) {
console.log('[+] Pinning bypassed: ' + hostname);
return;
};
});
POST /auth/token с grant_type, code, client_id. Точка для Steal Application Access Token (T1528). Проверяем: привязан ли refresh_token к device fingerprint, есть ли ротация, инвалидируется ли при смене пароля. Вторая - vehicle status: GET /vehicles/{vin}/status - GPS, топливо, статус замков; тут ищем BOLA. Третья - remote commands: POST /vehicles/{vin}/commands/unlock, /start - самое критичное: какие проверки авторизации стоят между HTTP-запросом и физическим действием на TCU?Когда unpinning НЕ работает
| Защитный механизм | Что происходит | Варианты обхода |
|---|---|---|
| RASP (DexGuard, Promon) | Frida-attach крашит приложение при старте | Патчинг APK через apktool, удаление проверок, re-sign. Frida Gadget injection. Занимает часы |
| Root detection (Play Integrity + StrongBox) | Приложение не запускается на рутованном устройстве | Magisk + Shamiko для software-проверок. Hardware attestation пока не обходится надёжно |
| Mutual TLS с клиентским сертификатом из HSM | В proxy нет трафика даже после SSL unpinning | Перехват невозможен без извлечения ключа из hardware. Самый крепкий барьер - реализуют единичные OEM |
BOLA через VIN: анатомия главной automotive-уязвимости
[Применимо: внешний пентест, grey box с учётной записью владельца]
BOLA (API1:2023 - Broken Object Level Authorization) - самая частая и самая опасная уязвимость в automotive API. Механика примитивна: сервер принимает VIN как идентификатор объекта, но не проверяет его принадлежность аутентифицированному пользователю.
Отличие от "обычного" IDOR: в e-commerce IDOR по
order_id раскрывает данные одного заказа. В automotive API IDOR по VIN открывает доступ к физическому объекту стоимостью от миллиона рублей - с возможностью удалённого управления.Типичный запрос:
HTTP:
GET /api/v2/vehicles/WBA1234567890ABCD/status HTTP/1.1
Host: api.vendor.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
WBA1234567890ABCD (свой) на WBA9876543210ZYXW (чужой). Ответ 200 с данными чужого автомобиля - BOLA подтверждена. По данным исследования Sam Curry о SiriusXM Connected Vehicle Services (ноябрь 2022), API-запрос через telematics service provider с чужим VIN позволял удалённо запускать, останавливать, блокировать и разблокировать автомобили нескольких глобальных брендов.Что тестировать после подтверждения:
- Read vs Write scope. Только чтение (
/status,/location) или запись тоже (/commands/unlock,/commands/start)? Read-only BOLA - серьёзно (GPS-слежка за fleet). Write BOLA - критично (угон). - Перебор VIN. VIN - 17-символьный идентификатор с предсказуемой структурой: позиции 1–3 определяют производителя (WMI), 4–8 - модель и конфигурацию (VDS), 9 - контрольная цифра (вычисляется), 10–17 - серийный номер (VIS). Зная WMI целевого OEM, можно генерировать валидные VIN и перебирать.
ffufс кастомным вордлистом из валидных VIN-паттернов для конкретного OEM, или Burp Intruder с позицией на VIN-поле. Если API не имеет rate limiting - это дополнительно Unrestricted Resource Consumption (API4:2023). - Альтернативные идентификаторы. Кроме VIN, тестируем
accountId,vehicleId(внутренний ID OEM), email владельца. В исследовании Curry et al. обнаружились 23 уязвимости в 7 OEM - далеко не все были привязаны к VIN. - Масштаб fleet. Документируем: сколько автомобилей потенциально затронуто? Если BOLA работает на любом VIN этого OEM - масштаб fleet-wide.
ffuf) может сработать как триггер: блокировка аккаунта, бан IP, алерт в SOC вендора. Начинайте с единичных ручных запросов - подтвердите BOLA, оцените scope, и только потом масштабируйте. Работать в рамках согласованного engagement или bug bounty программы - обязательно.Пост-эксплуатация: куда идти после BOLA в automotive API
BOLA подтверждена - пентест не заканчивается. Automotive API-инфраструктура содержит дополнительные attack surface, расширяющие импакт.SSRF в vehicle endpoint'ах. Ряд OEM использует общий backend для мобильных приложений, IVI-систем и дилерских порталов. SSRF в одном из endpoint'ов мобильного приложения может открыть доступ к внутренним сервисам - fleet management, дилерские инструменты, административные панели с расширенными привилегиями. Ищем параметры с URL-значениями: callback URL,
redirect_uri, webhook endpoints.Account takeover через OAuth-flow. Если
refresh_token не привязан к device fingerprint (а на legacy API-версиях это встречается постоянно), атакующий с чужим токеном получает полный доступ к аккаунту: личные данные, история поездок, привязанные платёжные методы, все автомобили на аккаунте. Проверяем: инвалидируется ли refresh_token при смене пароля? Есть ли ротация? Привязан ли к IP или User-Agent?Deprecated endpoints как backdoor. API9:2023 - Improper Inventory Management. Старые версии API (
/v1/) могут поддерживать операции, удалённые из текущей версии, без авторизации или с ослабленными проверками. В automotive-контексте: уязвимость, "закрытую" в /v3/, можно эксплуатировать через /v1/, который забыли отключить. Системный grep по всем версионным prefixes из APK с проверкой каждого - обязательная часть automotive API пентеста.Дилерские и fleet management API. При исследовании mobile API иногда всплывают endpoint'ы для дилеров или fleet-операторов:
/dealer/vehicles/{vin}/diagnostics, /fleet/tracking. Эти endpoint'ы часто авторизованы по другой схеме - API-key вместо OAuth - и содержат расширенные возможности: полная диагностика, история обслуживания, управление иммобилайзером. Если API-key извлечён из APK, Credentials In Files (T1552.001) превращается в pivot к дилерскому уровню доступа.Ограничения automotive API пентеста
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Заключение
Последние два года я наблюдаю парадокс: OEM тратят миллионы на безопасность CAN-шины, шифрование V2X и сертификацию по ISO/SAE 21434 - а потом выкатывают REST API с BOLA, которую находишь через Burp за полчаса. Дело не в некомпетентности. Проблема организационная: automotive security teams думают категориями ECU, CAN и AUTOSAR, AppSec-команды - категориями HTTP, OAuth и OWASP. Vehicle API живёт на пересечении, и за него целиком не отвечает ни одна группа.23 уязвимости в 7 OEM из исследования Curry et al. - не аномалия, а следствие этого разрыва. В 2024 году та же группа опубликовала исследование критических API-уязвимостей у Kia - два года после первой волны дискложуров, а класс ошибок не изменился: BOLA, отсутствие привязки VIN к аккаунту, deprecated endpoints без авторизации.
Для пентестеров automotive API - растущая ниша. Навыки web-пентеста переносятся напрямую, специфика (VIN как идентификатор, TCU как исполнитель команд, CAN-шина за API-слоем) осваивается за пару проектов. Попробуйте взять APK любого крупного OEM из Google Play, прогнать через jadx и поискать захардкоженные
client_secret - результаты могут удивить. На WAPT эту цепочку - от декомпиляции мобильного приложения до эксплуатации BOLA - проходят с лабами.
Последнее редактирование модератором: