Evil Twin EAP-TLS

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

EAP-TLS è la scelta “sicura” comune per WPA2/3-Enterprise, ma due debolezze pratiche emergono regolarmente durante le valutazioni:

  • Unauthenticated identity leakage: l’outer EAP-Response/Identity viene inviato in chiaro prima che venga stabilito qualsiasi tunnel TLS, quindi i veri nomi utente di dominio spesso leak over the air.
  • Broken client server-validation: se il supplicant non verifica rigorosamente il certificato del server RADIUS (o permette agli utenti di ignorare gli avvisi), un rogue AP con un certificato self-signed può comunque far connettere le vittime – trasformando mutual TLS in one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP effettua uno scambio di identità prima che TLS inizi. Se il client usa il vero nome utente di dominio come identità esterna, chiunque nel range RF può raccoglierlo senza autenticarsi.

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]"

Impatto: raccolta rapida di username senza autenticazione → alimenta password spraying, phishing, correlazione degli account. Peggio quando gli username corrispondono agli indirizzi email.

TLS 1.3 privacy vs meccaniche di downgrade

TLS 1.3 cripta i certificati client e la maggior parte dei metadati dell’handshake, quindi quando un supplicant veramente negozia TLS 1.3, un Evil Twin non può apprendere passivamente il certificato/identità del client. Molte stack enterprise permettono ancora TLS 1.2 per compatibilità; RFC 9190 avverte che un rogue AP può offrire solo suite static-RSA TLS 1.2 per forzare un fallback e riesporre l’identità esterna (o perfino il certificato client) in chiaro in EAP-TLS.

Playbook offensivo (downgrade per esporre l’ID):

  • Compila hostapd-wpe con solo le suite static-RSA TLS 1.2 abilitate e TLS 1.3 disabilitato in openssl_ciphersuite / ssl_ctx_flags.
  • Annuncia l’SSID aziendale; quando la vittima avvia TLS 1.3, rispondi con un alert TLS e riavvia l’handshake in modo che il peer ritenti con TLS 1.2, rivelando la sua identitĂ  reale prima che la validazione del certificato abbia successo.
  • Abbinalo a force_authorized=1 in hostapd-wpe cosĂŹ il 4-way handshake si completa anche se client-auth fallisce, dandoti traffico a livello DHCP/DNS per phish o portal.

Toggle difensivo (cosa cercare durante un assessment):

  • hostapd/wpa_supplicant 2.10 ha aggiunto il supporto EAP-TLS sia per il server che per il peer per TLS 1.3 ma lo distribuisce disabilitato di default; abilitarlo sui client con phase1="tls_disable_tlsv1_3=0" elimina la finestra di downgrade.

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

Rogue AP che trasmettono l’SSID aziendale possono presentare qualsiasi certificato. Se il client:

  • non valida il certificato del server, o
  • chiede all’utente e permette la sovrascrittura di CA non attendibili/certificati autofirmati, allora EAP-TLS smette di essere mutuale. Un hostapd/hostapd-wpe modificato che salta la validazione del certificato client (es., SSL_set_verify(..., 0)) è sufficiente per mettere in piedi l’Evil Twin.

Nota rapida sull’infrastruttura Rogue

Su Kali recente, compila hostapd-wpe usando hostapd-2.6 (da https://w1.fi/releases/) e installa prima gli header legacy di OpenSSL:

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

Windows supplicant misconfig pitfalls (GUI/GPO)

Parametri chiave del profilo Windows EAP-TLS:

  • Verify the server’s identity by validating the certificate
  • Checked → la chain deve essere trusted; unchecked → qualsiasi self-signed cert viene accettato.
  • Connect to these servers
  • Empty → qualsiasi cert emesso da una CA trusted viene accettato; impostare la lista CN/SAN per pinning dei nomi RADIUS attesi.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Checked → gli utenti non possono fare click-through; unchecked → l’utente può fidarsi di una CA/cert non trusted e unirsi al rogue AP.

Risultati osservati:

  • Strict validation + no prompts → rogue cert rifiutato; Windows registra un evento e TLS fallisce (buon segnale di detection).
  • Validation + user prompt → accettazione da parte dell’utente = associazione Evil Twin riuscita.
  • No validation → associazione Evil Twin silente con qualsiasi cert.

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks