Статья Безопасность подключённых автомобилей: пентест мобильного приложения от реверса APK до удалённых команд

Несколько CVE, рабочие end-to-end exploit-цепочки, fleet-wide impact: от захардкоженных credentials в APK до удалённой разблокировки дверей, доступа к камерам и запуска двигателя. Серия работ Curry et al. («Web Hackers vs. The Auto Industry», samcurry.net, январь 2023) показала, что отправной точкой нередко становились APN-credentials, зашитые в прошивку IVI-системы. Но чтобы добраться до таких цепочек, не обязательно выпаивать flash с платы. Мобильное приложение OEM - вход в тот же backend, и классы ошибок кочуют от вендора к вендору с завидным постоянством: IDOR по VIN-номеру, OAuth-токены без ротации, deprecated endpoint'ы без авторизации. Ниже - конкретная методика пентеста automotive-приложений уровня MyAudi, MyBMW, NissanConnect и классы уязвимостей, которые русскоязычные источники почему-то обходят стороной.

Поверхность атаки и место в kill chain​

Архитектура connected vehicle: мобильное приложение на смартфоне -> OEM cloud backend (REST API) -> Telematics Control Unit (TCU) в автомобиле -> внутренняя CAN-шина с десятками ЭБУ. Мобильное приложение - самый доступный элемент цепочки: APK лежит в Google Play, декомпиляция за минуты, контроль над трафиком через proxy.

Kill chain position. Мобильное приложение - это initial access (Exploit Public-Facing Application, T1190). Через него атакующий получает foothold на уровне API: OAuth-токен, endpoint'ы для управления автомобилем, механизмы привязки VIN к аккаунту. Дальше - эскалация: IDOR даёт доступ к чужим автомобилям, SSRF открывает внутреннюю инфраструктуру OEM, broken access control позволяет выполнять привилегированные операции.

IVI-системы и мобильные приложения сидят на одном backend - это подтверждено публичными исследованиями. Уязвимость, найденная через мобильный клиент, часто эксплуатируема и через головное устройство. Одна BOLA-уязвимость в API даёт fleet-wide impact - доступ не к одной машине, а ко всем, подключённым к сервису.

Контекст применения: внешний пентест, black box или grey box с учётной записью владельца. Достаточно рутованного Android-устройства, бесплатной учётной записи OEM (регистрация обычно не требует привязки к реальному авто) и стандартного набора инструментов.

Бизнес-логика атаки. Три сценария, каждый - реалистичный: (1) угон - IDOR в vehicle API даёт unlock + start engine на чужом VIN; (2) ransomware - блокировка запуска двигателя с требованием выкупа; (3) продажа данных - GPS-треки, маршруты, контакты. По данным TAdviser, в российском даркнете уже фигурируют предложения по удалённому взлому автомобилей.

Статический анализ APK: что извлечь в первую очередь​

Требования к окружению:

• ОС: GNU/Linux (Kali/Ubuntu 22.04+) или macOS
• RAM: минимум 4 ГБ (jadx на крупных automotive APK жрёт 1–2 ГБ)
• Инструменты: jadx 1.5+ (активно поддерживаемый проект), apktool 2.9+, MobSF 4.x для автоматизации
• APK: из Google Play через apkeep или зеркала

Декомпилируем APK через jadx -d output_dir target.apk и целенаправленно ищем четыре класса артефактов.

API endpoint'ы. Строки вида https://mal-1a.audi.de/api/, https://b2vapi.bmwgroup.com/webapi/. В automotive-приложениях endpoint'ы захардкожены в классах Retrofit-клиентов или OkHttp-interceptor'ах. Grep по паттерну https:// в декомпилированном коде даёт начальную карту API. Отдельно проверяем res/raw/ и assets/ - там нередко валяются конфигурационные JSON и XML с URL backend-сервисов.

OAuth-параметры. client_id, client_secret, redirect_uri, scope. Для приложений уровня MyAudi OAuth 2.0 - стандарт. Если client_secret лежит прямо в APK - это Credentials In Files (T1552.001, credential-access). Через него можно генерировать токены программно, минуя UI-flow приложения. И да, такое встречается чаще, чем хотелось бы.

Захардкоженные секреты. API-ключи для картографии, Firebase-конфигурации, сертификаты. Захардкоженные APN-credentials в IVI-прошивках создают cross-layer attack surface - локальный доступ к этим секретам позволяет эскалировать атаку до fleet-wide control. В мобильных APK работает тот же принцип.

Deprecated API-версии. OEM поддерживают /v1/, /v2/, /v3/ для обратной совместимости. Устаревшие версии часто лишены rate limiting, device binding и дополнительной авторизации - это Improper Inventory Management (API9:2023 по OWASP API Security Top 10). Ищем все версионные prefixes в декомпилированном коде и проверяем, живы ли они. Спойлер: обычно живы.

