Evil Twin EAP-TLS

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

EAP-TLS es la opción “segura” común para WPA2/3-Enterprise, pero dos debilidades prácticas aparecen con regularidad durante las evaluaciones:

  • Unauthenticated identity leakage: la EAP-Response/Identity externa se envía en texto claro antes de que se establezca cualquier túnel TLS, por lo que los nombres de usuario reales del dominio a menudo leak a través del aire.
  • Validación cliente-servidor defectuosa: si el supplicant no verifica estrictamente el certificado del servidor RADIUS (o permite que los usuarios omitan las advertencias), un rogue AP con un certificado self-signed aún puede onboard victims – convirtiendo mutual TLS en one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP realiza un intercambio de identidad antes de que TLS comience. Si el cliente usa el nombre de usuario real del dominio como su identidad externa, cualquier persona en rango RF puede capturarlo sin autenticarse.

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

Impacto: recolección rápida de nombres de usuario sin autenticación → alimenta password spraying, phishing y correlación de cuentas. Peor cuando los nombres de usuario coinciden con direcciones de correo.

TLS 1.3 privacy vs downgrade games

TLS 1.3 cifra los certificados de cliente y la mayor parte de los metadatos del handshake, así que cuando un supplicant actually negocia TLS 1.3, un Evil Twin no puede aprender pasivamente el certificado/identidad del cliente. Muchas pilas empresariales todavía permiten TLS 1.2 por compatibilidad; RFC 9190 advierte que un AP rogue puede ofrecer solo suites static-RSA de TLS 1.2 para forzar un fallback y re-exponer la identidad externa (o incluso el certificado del cliente) en cleartext EAP-TLS.

Playbook ofensivo (downgrade to leak ID):

  • Compilar hostapd-wpe con solo los cifrados static RSA de TLS 1.2 habilitados y TLS 1.3 deshabilitado en openssl_ciphersuite / ssl_ctx_flags.
  • Anunciar el SSID corporativo; cuando la víctima inicie TLS 1.3, responder con una alerta TLS y reiniciar el handshake para que el peer reintente con TLS 1.2, revelando su identidad real antes de que la validación del certificado tenga éxito.
  • Emparejar esto con force_authorized=1 en hostapd-wpe para que el 4-way handshake se complete aunque falle la autenticación del cliente, dándote tráfico a nivel DHCP/DNS para phish o portal.

Interruptor defensivo (qué buscar durante una evaluación):

  • hostapd/wpa_supplicant 2.10 añadió soporte de servidor y peer para EAP-TLS TLS 1.3 pero lo distribuye deshabilitado por defecto; habilitarlo en clientes con phase1="tls_disable_tlsv1_3=0" elimina la ventana de downgrade.

TLS 1.3 realities in 2024–2025

  • FreeRADIUS 3.0.23+ acepta EAP-TLS 1.3, pero los clientes aún fallan (Windows 11 no tiene resumption de sesión EAP-TLS 1.3, el soporte en Android varía), por lo que muchas implementaciones fijan tls_max_version = "1.2" por estabilidad.
  • Windows 11 habilita EAP-TLS 1.3 por defecto (22H2+), aun así los reintentos fallidos y pilas RADIUS inestables a menudo fuerzan un fallback a TLS 1.2.
  • El intercambio de claves RSA para TLS 1.2 está siendo deprecado; OpenSSL 3.x elimina las suites static-RSA a nivel de seguridad ≥2, así que un rogue TLS 1.2 static-RSA necesita OpenSSL 1.1.1 con @SECLEVEL=0 o anterior.

Direccionamiento práctico de versión durante un engagement

  • Forzar TLS 1.2 en el rogue (para leak identities):
# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0   # requires OpenSSL 1.1.1
disable_tlsv1_3=1
  • Probar intolerancia TLS del cliente: ejecutar dos rogues – uno anunciando solo TLS 1.3 (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) y otro solo TLS 1.2. Los clientes que solo se unan al BSS 1.2 son downgradeable.
  • Vigilar el fallback en capturas: filtrar en Wireshark por tls.handshake.version==0x0303 después de un ClientHello inicial con supported_versions que contenga 0x0304; las víctimas que reintentan 0x0303 están leaking su outer ID de nuevo.

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

APs rogue que anuncian el SSID corporativo pueden presentar cualquier certificado. Si el cliente:

  • no valida el certificado del servidor, o
  • muestra un prompt al usuario y permite sobrescribir CAs no confiables/certificados self-signed, entonces EAP-TLS deja de ser mutual. Un hostapd/hostapd-wpe modificado que omita la validación del certificado cliente (p. ej., SSL_set_verify(..., 0)) es suficiente para levantar el Evil Twin.

Nota rápida sobre la infraestructura rogue

En Kali reciente, compilar hostapd-wpe usando hostapd-2.6 (from https://w1.fi/releases/) e instalar primero los headers legacy de OpenSSL:

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

Errores comunes de configuración del supplicant de Windows (GUI/GPO)

Elementos clave del perfil EAP-TLS en Windows:

  • Verify the server’s identity by validating the certificate
  • Checked → chain must be trusted; unchecked → any self-signed cert is accepted.
  • Connect to these servers
  • Empty → any cert from a trusted CA is accepted; set CN/SAN list to pin expected RADIUS names.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Checked → users cannot click through; unchecked → user can trust an untrusted CA/cert and join the rogue AP.

Resultados observados:

  • Strict validation + no prompts → rogue cert rejected; Windows logs an event and TLS fails (good detection signal).
  • Validation + user prompt → user acceptance = successful Evil Twin association.
  • No validation → silent Evil Twin association with any cert.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks