CVE-2026-0073-Android-client-TLS-auth-bypass

CVE‑2026‑0073 ist ein Logikfehler im ADB-Daemon (adbd) von Android, der es einem Angreifer ermöglicht, die gegenseitige TLS-Authentifizierung zu umgehen und eine Remote-Shell auf einem Gerät zu öffnen, auf dem drahtloses Debugging aktiviert ist und das mindestens einmal mit einem beliebigen Computer gekoppelt wurde. Die Ursache liegt in einer einzigen falsch verwendeten API: Der Rückgabewert von OpenSSLs EVP_PKEY_cmp() wird als boolescher Wert behandelt, obwohl es sich um ein dreiwertiges Ergebnis handelt.

Normaler Authentifizierungsablauf beim drahtlosen ADB-Debugging

Wenn wir drahtloses Debugging in den Android-Entwickleroptionen aktivieren, startet das Gerät eine adbd-Instanz, die auf einem zufälligen TCP-Port lauscht. Hinweis: Diese Funktion wurde mit Android 11 eingeführt.

Das Protokoll hat zwei Phasen:

1. Klartext-Aushandlung: Der Host verbindet sich über TCP und führt einen CNXN/STLS-Handshake durch, um das Upgrade auf TLS zu vereinbaren.
2. TLS-1.3-gegenseitige Authentifizierung:
   • Der Server adbd verlangt, dass der Client ein Zertifikat vorlegt
   • adbd extrahiert den öffentlichen Schlüssel aus diesem Zertifikat
   • Anschließend vergleicht es den Schlüssel mit allen autorisierten RSA-Schlüsseln, die in /data/misc/adb/adb_keys gespeichert sind. Schlüssel werden dort bei früheren Kopplungen abgelegt (der Exploit setzt voraus, dass sich dort mindestens ein Schlüssel befindet)
   • Wenn die Schlüssel übereinstimmen, ist der Handshake erfolgreich und der Host kann Shell-Befehle als Benutzer shell senden Der Schlüsselvergleich erfolgt mit OpenSSLs EVP_PKEY_cmp(key1, key2), das Folgendes zurückgibt:

• 1 --> Schlüssel sind gleich
• 0 --> Schlüssel sind nicht gleich
• -1 --> Schlüsseltypen unterscheiden sich, oder ein Fehler ist aufgetreten

Der Fehler

In der Datei daemon/auth.cpp sieht die anfällige Funktion adb_tls_verify_cert() ungefähr so aus:

int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {     
    authorised = true;
}

Da if(cmp) wahr ist, solange cmp ungleich Null ist, führt ein Rückgabewert von -1 von EVP_PKEY_cmp() zur Autorisierung. Das bedeutet, dass die Funktion, da der gespeicherte Schlüssel RSA ist, -1 zurückgibt, wenn der Client ein EC- oder ed25519-Zertifikat vorlegt, und der Angreifer erhält autorisierten Zugriff.

Angriffsablauf

1. Ziel: Ein Android-Gerät mit aktiviertem drahtlosem Debugging und mindestens einem RSA-Schlüssel im Schlüsselspeicher (es wurde einmal von irgendjemandem gekoppelt).

2. Klartext-Handshake: Der Angreifer verbindet sich mit dem adbd-TCP-Port und tauscht CNXN/STLS aus.

3. TLS-Handshake mit EC-Zertifikat: Der Angreifer erzeugt einen ephemeren EC-P‑256-Schlüssel und ein selbstsigniertes Zertifikat. Dieser Schlüssel ist bewusst kein RSA-Schlüssel.

4. Fehlerhafter Vergleich: EVP_PKEY_cmp(RSA, EC) gibt ‑1 zurück → if (cmp) ist wahr → adbd markiert den Transport als autorisiert.

5. Nach TLS: Der Angreifer sendet kein Host-CNXN (das den Transport zurücksetzen würde) und öffnet direkt einen shell:-Stream mit einem großen delayed_ack-Fenster.

Ergebnis: Remote-Shell als Benutzer shell, ohne Benutzerinteraktion, ohne Benachrichtigung und ohne den Besitz eines legitimen privaten Schlüssels.

Warum in C übersetzen?

Das Python-Skript benötigt einen Python-3-Interpreter und die Bibliothek cryptography, die auf dem Angreifer-Rechner installiert sein muss. Eine C-Implementierung wird zu einer eigenständigen Binärdatei kompiliert, die außer dem systemeigenen OpenSSL/libssl keine externen Abhängigkeiten benötigt – und das ist auf praktisch jedem Linux-System standardmäßig vorhanden. Das senkt die Hürde für den Einsatz erheblich. Darüber hinaus kann ein C-Programm für jede Zielarchitektur (x86_64, ARM, MIPS) cross-kompiliert werden. Das bedeutet, dass der Exploit direkt auf eingebetteten Geräten wie Routern, Raspberry Pis oder sogar einem anderen Android-Gerät, das als Angreifer fungiert, kompiliert und ausgeführt werden kann – ohne dass eine Python-Umgebung erforderlich ist. Außerdem kann eine kompilierte C-Binärdatei von Symbolen befreit, gepackt (UPX) werden und ist ohne einen Disassembler undurchsichtig, was sie unauffälliger macht als ein Python-Skript.

Demo

Exploit ausführen: Geben Sie die IP und den PORT des drahtlosen Debugging-Interfaces an, und Sie haben eine Shell auf dem Gerät.

docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>

Taschenrechner starten

am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator

Hinweis zur LLM-Nutzung

Ein LLM wurde verwendet, um den Exploit von Python nach C zu übersetzen; der ursprüngliche Exploit ist hier. Die Übersetzung war nicht 1:1 korrekt, und wir standen vor vielen Problemen. Daher war eine Schleife aus Codeanalyse und wiederholtem Hin und Her im Chat nötig, um Fehler in der Übersetzung zu beheben und zu einem vollständig lauffähigen Exploit zu gelangen.