Evil Twin EAP-TLS

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

EAP-TLS est le choix “secure” courant pour WPA2/3-Enterprise, mais deux faiblesses pratiques apparaissent régulièrement lors des évaluations :

  • Unauthenticated identity leakage: la outer EAP-Response/Identity est envoyée en clair avant que tout tunnel TLS soit établi, donc les vrais noms d’utilisateur de domaine often leak over the air.
  • Broken client server-validation: si le supplicant ne vérifie pas strictement le certificat du serveur RADIUS (ou permet aux utilisateurs de cliquer pour passer outre les avertissements), un rogue AP avec un self-signed cert peut quand même onboarder des victimes — transformant mutual TLS en one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP initie un échange d’identité avant le démarrage du TLS. Si le client utilise le vrai nom d’utilisateur de domaine comme outer identity, n’importe qui dans la portée RF peut le harvest sans s’authentifier.

Passive harvest workflow

# 1) Park on the right channel/BSSID
airodump-ng -i $IFACE -c $CHAN --bssid $BSSID

# 2) Decode EAP frames and extract identities
# Trigger a client connection (e.g., your phone) to see the leak
tshark -i "$IFACE" -Y eap -V | grep "Identity: *[a-z]\|*[A-Z]\|*[0-9]"

Impact : collecte rapide de username no-auth → alimente password spraying, phishing, corrélation de comptes. Pire lorsque les usernames correspondent aux adresses email.

Confidentialité TLS 1.3 vs jeux de downgrade

TLS 1.3 chiffre les certificats client et la plupart des métadonnées du handshake, donc quand un supplicant négocie réellement TLS 1.3, un Evil Twin ne peut pas apprendre passivement le certificat/l’identité du client. Beaucoup de stacks d’entreprise autorisent encore TLS 1.2 pour compatibilité ; le RFC 9190 avertit qu’un rogue AP peut proposer seulement des suites static-RSA TLS 1.2 pour forcer un fallback et ré-exposer l’identité externe (ou même le certificat client) en clair dans EAP-TLS.

Offensive playbook (downgrade to leak ID):

  • Compiler hostapd-wpe avec seulement les chiffrements static-RSA TLS 1.2 activés et TLS 1.3 désactivé dans openssl_ciphersuite / ssl_ctx_flags.
  • Advertise the corporate SSID ; quand la victime initie TLS 1.3, répondre avec une alerte TLS et redémarrer le handshake pour que le peer retente en TLS 1.2, révélant sa véritable identité avant que la validation du cert ne réussisse.
  • Associez cela avec force_authorized=1 dans hostapd-wpe pour que le 4-way handshake se termine même si client-auth échoue, vous donnant du trafic au niveau DHCP/DNS pour phish ou portal.

Défensive toggle (ce qu’il faut vérifier pendant une évaluation) :

  • hostapd/wpa_supplicant 2.10 a ajouté le support EAP-TLS côté serveur et pair pour TLS 1.3 mais l’expédie désactivé par défaut ; l’activer sur les clients avec phase1="tls_disable_tlsv1_3=0" supprime la fenêtre de downgrade.

Réalités TLS 1.3 en 2024–2025

  • FreeRADIUS 3.0.23+ accepte EAP-TLS 1.3, mais les clients posent encore problème (Windows 11 n’a pas de session resumption EAP-TLS 1.3, le support Android varie), donc de nombreux déploiements verrouillent tls_max_version = "1.2" pour la stabilité.
  • Windows 11 active EAP-TLS 1.3 par défaut (22H2+), pourtant des reprises échouées et des stacks RADIUS instables forcent souvent un fallback vers TLS 1.2.
  • L’échange de clés RSA pour TLS 1.2 est en cours de dépréciation ; OpenSSL 3.x supprime les suites static-RSA au niveau de sécurité ≥2, donc un rogue TLS 1.2 static-RSA nécessite OpenSSL 1.1.1 avec @SECLEVEL=0 ou une version antérieure.

Practical version steering during an engagement

  • Forcer TLS 1.2 sur le rogue (to leak identities):
# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0   # requires OpenSSL 1.1.1
disable_tlsv1_3=1
  • Tester l’intolérance TLS du client : lancez deux rogues – un annonçant TLS 1.3-only (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) et un TLS 1.2-only. Les clients qui ne rejoignent que la BSS 1.2 sont susceptibles d’être rétrogradés.
  • Surveillez les fallback dans les captures : filtrez dans Wireshark pour tls.handshake.version==0x0303 après un ClientHello initial avec supported_versions contenant 0x0304 ; les victimes qui retentent 0x0303 exposent à nouveau leur outer ID.

Evil Twin via broken server validation (“mTLS?”)

Les Rogue APs diffusant le SSID corporate peuvent présenter n’importe quel certificat. Si le client :

  • ne valide pas le certificat serveur, ou
  • invite l’utilisateur et permet l’override des CAs non fiables/certificats auto-signés, alors EAP-TLS cesse d’être mutuel. Un hostapd/hostapd-wpe modifié qui saute la validation du certificat client (par ex., SSL_set_verify(..., 0)) suffit à déployer l’Evil Twin.

Note rapide sur l’infra rogue

Sur les Kali récents, compilez hostapd-wpe en utilisant hostapd-2.6 (from https://w1.fi/releases/) et installez d’abord les en-têtes OpenSSL legacy :

apt-get install libssl1.0-dev
# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert

Pièges de mauvaise configuration du supplicant Windows (GUI/GPO)

Principaux réglages du profil EAP-TLS sous Windows :

  • Verify the server’s identity by validating the certificate
  • Cochée → la chaîne doit être de confiance ; décochée → tout certificat auto-signé est accepté.
  • Connect to these servers
  • Vide → tout certificat émis par une CA de confiance est accepté ; renseigner la liste CN/SAN pour fixer les noms RADIUS attendus.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Cochée → les utilisateurs ne peuvent pas passer outre ; décochée → l’utilisateur peut faire confiance à une CA/cert non fiable et rejoindre l’AP malveillant.

Résultats observés :

  • Strict validation + no prompts → certificat malveillant rejeté ; Windows journalise un événement et TLS échoue (bon signal de détection).
  • Validation + user prompt → acceptation par l’utilisateur = association Evil Twin réussie.
  • No validation → association silencieuse à un Evil Twin avec n’importe quel certificat.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks