Evil Twin EAP-TLS

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

EAP-TLS jest powszechnym „bezpiecznym” wyborem dla WPA2/3-Enterprise, ale podczas testów regularnie ujawniają się dwie praktyczne słabości:

  • Unauthenticated identity leakage: zewnętrzne EAP-Response/Identity jest wysyłane w cleartext zanim zostanie zbudowany jakikolwiek tunel TLS, więc rzeczywiste nazwy użytkowników domeny często leak over the air.
  • Broken client server-validation: jeśli supplicant nie weryfikuje rygorystycznie certyfikatu serwera RADIUS (lub pozwala użytkownikom zaakceptować ostrzeżenia), złośliwy AP z self-signed cert może nadal onboard victims – zamieniając mutual TLS w one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP wymusza wymianę tożsamości przed rozpoczęciem TLS. Jeśli klient używa rzeczywistej nazwy użytkownika domeny jako swojej zewnętrznej tożsamości, każdy w zasięgu RF może ją zebrać bez uwierzytelniania.

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: szybkie, no-auth zbieranie username → napędza password spraying, phishing i account correlation. Gorzej, gdy usernames pokrywają się z adresami e-mail.

TLS 1.3 privacy vs downgrade games

TLS 1.3 szyfruje client certs i większość metadanych handshake, więc gdy supplicant rzeczywiście negocjuje TLS 1.3, Evil Twin nie może pasywnie poznać client certificate/identity. Wiele enterprise stacków wciąż dopuszcza TLS 1.2 dla kompatybilności; RFC 9190 ostrzega, że rogue AP może zaoferować tylko TLS 1.2 static-RSA suites, aby wymusić fallback i ponownie ujawnić outer identity (a nawet client cert) w cleartext EAP-TLS.

Offensive playbook (downgrade to leak ID):

  • Skompiluj hostapd-wpe z włączonymi tylko TLS 1.2 static RSA ciphers i z wyłączonym TLS 1.3 w openssl_ciphersuite / ssl_ctx_flags.
  • Advertise corporate SSID; gdy ofiara inicjuje TLS 1.3, odpowiedz TLS alert i zrestartuj handshake, aby peer spróbował ponownie z TLS 1.2, ujawniając swoją prawdziwą identity zanim cert validation powiedzie się.
  • Połącz to z force_authorized=1 w hostapd-wpe, aby 4-way handshake zakończył się nawet jeśli client-auth zawiedzie, dając Ci ruch na poziomie DHCP/DNS do phish lub portal.

Defensive toggle (what to look for during an assessment):

  • hostapd/wpa_supplicant 2.10 dodał wsparcie EAP-TLS dla server i peer dla TLS 1.3, ale jest ono wyłączone domyślnie; włączenie go na klientach za pomocą phase1="tls_disable_tlsv1_3=0" usuwa okno dla downgrade’a.

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

Rogue APs broadcastujące corporate SSID mogą przedstawić dowolny certificate. Jeśli klient:

  • doesn’t validate server cert, lub
  • prompts the user i pozwala nadpisać untrusted CAs/self-signed certs, to EAP-TLS przestaje być mutual. Zmodyfikowany hostapd/hostapd-wpe, który pomija client-cert validation (np. SSL_set_verify(..., 0)), wystarczy do postawienia Evil Twin.

Rogue infra quick note

Na nowszym Kali skompiluj hostapd-wpe używając hostapd-2.6 (z https://w1.fi/releases/) i najpierw zainstaluj legacy OpenSSL headers:

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

Pułapki błędnej konfiguracji supplicanta Windows (GUI/GPO)

Kluczowe ustawienia profilu EAP-TLS w Windows:

  • Verify the server’s identity by validating the certificate
  • Zaznaczone → łańcuch musi być zaufany; niezaznaczone → akceptowany jest dowolny certyfikat samopodpisany.
  • Connect to these servers
  • Puste → akceptowany jest dowolny certyfikat od zaufanego CA; ustaw listę CN/SAN, aby przypiąć oczekiwane nazwy RADIUS.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Zaznaczone → użytkownicy nie mogą klikać dalej; niezaznaczone → użytkownik może zaufać niezaufanemu CA/certyfikatowi i połączyć się z rogue AP.

Zaobserwowane skutki:

  • Strict validation + no prompts → certyfikat rogue odrzucony; Windows loguje zdarzenie i TLS nie powodzi się (dobry sygnał detekcji).
  • Validation + user prompt → akceptacja przez użytkownika = udana asocjacja z Evil Twin.
  • No validation → cicha asocjacja z Evil Twin z dowolnym certyfikatem.

Źródła

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks