CVSS 8.8, вектор AV:A - один из тех случаев, когда adjacent-network RCE в Android получает статус Critical от Google. И знаете, что самое обидное? Корневая причина - одна строчка кода. CVE-2026-0073 - логическая ошибка в функции
adbd_tls_verify_cert: EC-сертификат вместо RSA, ненулевой return value от EVP_PKEY_cmp() трактуется как "верификация пройдена". Без клика, без промпта, без установки приложения - shell от uid=2000 на Android 14, 15, 16 и 16-QPR2. При воспроизведении в лабе путь от mDNS-обнаружения до интерактивного shell занимает минуты, а не часы. Ниже - полный разбор CVE-2026-0073, root cause, вектор эксплуатации ADB daemon, воспроизведение и чеклист харденинга.Бизнес-логика атаки: зачем shell на Android через Wi-Fi
Прежде чем лезть в код - зачем атакующему ADB-shell на чужом Android? Shell-пользователь (uid=2000) - не root, но это выход за пределы application sandbox. По данным Penligent, из SELinux-контекстаu:r:shell:s0 доступны: системные логи, состояние пакетов, исполнение команд через pm, am, settings, run-as, создание скриншотов и взаимодействие с системными сервисами. Для атакующего это извлечение корпоративных данных, учёток VPN, конфигураций MDM и использование устройства как pivot-точки для lateral movement. Подробнее - в нашем обзоре пентест мобильных приложений.Целевые сценарии для Android zero-click атаки:
- Корпоративный офис, конференция, отель - атакующий подключается к общему Wi-Fi, обнаруживает устройства с wireless debugging через mDNS, эксплуатирует CVE-2026-0073 и получает плацдарм внутри периметра
- Android-устройства в режиме киоска - POS-терминалы, цифровые вывески, полевые планшеты. По данным DecryptionDigest, эти устройства часто работают в фиксированных сетях с предсказуемыми адресами и включёнными диагностическими сервисами
- BYOD - персональные Android-устройства сотрудников в корпоративном Wi-Fi, где обновления отстают от бюллетеня на недели или месяцы. По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и устранением в организациях - 29 месяцев
Корневая причина CVE-2026-0073: type confusion в EVP_PKEY_cmp
NVD классифицирует уязвимость ADB Android 2026 как CWE-303 (Incorrect Implementation of Authentication Algorithm). За этим номером - инженерный дефект, который умещается в одну строку. Буквально.
Wireless ADB в Android 11+ использует TLS mutual authentication: при подключении хост предъявляет сертификат, а
adbd проверяет, что публичный ключ из сертификата совпадает с ключом, сохранённым при pairing. Функция adbd_tls_verify_cert в auth.cpp вызывает OpenSSL-функцию EVP_PKEY_cmp()(https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_cmp.html) для сравнения хранимого RSA-ключа с ключом из клиентского TLS-сертификата.Согласно описанию PT Security,
EVP_PKEY_cmp() возвращает:1- ключи совпадают0- ключи не совпадают- Отрицательное значение (-1 или -2) - ошибка или несовместимые типы ключей
auth.cpp проверяет результат как boolean: ненулевое значение трактуется как "верификация пройдена". Атакующий предъявляет сертификат с ключом EC P-256 или Ed25519 вместо ожидаемого RSA. EVP_PKEY_cmp() возвращает отрицательное значение (типы несовместимы) - это не ноль, и код интерпретирует его как успешную проверку.
C:
// Уязвимый паттерн в auth.cpp (концептуальная реконструкция)
int result = EVP_PKEY_cmp(stored_rsa_key, client_cert_key);
if (result) { // -1 != 0, значит "совпадение"
return AUTH_SUCCESS;
}
// Корректная реализация: if (result == 1)adbd входит в Project Mainline как APEX-модуль com.android.adbd (Android 11+), что позволяет Google доставлять патч через Google Play system updates, минуя OEM-сертификацию. Это существенно сократило окно уязвимости по сравнению со стандартным процессом обновления через вендоров.Дополнительный вектор, зафиксированный PT Security: помимо authentication bypass, есть отдельные сведения о memory corruption в логике парсинга пакетов при mDNS/SSDP-обнаружении - integer underflow в проверке границ сервисных пакетов может привести к heap-based buffer overflow и удалённому выполнению кода Android. Это отдельная проблема от основного обхода аутентификации, но она расширяет поверхность атаки.
Протокол wireless ADB и точка отказа аутентификации
Для пентестера критично понимать, на каком уровне протокола происходит ADB exploit. Wireless debugging в Android 11+ - не "ADB на TCP 5555" из эпохи Android 4, где аутентификации не было вообще (и да, те времена вспоминаются с ностальгией). Современный протокол добавляет полноценный TLS-слой:- Устройство с включённым wireless debugging слушает на случайно назначенном TCP-порту и объявляет себя через mDNS (
_adb-tls-connect._tcp) - Хост устанавливает TCP-соединение к обнаруженному порту
- STLS-negotiation - апгрейд соединения до TLS
- Хост предъявляет клиентский TLS-сертификат
adbd_tls_verify_certсравнивает ключ из сертификата с хранилищем доверенных ключей - здесь CVE-2026-0073- При "успехе" - внутри TLS-туннеля начинается стандартное ADB-фреймирование
- Атакующий открывает shell-сервис и получает uid=2000
Старый режим
adb tcpip 5555 (без аутентификации) до сих пор встречается на кастомных прошивках и Android-based appliances: телевизорах, умных колонках, промышленных панелях. По данным Penligent, Android-based appliances зачастую уязвимее телефонов - обновления приходят с опозданием или не приходят вообще.Место CVE-2026-0073 в цепочке атаки
Уязвимость вписывается в kill chain мобильного пентеста Android. Вот как это выглядит на практике:
Initial Access - External Remote Services (T1133): подключение к ADB-порту из adjacent-сети. Для устройств с постоянным Wi-Fi - ещё и persistence. Также применим Exploitation of Remote Services (T1210) при pivot через скомпрометированное устройство.
Execution - Unix Shell (T1059.004): интерактивный shell после обхода аутентификации. Native API (T1106): через ADB доступны системные API для установки пакетов, управления процессами и сервисами.
Discovery - System Information Discovery (T1082):
getprop, dumpsys, pm list packages дают полную картину устройства - версию ОС, патч-левел, список приложений, конфигурацию сети.Privilege Escalation - Exploitation for Privilege Escalation (T1068): shell-доступ (uid=2000) открывает путь к local privesc через kernel-уязвимости или misconfiguration.
Что предшествует: разведка сети -
nmap/masscan по TCP 5555 и высокому диапазону портов, mDNS-browse для обнаружения wireless debugging. Что следует: установка backdoor APK через adb install -r, извлечение данных, pivot в корпоративную сеть через VPN-конфигурации или корпоративные сертификаты, доступные из shell-контекста.Предусловия и ограничения эксплуатации ADB daemon
Эта Android zero-click RCE уязвимость - не magic button для любого устройства. Вот конкретные границы.Работает если:
- Android 14, 15, 16 или 16-QPR2 без security patch level 2026-05-01
- Wireless debugging включён в Developer Options
- Атакующий в той же L2-сети (Wi-Fi, Ethernet bridge) или в пределах беспроводной досягаемости
- TCP-порт ADB не заблокирован MDM-политикой или firewall
- Wireless debugging выключен (по умолчанию отключён на потребительских устройствах - и это спасает большинство)
- Client isolation активна на Wi-Fi AP (блокирует L2-взаимодействие)
- Устройство обновлено до patch level 2026-05-01 или новее
- Developer options отключены через EMM-политику
- Устройство за NAT без прямого L2-доступа к порту
| Параметр | Значение |
|---|---|
| CVSS | 8.8 HIGH (Google severity: Critical) |
| Доступ | Adjacent network only (AV:A), не internet-wide |
| Привилегии | Не требуются (PR:N) |
| User interaction | Не требуется (UI:N) |
| Результат | shell uid=2000, не root |
| EPSS | 0.0054, percentile 0.42 (ниже медианы) |
| CISA SSVC | Track (exploitation: none на момент оценки) |
| Автоматизируемость | Нет (требуется adjacent-позиция) |
CISA классифицирует decision как Track с пометкой exploitation: none и automatable: no. Массовой эксплуатации на момент оценки зафиксировано не было. Но на GitHub уже опубликовано несколько PoC: SecTestAnnaQuinn/CVE-2026-0073-Android-adbd-authentication-bypass-POC (79 звёзд), adityatelange/poc-CVE-2026-0073 (51 звезда), MartinPSDev/CVE-2026-0073-Android-ADBD-bypass-POC (18 звёзд) - последний описывает type confusion через EC/Ed25519 ключи. Публичные PoC с подробным описанием вектора снижают порог входа, так что "exploitation: none" - это вопрос времени.
Воспроизведение Android zero-click атаки в лаборатории
Требования к окружению
- Целевое устройство: Android 14+ с включённым wireless debugging (физическое устройство или AOSP-эмулятор)
- Хост атакующего: GNU/Linux (Kali/Ubuntu 22.04+), пакеты
adb,nmap,openssl, Python 3.8+ - RAM: 8 ГБ минимум при использовании эмулятора, 4 ГБ - для работы с физическим устройством
- Сеть: оба устройства в одной L2-подсети. Рекомендуется отдельный Wi-Fi AP без выхода в интернет для полной изоляции
- Правовой контекст: только собственные устройства в изолированной лабораторной среде
Шаг 1: обнаружение целей
Wireless ADB анонсирует себя через mDNS. Обнаружение - через mDNS-browse или прямое сканирование TCP-портов. Modern wireless debugging использует случайный порт из высокого диапазона, но старый добрый 5555 по-прежнему встречается на устройствах сadb tcpip.
Bash:
# mDNS-обнаружение wireless debugging сервисов
avahi-browse -r _adb-tls-connect._tcp
# Сканирование подсети на ADB-порты
nmap -sV -p 5555,37000-44000 --open 192.168.1.0/24Шаг 2: подготовка EC-сертификата
Суть эксплуатации ADB daemon - предъявить сертификат с EC-ключом вместо RSA. Самоподписанный EC P-256 сертификат генерируется стандартными средствами OpenSSL. Публичные PoC (adityatelange/poc-CVE-2026-0073, MartinPSDev/CVE-2026-0073-Android-ADBD-bypass-POC) автоматизируют весь процесс: генерация ключа -> TCP-соединение -> STLS -> TLS handshake с EC-сертификатом -> ADB shell.Шаг 3: эксплуатация
PoC устанавливает TCP-соединение с обнаруженным портом, выполняет STLS-negotiation, предъявляет EC-сертификат. Дефектная проверка вadbd_tls_verify_cert возвращает ненулевое значение - и PoC получает полноценную авторизованную ADB-сессию. Вся магия в том, что -1 != 0, а значит if (result) срабатывает.Шаг 4: валидация доступа
Bash:
# Проверка контекста (пример для демонстрации концепции)
id
# uid=2000(shell) gid=2000(shell) context=u:r:shell:s0
getprop ro.build.version.security_patch
# Если вывод < 2026-05-01 - устройство уязвимо
pm list packages -3
# Список установленных сторонних приложенийscreencap, установка APK без промптов пользователю. Для перехода к privilege escalation - анализ ядра и системных компонентов на дополнительные уязвимости через run-as для debuggable-приложений.Обнаружение эксплуатации и харденинг ADB daemon
Сетевые сигналы для SOC
- TCP-соединения к портам wireless ADB из подсетей без легитимных dev-станций - аномалия
- mDNS-запросы к
_adb-tls-connect._tcpиз пользовательских VLAN - красный флаг - На устройстве:
logcatфиксирует ADB-подключения. Коннекты от неавторизованных MAC/IP при отсутствии записи о pairing - индикатор компрометации - Для SIEM-корреляции: новое ADB-соединение + TLS client certificate с EC/Ed25519 вместо RSA + отсутствие записи pairing в логах устройства
- Suricata/Zeek: детект ADB-протокола (сигнатура
CNXNпосле TLS handshake) на нестандартных портах
Ограничения детектирования
TLS-туннель скрывает содержимое ADB-сессии от сетевых IDS - обнаружение возможно только по метаданным: факт TLS handshake на ADB-порту, тип ключа в client certificate (при наличии TLS inspection), аномальная длительность сессии. На уровне endpoint Android не генерирует push-уведомление при подключении через wireless ADB (в отличие от USB-отладки). Это системное ограничение детекта на стороне устройства, и с ним пока ничего не сделать.Чеклист харденинга для отчёта по мобильному пентесту
Готовый список действий - можно копировать в отчёт и отправлять администраторам MDM как есть:Одна строка кода -
if (result) вместо if (result == 1) - обнулила весь механизм аутентификации wireless ADB на четырёх мажорных версиях Android. Не сложная цепочка эксплойтов с обходом ASLR, не sandbox escape через десять CVE. Классическая type confusion при интерпретации return value - ошибка, которую статический анализатор или грамотный code review поймали бы до мержа.Для меня этот кейс - аргумент в давнем споре: стоит ли бесконечно инвестировать в навороченные runtime-защиты (SELinux, seccomp, sandbox), если базовая логика аутентификации ломается на уровне оператора if? SELinux ограничил blast radius до uid=2000 вместо root - и это реально сработало. Но факт, что bypass прошёл мимо всех ревью в AOSP и затронул миллиарды устройств, говорит о системной проблеме не в Android, а в подходе к верификации auth-кода. Мы привыкли искать use-after-free, race condition, JIT-баги - а реальные critical CVE возникают из-за того, что инженер не прочитал документацию OpenSSL на
EVP_PKEY_cmp().В практике мобильного пентеста это смещает приоритеты: прежде чем гнаться за kernel exploit, проверь, не включён ли wireless debugging на целевом устройстве и какой на нём patch level. Зачастую этого достаточно.
Последнее редактирование модератором:
