Evil Twin EAP-TLS

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

EAP-TLS é a escolha “segura” comum para WPA2/3-Enterprise, mas duas fraquezas práticas aparecem regularmente durante avaliações:

  • Unauthenticated identity leakage: o outer EAP-Response/Identity é enviado em cleartext antes de qualquer túnel TLS ser estabelecido, então nomes de usuário de domínio reais frequentemente leak over the air.
  • Broken client server-validation: se o supplicant não verificar estritamente o RADIUS server certificate (ou permitir que usuários click through warnings), um rogue AP com um self-signed cert ainda pode onboard victims — transformando mutual TLS em one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP realiza uma troca de identidade before o TLS iniciar. Se o cliente usar o nome de usuário de domínio real como sua outer identity, qualquer pessoa em RF range pode harvest it sem se autenticar.

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: coleta rápida de nomes de usuário sem autenticação (no-auth) → alimenta password spraying, phishing e correlação de contas. Pior quando os nomes de usuário coincidem com endereços de email.

TLS 1.3: privacidade vs estratégias de downgrade

TLS 1.3 cifra os certificados do cliente e a maior parte dos metadados do handshake, então quando um supplicant realmente negocia TLS 1.3, um Evil Twin não pode aprender passivamente o certificado/identidade do cliente. Muitas pilhas empresariais ainda permitem TLS 1.2 por compatibilidade; RFC 9190 alerta que um rogue AP pode oferecer apenas suítes TLS 1.2 static-RSA para forçar um fallback e reexpor a identidade externa (ou até o certificado do cliente) em cleartext EAP-TLS.

Offensive playbook (downgrade to leak ID):

  • Compile hostapd-wpe com apenas os conjuntos de cifras static-RSA de TLS 1.2 habilitados e TLS 1.3 desabilitado em openssl_ciphersuite / ssl_ctx_flags.
  • Anuncie o SSID corporativo; quando a vítima inicia TLS 1.3, responda com um alerta TLS e reinicie o handshake para que o peer tente novamente com TLS 1.2, revelando sua identidade real antes da validação do cert ter sucesso.
  • Combine isso com force_authorized=1 no hostapd-wpe para que o 4-way handshake complete mesmo se o client-auth falhar, dando tráfego a nível DHCP/DNS para phish ou portal.

Defensive toggle (o que observar durante uma avaliação):

  • hostapd/wpa_supplicant 2.10 adicionou suporte de servidor e peer para EAP-TLS sobre TLS 1.3, mas vem desabilitado por padrão; habilitar nos clientes com phase1="tls_disable_tlsv1_3=0" remove a janela de downgrade.

Realidades do TLS 1.3 em 2024–2025

  • FreeRADIUS 3.0.23+ aceita EAP-TLS 1.3, mas clientes ainda quebram (Windows 11 não tem resumption de sessão EAP-TLS 1.3, o suporte no Android varia), então muitas implantações fixam tls_max_version = "1.2" por estabilidade.
  • Windows 11 habilita EAP-TLS 1.3 por padrão (22H2+), porém resumos de sessão falhos e pilhas RADIUS instáveis frequentemente forçam fallback para TLS 1.2.
  • A troca de chaves RSA para TLS 1.2 está sendo descontinuada; OpenSSL 3.x remove suítes static-RSA em nível de segurança ≥2, então um rogue TLS 1.2 static-RSA precisa de OpenSSL 1.1.1 com @SECLEVEL=0 ou anterior.

Direcionamento prático de versão durante um engagement

  • Forçar TLS 1.2 no 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
  • Testar intolerância TLS do cliente: execute dois rogues – um anunciando apenas TLS 1.3 (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) e outro apenas TLS 1.2. Clientes que só entram na BSS 1.2 são passíveis de downgrade.
  • Observar fallback em captures: filtre no Wireshark por tls.handshake.version==0x0303 após um ClientHello inicial com supported_versions contendo 0x0304; vítimas que retry 0x0303 estão leaking sua outer ID novamente.

Evil Twin via validação de servidor quebrada (“mTLS?”)

Rogue APs que divulgam o SSID corporativo podem apresentar qualquer certificado. Se o cliente:

  • não valida o certificado do servidor, ou
  • solicita ao usuário e permite sobrescrever CAs não confiáveis / certificados self-signed, então EAP-TLS deixa de ser mutual. Um hostapd/hostapd-wpe modificado que pula a validação do client-cert (e.g., SSL_set_verify(..., 0)) é suficiente para levantar o Evil Twin.

Nota rápida sobre infra rogue

No Kali recente, compile hostapd-wpe usando hostapd-2.6 (de https://w1.fi/releases/) e instale primeiro os headers legados do OpenSSL:

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

Armadilhas de misconfiguração do Windows supplicant (GUI/GPO)

Principais opções do perfil Windows EAP-TLS:

  • Verify the server’s identity by validating the certificate
  • Marcado → a cadeia deve ser confiável; desmarcado → qualquer certificado autoassinado é aceito.
  • Connect to these servers
  • Vazio → qualquer certificado de uma CA confiável é aceito; defina a lista CN/SAN para fixar (pin) os nomes RADIUS esperados.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Marcado → os usuários não podem prosseguir clicando; desmarcado → o usuário pode confiar em uma CA/cert não confiável e conectar-se ao AP malicioso.

Resultados observados:

  • Strict validation + no prompts → certificado malicioso rejeitado; Windows registra um evento e TLS falha (bom sinal de detecção).
  • Validation + user prompt → aceitação do usuário = associação Evil Twin bem-sucedida.
  • No validation → associação silenciosa do Evil Twin com qualquer certificado.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks