m00ddy/cve-2026-0073-android-client-tls-auth-bypasstraduciendo exploit original de python a C
CVE‑2026‑0073 es un error lógico en el demonio ADB de Android (adbd) que permite a un atacante eludir la autenticación mutua TLS y abrir un shell remoto en un dispositivo que tenga la depuración inalámbrica habilitada y que se haya emparejado con cualquier ordenador al menos una vez. La causa raíz es una única API mal utilizada: el valor de retorno de EVP_PKEY_cmp() de OpenSSL se trata como un booleano en lugar de un resultado de tres valores.
cuando habilitamos la depuración inalámbrica desde los ajustes de desarrollador de Android, el dispositivo inicia una instancia de adbd que escucha en un puerto TCP aleatorio.
Nota: esta función se introdujo a partir de Android 11.
el protocolo tiene dos fases:
adbd exige que el cliente presente un certificadoadbd extrae la clave pública de ese certificado/data/misc/adb/adb_keys. las claves se colocan allí durante emparejamientos anteriores (el exploit requiere que haya al menos una clave aquí)shell
la comparación de claves se realiza con EVP_PKEY_cmp(key1, key2) de OPENSSL, que devuelveen el archivo daemon/auth.cpp la función vulnerable adb_tls_verify_cert() tiene un aspecto similar a este:
int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {
authorised = true;
}
dado que if(cmp) devuelve true mientras cmp sea distinto de cero, un valor de retorno de -1 de EVP_PKEY_cmp() conduce a la autorización. esto significa que, como la clave almacenada es RSA, cuando el cliente presenta un certificado EC o ed25519, la función devuelve -1 y el atacante obtiene acceso autorizado.
objetivo: un dispositivo Android con la depuración inalámbrica habilitada y al menos una clave RSA en su almacén de claves (se ha emparejado una vez, por cualquier persona).
handshake en claro: el atacante se conecta al puerto TCP de adbd e intercambia CNXN/STLS.
handshake TLS con certificado EC: el atacante genera una clave efímera EC P‑256 y un certificado autofirmado. esta clave no es RSA deliberadamente.
comparación defectuosa: EVP_PKEY_cmp(RSA, EC) devuelve ‑1 → if (cmp) es true → adbd marca el transporte como autorizado.
post‑TLS: el atacante evita enviar un CNXN de host (que restablecería el transporte) y abre directamente un flujo shell: con una ventana delayed_ack grande.
Resultado: shell remoto como el usuario shell, sin interacción del usuario, sin notificación y sin necesidad de poseer ninguna clave privada legítima.
El script de Python requiere un intérprete de python 3 y la biblioteca cryptography instalados en la máquina del atacante. Una implementación en C compila a un binario independiente sin dependencias externas más allá del OpenSSL/libssl del sistema, que está presente en prácticamente todos los sistemas linux por defecto. Esto reduce drásticamente la barrera para su despliegue. Además, un programa en C puede compilarse de forma cruzada para cualquier arquitectura de destino (x86_64, ARM, MIPS). Esto significa que el exploit podría compilarse y ejecutarse directamente en dispositivos integrados como routers, Raspberry Pis, o incluso otro dispositivo Android que actúe como atacante, sin necesidad de entorno python. Y un binario C compilado puede ser despojado de símbolos, empaquetado (UPX), y es opaco sin un desensamblador, lo que lo hace más sigiloso que un script de python.
ejecutando el exploit: proporciona la IP y el PUERTO de la interfaz de depuración inalámbrica y tendrás un shell en el dispositivo.
docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>
abriendo una calculadora
am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator
Se utilizó un LLM para traducir el exploit de python a C, el exploit original está aquí. la traducción no fue correcta 1:1 y nos enfrentamos a muchos problemas, por lo que fue necesario un bucle de análisis de código y charlas de ida y vuelta para corregir errores en la traducción y llegar a un exploit completo en funcionamiento.