m00ddy/cve-2026-0073-android-client-tls-auth-bypassTraduzione dell'exploit Python originale in C
CVE‑2026‑0073 è un bug logico nel demone ADB di Android (adbd) che consente a un attaccante di bypassare l'autenticazione reciproca TLS e aprire una shell remota su un dispositivo che ha il debug wireless abilitato ed è stato accoppiato con qualsiasi computer almeno una volta. La causa principale è una singola API usata in modo improprio: il valore di ritorno di EVP_PKEY_cmp() di OpenSSL viene trattato come un booleano invece che come un risultato a tre valori.
Quando abilitiamo il debug wireless dalle impostazioni sviluppatore di Android, il dispositivo avvia un'istanza adbd che rimane in ascolto su una porta TCP casuale.
Nota: questa funzionalità è stata introdotta a partire da Android 11.
il protocollo ha due fasi:
adbd richiede che il client presenti un certificatoadbd estrae la chiave pubblica da quel certificato/data/misc/adb/adb_keys. le chiavi vengono inserite lì durante gli accoppiamenti precedenti (l'exploit richiede che qui sia presente almeno una chiave)shellil confronto delle chiavi viene eseguito usando EVP_PKEY_cmp(key1, key2) di OPENSSL, che restituisce
nel file daemon/auth.cpp la funzione vulnerabile adb_tls_verify_cert() assomiglia a questo:
int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {
authorised = true;
}
poiché if(cmp) restituisce vero finché cmp è diverso da zero, un valore di ritorno pari a -1 da EVP_PKEY_cmp() porta all'autorizzazione. questo significa che, poiché la chiave memorizzata è RSA, quando il client presenta un certificato EC o ed25519, la funzione restituisce -1 e l'attaccante ottiene accesso autorizzato.
target: un dispositivo Android con debug wireless abilitato e almeno una chiave RSA nel suo keystore (è stato accoppiato una volta, da chiunque).
handshake in chiaro: l'attaccante si connette alla porta TCP di adbd e scambia CNXN/STLS.
handshake TLS con certificato EC: l'attaccante genera una chiave EC P‑256 effimera e un certificato autofirmato. questa chiave è deliberatamente non RSA.
confronto difettoso: EVP_PKEY_cmp(RSA, EC) restituisce ‑1 → if (cmp) è vero → adbd contrassegna il transport come autorizzato.
post‑TLS: l'attaccante evita di inviare una CNXN host (che resetterebbe il transport) e apre direttamente uno stream shell: con una grande finestra delayed_ack.
Risultato: shell remota come utente shell, senza interazione da parte dell'utente, senza notifiche e senza bisogno di possedere alcuna chiave privata legittima.
Lo script Python richiede un interprete Python 3 e la libreria cryptography installata sulla macchina dell'attaccante. Un'implementazione in C viene compilata in un binario autonomo senza dipendenze esterne oltre a OpenSSL/libssl di sistema, che è presente praticamente su ogni sistema Linux per impostazione predefinita. Questo abbassa notevolmente la barriera alla distribuzione. Inoltre, un programma C può essere cross-compilato per qualsiasi architettura di destinazione (x86_64, ARM, MIPS). Questo significa che l'exploit potrebbe essere compilato ed eseguito direttamente su dispositivi embedded come router, Raspberry Pi o persino un altro dispositivo Android che funge da attaccante, senza bisogno di un ambiente Python. E un binario C compilato può essere privato dei simboli, compattato (UPX) ed è opaco senza un disassembler, il che lo rende più furtivo di uno script Python.
esecuzione dell'exploit: fornisci IP e PORTA dell'interfaccia di debug wireless e ottieni una shell sul dispositivo.
docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>
far apparire una calcolatrice
am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator
È stato usato un LLM per tradurre l'exploit da Python a C; l'exploit originale è qui. la traduzione non era corretta 1:1 e abbiamo affrontato molti problemi; per questo è stato necessario un ciclo di analisi del codice e di conversazione avanti e indietro per correggere i bug nella traduzione e arrivare a un exploit completo e funzionante.