MobSF автоматизирует часть рутины: загружаете APK - получаете endpoint'ы, небезопасные хранилища, hardcoded secrets. Но ручной разбор через jadx незаменим для анализа OAuth-flow и vehicle-специфичной логики авторизации - автоматика тут слепа.

SSL Unpinning: обход certificate pinning через Frida​

Практически все automotive-приложения реализуют certificate pinning. Стандартный Burp CA-сертификат, установленный в системное хранилище, не пропустит трафик. Без unpinning в proxy - пустота.

Требования к окружению:

• Рутованное Android-устройство или эмулятор (Android 10–13; для 14+ могут потребоваться дополнительные патчи)
• RAM: минимум 8 ГБ (эмулятор + Burp одновременно)
• Frida 16.x+ (активно поддерживаемый проект), objection 1.11+
• Burp Suite с настроенным invisible proxy на 8080

Цепочка: frida-server на устройстве -> objection -g com.audiag.myaudi explore -> android sslpinning disable -> proxy в Wi-Fi настройках -> Burp.

Если стандартный disable не срабатывает (а на свежих automotive-приложениях OEM добавляют кастомные реализации через OkHttp CertificatePinner или Network Security Config с дополнительными callback'ами) - нужен кастомный Frida-скрипт:

// Frida: упрощённый обход OkHttp CertificatePinner
// Покрывает один overload (OkHttp 3.x); для OkHttp 4.x нужен
// дополнительный hook на check$okhttp. Используйте Universal Android
// SSL Pinning Bypass (Frida CodeShare) или objection для полного покрытия
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 появляется весь трафик. Типичная картина для automotive-приложения:

• 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, топливо, статус замков. Тут ищем IDOR: подставляем чужой VIN.
• Remote commands - POST /vehicles/{vin}/commands/unlock, /start - самое критичное. Какие проверки авторизации стоят между HTTP-запросом и физическим действием?

Весь перехват - Adversary-in-the-Middle (T1557) и Network Sniffing (T1040) на уровне приложения. Разница с классическим MITM: мы контролируем устройство и целенаправленно обходим защиту TLS.

Когда техника НЕ работает. (1) RASP-решения (Guardsquare DexGuard/iXGuard, Promon): binary-level обфускация и runtime-проверки убивают Frida-attach при старте. Выход - патчинг APK через apktool с удалением проверок и re-sign, либо Frida Gadget injection. Занимает часы, но работает. (2) Root detection через Play Integrity API с hardware attestation (StrongBox Keymaster): Magisk + Shamiko обходит software-проверки, но hardware attestation на устройствах с заблокированным bootloader'ом пока не обходится надёжно. (3) Mutual TLS с клиентским сертификатом из HSM: proxy-перехват невозможен без извлечения ключа из hardware - самый крепкий барьер, но реализуют его единичные OEM.

Уязвимости vehicle API по OWASP API Security Top 10​

Automotive API подвержены стандартным классам уязвимостей, но с принципиальным отличием: эксплуатация затрагивает физическую безопасность. SQL-инъекция в интернет-магазине - утечка данных. BOLA в vehicle API - посторонний заводит ваш двигатель.

BOLA / IDOR (API1:2023 - Broken Object Level Authorization)​

Самая частая и опасная уязвимость в automotive API. Сервер принимает VIN как идентификатор объекта, но не проверяет принадлежность этого VIN аутентифицированному пользователю. Звучит примитивно - а работает у крупнейших OEM.

По данным Cequence, API-запрос через telematics service provider с чужим VIN в поле идентификатора позволял удалённо запускать, останавливать, блокировать и разблокировать автомобили нескольких глобальных брендов. Типичный запрос:

GET /api/v2/vehicles/WVWZZZ3CZWE123456/status
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Замена VIN на произвольный - если сервер вернул 200 с чужими данными, это BOLA. Если POST .../commands/unlock с тем же чужим VIN тоже отработал - это потенциальный угон.

По данным PlaxidityX, IDOR-уязвимости в API автосигнализаций Viper и Pandora позволяли сбрасывать пароли, захватывать аккаунты и заглушать двигатель работающего автомобиля через smart alarm API.

Работает если: legacy API (v1/v2) без server-side VIN binding, отсутствие ABAC/RBAC на уровне vehicle resource. Не работает: API с серверной проверкой привязки VIN к аккаунту через authorization service; API с HMAC-подписью запросов (VIN + timestamp + user_id).

Broken Authentication (API2:2023)​

OAuth-реализации в automotive имеют характерные слабости:

• Отсутствие device binding - access_token с одного смартфона работает с другого (T1528, Steal Application Access Token)
• Refresh_token без ротации - живёт месяцами и не инвалидируется при смене пароля
• Client_secret в APK - извлечённый из декомпилированного кода credential позволяет генерировать токены программно

По данным TAdviser, неправильно настроенная SSO-система BMW и Rolls-Royce позволяла через одну учётную запись получить доступ к дилерскому порталу с VIN-номерами и документами о продаже. Одна учётка - и ты в дилерском бэкенде.

SSRF: от мобильного API к внутренней инфраструктуре​

SSRF - путь от внешнего API-endpoint'а к внутренним сервисам OEM. По данным Curry et al. (samcurry.net, январь 2023), SSRF в IoV-backend'е Mercedes-Benz позволила исследователям обратиться к внутренним сервисам управления fleet'ом. Итог - end-to-end exploit от firmware extraction до доступа к внутренним инструментам управления автопарком. Обнаруженные уязвимости были исправлены вендорами после ответственного раскрытия.

SSRF в automotive - second-stage атака: сначала foothold через mobile API, затем обнаружение endpoint'а, принимающего URL как параметр. Классическая эскалация, но с нетипичным импактом.

Kill chain: пять шагов от APK до remote commands​

Полная цепочка при пентесте automotive mobile app:

Шаг 1 - Recon. APK -> jadx -> endpoint'ы, OAuth credentials, deprecated API-версии. MobSF для автоматического скана. Результат: карта API с десятками endpoint'ов и перечень секретов.

Шаг 2 - Traffic interception (T1557). Рутованное устройство -> Frida SSL unpinning -> Burp Suite. Маппим OAuth-flow, фиксируем структуру vehicle-запросов. Без этого шага - слепое тестирование.

Шаг 3 - IDOR-тестирование (T1190). Подставляем чужие VIN в каждый endpoint. Проверяем раздельно: авторизация может быть неравномерной - status доступен по чужому VIN, а commands закрыты дополнительной проверкой. Без доступа к физическому автомобилю для верификации нельзя гарантировать, что команда дойдёт до TCU - но BOLA на уровне API подтверждается однозначно.

Шаг 4 - Token manipulation (T1528). Проверяем device binding, ротацию refresh_token, генерацию токенов через извлечённый client_secret. System Information Discovery (T1082) - через vehicle status API собираем данные: модель, год, пробег, GPS-координаты.

Шаг 5 - Remote commands. Если BOLA подтверждена - unlock, start, horn на целевом VIN. На этом этапе атакующий получает физический контроль над автомобилем.

Реальные инциденты подтверждают цепочку. NissanConnect (Nissan Leaf): плохо аутентифицированный API давал удалённый контроль климата, разряд батареи и трекинг маршрутов (по данным PlaxidityX). Spireon (по данным samcurry.net, январь 2023, заявлено около 15 миллионов подключённых автомобилей): обход аутентификации и доступ к панели администрирования с возможностью отправлять произвольные команды на весь fleet, включая транспорт экстренных служб. В системах Ferrari (по данным samcurry.net) через broken access control в API управления пользователями POST-запрос на endpoint создания аккаунтов позволял назначить роль super-admin. Один POST-запрос - и ты админ Ferrari.

Когда стандартная методика не работает​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Automotive security находится примерно там, где web-безопасность была десять лет назад. Те же IDOR, те же текущие токены, те же deprecated API без авторизации - только ставки несопоставимы. Утечка данных из интернет-магазина неприятна. IDOR в vehicle API - это посторонний человек, разблокирующий ваш автомобиль на ночной парковке.

OEM продолжают относиться к мобильному приложению как к маркетинговому продукту, а не как к control plane для физического объекта стоимостью в несколько миллионов. Security review для финтех-приложения с лимитом перевода 500 рублей длится неделями. Для приложения, управляющего разблокировкой автомобиля - зачастую ограничивается автоматическим сканом.

Серия исследований Curry et al. (2023) это подтверждает: systemic anti-patterns - захардкоженные credentials, отсутствие изоляции APN, broken access control - воспроизводятся у каждого следующего вендора. Одна SSRF в backend'е Mercedes-Benz - доступ к внутренним инструментам управления автопарком. Одна IDOR в Spireon - предположительно контроль над миллионами подключённых автомобилей. Не один автомобиль, а fleet целиком.

Я ожидаю, что в ближайшие пару лет automotive API станут одной из горячих тем в bug bounty - несколько OEM уже запустили программы, а attack surface только растёт. Если хочешь отточить подмену object ID в API без юридических последствий реального VIN - web-задачи на HackerLab.pro (https://hackerlab.pro) строятся вокруг аналогичной BOLA-механики.