Evil Twin EAP-TLS

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

EAP-TLS, WPA2/3-Enterprise için yaygın “güvenli” seçimdir; ancak değerlendirmelerde düzenli olarak iki pratik zayıflık ortaya çıkar:

  • Unauthenticated identity leakage: outer EAP-Response/Identity, herhangi bir TLS tüneli kurulmadan önce cleartext olarak gönderilir; bu nedenle gerçek domain kullanıcı adları genellikle hava üzerinden leak olur.
  • Broken client server-validation: supplicant RADIUS sunucu sertifikasını sıkı şekilde doğrulamazsa (veya kullanıcıların uyarıları geçmesine izin verirse), self-signed cert kullanan rogue AP yine de kurbanları ağa dahil edebilir — mutual TLS’i one-way TLS’e çevirir.

Unauthenticated EAP identity leakage / username enumeration

EAP, TLS başlamadan önce bir kimlik değişimi başlatır. Eğer client outer identity olarak gerçek domain kullanıcı adını kullanıyorsa, RF menzilindekiler bunu kimlik doğrulaması olmadan elde edebilir.

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: hızlı, no-auth username toplama → password spraying, phishing, hesap korelasyonunu besler. Kullanıcı adları e-posta adresleriyle eşleştiğinde durum daha kötü.

TLS 1.3 gizlilik vs downgrade oyunları

TLS 1.3 client certs ve çoğu handshake metadata’sını şifreler; bu yüzden bir supplicant gerçekten TLS 1.3 üzerinde anlaşma sağladığında, bir Evil Twin pasif olarak client certificate/identity’yi öğrenemez. Birçok kurumsal yığın uyumluluk için hâlâ TLS 1.2’ye izin veriyor; RFC 9190, kötü niyetli bir AP’nin yalnızca TLS 1.2 static-RSA suite’leri sunarak fallback zorlayıp outer identity’yi (ve hatta client cert’i) cleartext EAP-TLS içinde tekrar açığa çıkarabileceği konusunda uyarır.

Offensive playbook (downgrade to leak ID):

  • hostapd-wpe’yi yalnızca TLS 1.2 static RSA şifreleri etkin ve TLS 1.3 devre dışı olacak şekilde derleyin; bunu openssl_ciphersuite / ssl_ctx_flags içinde ayarlayın.
  • Kurumsal SSID’yi yayınlayın; kurban TLS 1.3 başlattığında bir TLS alert ile yanıt verin ve handshake’i yeniden başlatın, böylece peer TLS 1.2 ile tekrar dener ve sertifika doğrulaması başarılı olmadan önce gerçek kimliğini ifşa eder.
  • Bunu force_authorized=1 ile hostapd-wpe’de eşleştirerek client-auth başarısız olsa bile 4-way handshake’in tamamlanmasını sağlayın; bu size phishing veya portal için DHCP/DNS-seviyesinde trafik verir.

Defensive toggle (assessment sırasında nelere bakılmalı):

  • hostapd/wpa_supplicant 2.10, EAP-TLS için hem server hem de peer desteğini TLS 1.3 ile ekledi ancak varsayılan olarak devre dışı geliyor; istemcilerde phase1="tls_disable_tlsv1_3=0" ile etkinleştirmek downgrade penceresini kapatır.

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

Kurumsal SSID’yi yayınlayan rogue AP’ler herhangi bir sertifika sunabilir. Eğer istemci:

  • doesn’t validate the server cert, veya
  • prompts the user ve untrusted CAs/self-signed certs için override’a izin veriyorsa, o zaman EAP-TLS mutual olmaktan çıkar. client-cert doğrulamasını atlayan (ör. SSL_set_verify(..., 0)) modifiye edilmiş bir hostapd/hostapd-wpe Evil Twin kurmak için yeterlidir.

Rogue infra quick note

Güncel Kali’de, hostapd-wpe’yi hostapd-2.6 (from https://w1.fi/releases/) kullanarak derleyin ve önce legacy OpenSSL headers’ı kurun:

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)

Key knobs from the Windows EAP-TLS profile:

  • Sertifikayı doğrulayarak sunucunun kimliğini doğrula
  • Checked → zincirin güvenilir olması gerekir; unchecked → herhangi bir self-signed cert kabul edilir.
  • Bu sunuculara bağlan
  • Empty → trusted CA’dan herhangi bir cert kabul edilir; CN/SAN listesini ayarlayarak beklenen RADIUS isimlerini pinleyin.
  • Kullanıcıya yeni sunucuları veya güvenilen sertifika otoritelerini yetkilendirmesi için istemde bulunma
  • Checked → kullanıcılar atlayamaz; unchecked → kullanıcı güvensiz bir CA/cert’e güven verebilir ve rogue AP’ye katılabilir.

Observed outcomes:

  • Strict validation + no prompts → rogue cert reddedilir; Windows bir olay kaydeder ve TLS başarısız olur (iyi bir tespit sinyali).
  • Validation + user prompt → kullanıcı onayı = başarılı Evil Twin association.
  • No validation → herhangi bir cert ile sessiz Evil Twin association.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin