m00ddy/cve-2026-0073-android-client-tls-auth-bypasstraduction de l'exploit python original en C
CVE‑2026‑0073 est un bug logique dans le démon ADB d'Android (adbd) qui permet à un attaquant de contourner l'authentification mutuelle TLS et d'ouvrir un shell distant sur un appareil dont le débogage sans fil est activé et qui a été appairé avec un ordinateur au moins une fois. La cause racine est une seule API mal utilisée : la valeur de retour de EVP_PKEY_cmp() d'OpenSSL est traitée comme un booléen au lieu d'un résultat à trois valeurs.
Lorsque nous activons le débogage sans fil depuis les paramètres développeur Android, l'appareil démarre une instance adbd qui écoute sur un port TCP aléatoire.
Remarque : cette fonctionnalité a été introduite à partir d'Android 11.
le protocole comporte deux phases :
adbd exige que le client présente un certificatadbd extrait la clé publique de ce certificat/data/misc/adb/adb_keys. Les clés y sont placées lors des appairages précédents (l'exploit nécessite qu'au moins une clé s'y trouve)shell
la comparaison des clés est effectuée à l'aide de EVP_PKEY_cmp(key1, key2) d'OpenSSL, qui retournedans le fichier daemon/auth.cpp, la fonction vulnérable adb_tls_verify_cert() ressemble à ceci :
int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {
authorised = true;
}
étant donné que if(cmp) est vrai tant que cmp est non nul, une valeur de retour de -1 de EVP_PKEY_cmp() conduit à l'autorisation. Cela signifie que puisque la clé stockée est RSA, lorsque le client présente un certificat EC ou ed25519, la fonction retourne -1 et l'attaquant obtient un accès autorisé.
cible : un appareil Android avec le débogage sans fil activé et au moins une clé RSA dans son trousseau de clés (il a été appairé une fois, par n'importe qui).
poignée de main en texte clair : l'attaquant se connecte au port TCP adbd et échange CNXN/STLS.
poignée de main TLS avec certificat EC : l'attaquant génère une clé EC P‑256 éphémère et un certificat auto-signé. Cette clé est délibérément non-RSA.
comparaison erronée : EVP_PKEY_cmp(RSA, EC) retourne -1 → if (cmp) est vrai → adbd marque le transport comme autorisé.
post-TLS : l'attaquant évite d'envoyer un CNXN hôte (qui réinitialiserait le transport) et ouvre directement un flux shell: avec une grande fenêtre delayed_ack.
Résultat : Shell distant en tant qu'utilisateur shell, sans interaction utilisateur, sans notification et sans besoin de posséder une clé privée légitime.
Le script Python nécessite un interpréteur Python 3 et la bibliothèque cryptography installée sur la machine attaquante. Une implémentation en C se compile en un binaire autonome sans dépendances externes au-delà de OpenSSL/libssl du système, présent sur pratiquement tous les systèmes Linux par défaut. Cela abaisse considérablement la barrière de déploiement. De plus, un programme C peut être cross-compilé pour n'importe quelle architecture cible (x86_64, ARM, MIPS). Cela signifie que l'exploit pourrait être compilé et exécuté directement sur des appareils embarqués comme des routeurs, des Raspberry Pi, ou même un autre appareil Android agissant comme attaquant, sans environnement Python nécessaire. Et un binaire C compilé peut être dédépouillé de ses symboles, compressé (UPX), et est opaque sans désassembleur, ce qui le rend plus furtif qu'un script Python.
exécution de l'exploit : fournissez l'IP et le PORT de l'interface de débogage sans fil et vous obtenez un shell sur l'appareil.
docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>
ouverture d'une calculatrice
am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator
Un LLM a été utilisé pour traduire l'exploit de Python vers C, l'exploit original est ici. La traduction n'était pas correcte 1:1 et nous avons rencontré de nombreux problèmes, donc une boucle d'analyse de code et d'échanges aller-retour a été nécessaire pour corriger les bugs de la traduction et aboutir à un exploit fonctionnel complet.