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

CVE‑2026‑0073 is a logic bug in Android’s ADB daemon (adbd) that allows an attacker to bypass TLS mutual authentication and open a remote shell on a device that has wireless debugging enabled and has been paired with any computer at least once. The root cause is a single misused API: the return value of OpenSSL’s EVP_PKEY_cmp() is treated as a Boolean instead of a three‑valued result. ## Normal authentication flow with ADB wireless debugging when we enable wireless debugging from android developer settings, the device starts an `adbd` instance that listens on a random TCP port. Note: this feature was introduced in Android 11 onwards. the protocol has two phases: 1. cleartext negotiation: the host connects via TCP and exchanges a CNXN/STLS handshake to agree on upgrading to TLS. 2. TLS 1.3 mutual authentication: - server `adbd` requires the client to present a certificate - `adbd` extracts the public key from that certificate - it then compares the key against all authorized RSA keys stored in its `/data/misc/adb/adb_keys`. keys are placed there during previous pairings (the exploit requires at least one key to be here) - if the keys match, the handshake succeeds and the host can send shell commads as the `shell` user the key comparison is done using OPENSSL's `EVP_PKEY_cmp(key1, key2)`, which returns - 1 --> keys are equal - 0 --> keys are not equal - -1 --> key types differ, or error occured ## The bug in the file `daemon/auth.cpp` the vulnerable function `adb_tls_verify_cert()` looks something like this: int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key); if (cmp) { authorised = true; } ## Attack sequence 1. target: an android device with wireless debugging enabled and at least one RSA key in its keystore (it has been paired once, by anyone). 2. cleartext handshake: attacker connects to the adbd TCP port and exchanges CNXN/STLS. 3. TLS handshake with EC certificate: the attacker generates an ephemeral EC P‑256 key and a self‑signed certificate. this key is deliberately not RSA. 4. flawed comparison: `EVP_PKEY_cmp(RSA, EC)` returns ‑1 → `if (cmp)` is true → adbd marks the transport as authorised. 5. post‑TLS: The attacker avoids sending a host CNXN (which would reset the transport) and directly opens a `shell:` stream with a large `delayed_ack` window. Result: Remote shell as the shell user, with no user interaction, no notification, and no need to possess any legitimate private key. ## Why translating it to C? The Python script requires a python 3 interpreter and the `cryptography` library to be installed on the attacker machine. A C implementation compiles to a standalone binary with no external dependencies beyond the system's OpenSSL/libssl, which is present on virtually every linux system by default. This dramatically lowers the barrier to deployment. Furthermore, A C program can be cross-compiled for any target architecture (x86_64, ARM, MIPS). This means the exploit could be compiled and run directly on embedded devices like routers, Raspberry Pis, or even another android device acting as the attacker, with no python environment needed. And a compiled C binary can be stripped of symbols, packed (UPX), and is opaque without a disassembler which makes it stealthier than a python script. ## Demo running the exploit: provide the IP and PORT of the wireless debuggin interface and you have a shell on the device. docker build -t adb_bypass . docker run -it --network host adb_bypass popping a calc am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator ## Note on LLM usage LLM was used to translate the exploit from python to C, the original exploit is [here](https://github.com/SecTestAnnaQuinn/CVE-2026-0073-Android-adbd-authentication-bypass-POC). the translation wasn't correct 1:1 and we faced a lot of issues, therefore a loop of code analysis and back and forth chatting was necessary to fix bugs in the translation and arrive at a full running exploit.

标签：客户端加密