Evil Twin EAP-TLS

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

EAP-TLS ist die gängige „sichere“ Wahl für WPA2/3-Enterprise, aber zwei praktische Schwachstellen treten bei Assessments regelmäßig auf:

  • Unauthenticated identity leakage: Die äußere EAP-Response/Identity wird im Klartext gesendet, bevor ein TLS-Tunnel aufgebaut ist, sodass echte Domain-Benutzernamen oft über die Luft leak.
  • Broken client server-validation: Wenn der supplicant das RADIUS-Serverzertifikat nicht strikt validiert (oder Benutzern erlaubt, Warnungen wegzuklicken), kann ein rogue AP mit einem self-signed cert trotzdem Opfer onboarden – und mutual TLS in one-way TLS verwandeln.

Unauthenticated EAP identity leakage / username enumeration

EAP führt einen Identitätsaustausch durch, bevor TLS startet. Wenn der Client den echten Domain-Benutzernamen als äußere Identität verwendet, kann jeder im RF-Bereich diesen ohne Authentifizierung abgreifen.

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

Auswirkung: schnelle, no-auth username-Sammlung → treibt password spraying, phishing und account correlation an. Schlimmer, wenn usernames mit email addresses übereinstimmen.

TLS 1.3 Privatsphäre vs Downgrade-Angriffe

TLS 1.3 verschlüsselt Client-Zertifikate und die meisten Handshake-Metadaten, sodass wenn ein supplicant tatsächlich TLS 1.3 aushandelt, ein Evil Twin passiv nicht das client certificate/identity erlernen kann. Viele Enterprise-Stacks erlauben aus Kompatibilitätsgründen weiterhin TLS 1.2; RFC 9190 warnt, dass ein rogue AP nur TLS 1.2 static-RSA-Suites anbieten kann, um ein Fallback zu erzwingen und die outer identity (oder sogar das Client-Zertifikat) im Klartext von EAP-TLS wieder offenzulegen.

Offensive playbook (downgrade to leak ID):

  • Kompiliere hostapd-wpe so, dass nur TLS 1.2 static RSA Ciphers aktiviert sind und TLS 1.3 in openssl_ciphersuite / ssl_ctx_flags deaktiviert ist.
  • Broadcaste das corporate SSID; wenn das Opfer TLS 1.3 initiiert, antworte mit einem TLS-Alert und starte den Handshake neu, sodass der Peer mit TLS 1.2 erneut versucht und seine echte Identity offenlegt, bevor die Zertifikats-Validierung erfolgreich ist.
  • Kombiniere das mit force_authorized=1 in hostapd-wpe, sodass der 4-way handshake abgeschlossen wird, selbst wenn client-auth fehlschlägt, und dir DHCP/DNS-Level-Traffic zum phishen oder für ein Portal liefert.

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

  • hostapd/wpa_supplicant 2.10 hat EAP-TLS-Server- und Peer-Unterstützung für TLS 1.3 hinzugefügt, liefert sie aber standardmäßig deaktiviert; das Aktivieren auf Clients mit phase1="tls_disable_tlsv1_3=0" schließt das Downgrade-Fenster.

TLS 1.3 Realitäten in 2024–2025

  • FreeRADIUS 3.0.23+ akzeptiert EAP-TLS 1.3, aber Clients brechen immer noch (Windows 11 hat keine EAP-TLS 1.3 session resumption, Android-Unterstützung variiert), daher setzen viele Deployments tls_max_version = "1.2" für Stabilität.
  • Windows 11 aktiviert EAP-TLS 1.3 standardmäßig (22H2+), dennoch erzwingen fehlgeschlagene Resumptions und instabile RADIUS-Stacks oft ein Fallback auf TLS 1.2.
  • RSA Key Exchange für TLS 1.2 wird deprecated; OpenSSL 3.x entfernt static-RSA-Suites bei security level ≥2, daher benötigt ein TLS 1.2 static-RSA rogue OpenSSL 1.1.1 mit @SECLEVEL=0 oder älter.

Praktische Versionssteuerung während eines Engagements

  • Erzwinge TLS 1.2 auf dem 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
  • Teste die TLS-Intoleranz von Clients: Starte zwei rogue APs – einen, der nur TLS 1.3 ausstrahlt (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) und einen, der nur TLS 1.2 anbietet. Clients, die nur dem 1.2 BSS beitreten, sind für ein Downgrade anfällig.
  • Auf Fallbacks in Captures achten: Filtere in Wireshark nach tls.handshake.version==0x0303 nach einem initialen ClientHello mit supported_versions, das 0x0304 enthält; Opfer, die 0x0303 erneut versuchen, leaken damit wieder ihre outer ID.

Evil Twin via fehlerhafte Server-Validierung (“mTLS?”)

Rogue APs, die das corporate SSID ausstrahlen, können beliebige Zertifikate präsentieren. Wenn der Client:

  • das Server-Zertifikat nicht validiert, oder
  • den Benutzer auffordert und das Überschreiben von untrusted CAs/self-signed certs zulässt, dann ist EAP-TLS nicht mehr mutual. Ein modifiziertes hostapd/hostapd-wpe, das die Client-Zertifikat-Validierung überspringt (z. B. SSL_set_verify(..., 0)), reicht aus, um den Evil Twin aufzusetzen.

Kurze Notiz zur Rogue-Infrastruktur

Auf aktuellem Kali: kompiliere hostapd-wpe mit hostapd-2.6 (von https://w1.fi/releases/) und installiere zuerst die legacy OpenSSL-Header:

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 – Fehlkonfigurationsfallen (GUI/GPO)

Wichtige Einstellungen im Windows EAP-TLS-Profil:

  • Verify the server’s identity by validating the certificate
  • Ausgewählt → die Kette muss vertraut sein; nicht ausgewählt → jedes selbstsignierte cert wird akzeptiert.
  • Connect to these servers
  • Leer → jedes cert von einer vertrauenswürdigen CA wird akzeptiert; CN/SAN-Liste setzen, um erwartete RADIUS-Namen zu pinnen.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Ausgewählt → Benutzer können nicht per Klick weitergehen; nicht ausgewählt → Benutzer kann einer nicht vertrauenswürdigen CA/cert vertrauen und dem rogue AP beitreten.

Beobachtete Ergebnisse:

  • Strict validation + no prompts → rogue cert abgelehnt; Windows protokolliert ein Ereignis und TLS schlägt fehl (gutes Erkennungssignal).
  • Validation + user prompt → Benutzerakzeptanz = erfolgreiche Evil Twin-Assoziation.
  • No validation → stille Evil Twin-Assoziation mit jedem cert.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks