Модуль телематического блока управления на антистатическом коврике с гравировкой API-запроса. Рядом смартфон с интерфейсом Burp Suite, тиловое свечение экрана на тёмной поверхности.


На аудите 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: не один аккаунт, а все машины на платформе.

Три сценария с реальным импактом:
  1. Угон. IDOR в vehicle API даёт unlock + start engine на произвольном VIN. Атакующий не вскрывает замок - TCU исполняет HTTP-команду как легитимную.
  2. Ransomware на колёсах. Блокировка запуска двигателя через API endpoint. Если POST /vehicles/{vin}/commands/immobilize доступен через BOLA - шантаж владельца fleet становится реальностью.
  3. Продажа данных. GPS-треки, маршруты, контакты из Bluetooth-синхронизации. По данным исследователей, раскрывших уязвимости осенью 2022 года, они могли определять местоположение автомобилей, используя только VIN или email-адрес владельца (Cisco Security Blog).

Recon и перехват трафика: подготовка к пентесту automotive API​

1781305751974.webp

Требования к окружению:
  • ОС: 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;
    };
});
После unpinning в Burp появляются три категории критичных запросов. Первая - OAuth token exchange: 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-уязвимости​

1781305845826.webp

[Применимо: внешний пентест, 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...
Заменяем VIN WBA1234567890ABCD (свой) на WBA9876543210ZYXW (чужой). Ответ 200 с данными чужого автомобиля - BOLA подтверждена. По данным исследования Sam Curry о SiriusXM Connected Vehicle Services (ноябрь 2022), API-запрос через telematics service provider с чужим VIN позволял удалённо запускать, останавливать, блокировать и разблокировать автомобили нескольких глобальных брендов.

Что тестировать после подтверждения:
  1. Read vs Write scope. Только чтение (/status, /location) или запись тоже (/commands/unlock, /commands/start)? Read-only BOLA - серьёзно (GPS-слежка за fleet). Write BOLA - критично (угон).
  2. Перебор 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).
  3. Альтернативные идентификаторы. Кроме VIN, тестируем accountId, vehicleId (внутренний ID OEM), email владельца. В исследовании Curry et al. обнаружились 23 уязвимости в 7 OEM - далеко не все были привязаны к VIN.
  4. Масштаб fleet. Документируем: сколько автомобилей потенциально затронуто? Если BOLA работает на любом VIN этого OEM - масштаб fleet-wide.
OPSEC при тестировании. OEM, прошедшие через публичные инциденты 2022–2024, начали внедрять anomaly detection на vehicle endpoint'ы. Перебор VIN на высокой скорости (дефолтный 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 - проходят с лабами.
 
Последнее редактирование модератором:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab