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” tercihidir, ancak değerlendirmelerde iki pratik zayıflık düzenli olarak ortaya çıkar:

  • Doğrulanmamış kimlik sızıntısı: dış EAP-Response/Identity, herhangi bir TLS tüneli kurulmadan önce düz metin olarak gönderilir, bu yüzden gerçek domain kullanıcı adları genellikle kablosuz ortamda leak.
  • İstemci-sunucu doğrulamasının bozulması: supplicant RADIUS sunucu sertifikasını sıkı şekilde doğrulamazsa (veya kullanıcılara uyarıları onaylamasına izin verirse), kendi imzalı bir sertifikaya sahip sahte bir AP yine de kurbanları ağa kabul ettirebilir – böylece mutual TLS tek yönlü TLS’e dönüşür.

Doğrulanmamış EAP kimlik sızıntısı / kullanıcı adı keşfi

EAP, TLS başlamadan önce bir kimlik alışverişi gerçekleştirir. Eğer istemci gerçek domain kullanıcı adını dış kimliği olarak kullanıyorsa, RF menzilindeki herkes bunu kimlik doğrulaması yapmadan toplayabilir.

Pasif toplama iş akışı

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

Etkisi: hızlı, kimlik doğrulama gerektirmeyen kullanıcı adı toplama → password spraying, phishing, account correlation için yakıt sağlar. Kullanıcı adları e-posta adresleriyle eşleşiyorsa daha kötü.

TLS 1.3 privacy vs downgrade games

TLS 1.3, client certs ve çoğu handshake metadata’sını şifrelediğinden, bir supplicant gerçekten TLS 1.3 müzakere ettiğinde, bir Evil Twin pasif olarak client certificate/identity öğrenemez. Birçok kurumsal yığın uyumluluk için hâlâ TLS 1.2’ye izin veriyor; RFC 9190, bir rogue AP’nin sadece TLS 1.2 static-RSA suite’leri sunarak bir fallback’i zorlayıp outer identity’yi (veya hatta client cert’i) cleartext EAP-TLS içinde yeniden ortaya çı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; bunun için openssl_ciphersuite / ssl_ctx_flags ayarlarını kullanın.
  • Kurumsal SSID’yi duyurun; hedef 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 deneyecek ve cert doğrulaması başarılı olmadan gerçek kimliğini ortaya çıkaracaktır.
  • Bunu hostapd-wpe içinde force_authorized=1 ile eşleştirin; böylece client-auth başarısız olsa bile 4-way handshake tamamlanır ve phish veya portal için DHCP/DNS düzeyinde trafik elde edersiniz.

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

  • hostapd/wpa_supplicant 2.10, EAP-TLS server ve peer için TLS 1.3 desteği ekledi ama varsayılan olarak devre dışı geliyor; client’larda phase1="tls_disable_tlsv1_3=0" ile etkinleştirmek downgrade penceresini ortadan kaldırır.

TLS 1.3 realities in 2024–2025

  • FreeRADIUS 3.0.23+ EAP-TLS 1.3 kabul ediyor, ancak client’lar hâlâ sorun çıkarıyor (Windows 11’de EAP-TLS 1.3 session resumption yok, Android desteği değişken), bu yüzden birçok dağıtım istikrar için tls_max_version = "1.2" sabitliyor.
  • Windows 11, EAP-TLS 1.3’ü varsayılan olarak etkinleştiriyor (22H2+), ancak başarısız resumption’lar ve kararsız RADIUS yığınları genellikle TLS 1.2’ye fallback’e zorlayabiliyor.
  • TLS 1.2 için RSA anahtar değişimi kullanım dışı bırakılıyor; OpenSSL 3.x, security level ≥2’de static-RSA suite’lerini kaldırıyor, bu yüzden TLS 1.2 static-RSA rogue için OpenSSL 1.1.1 ve @SECLEVEL=0 veya daha eski sürümler gerekiyor.

Practical version steering during an engagement

  • Force TLS 1.2 on the 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
  • Probe client TLS intolerance: iki rogue çalıştırın – biri TLS 1.3-only duyuran (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) ve diğeri TLS 1.2-only. Yalnızca 1.2 BSS’e katılan client’lar downgrade edilmeye açıktır.
  • Watch for fallback in captures: ilk ClientHello’da supported_versions içinde 0x0304 varken, Wireshark’ta tls.handshake.version==0x0303 ile filtreleyin; 0x0303’ü tekrar deneyen kurbanlar outer ID’lerini yeniden leaking ediyor.

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

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

  • sunucu sertifikasını doğrulamıyorsa, veya
  • kullanıcıyı uyarıyor ve güvensiz CA’ların / self-signed sertifikaların üzerine yazılmasına izin veriyorsa, o zaman EAP-TLS mutual olmaktan çıkar. client-cert doğrulamasını atlayan (ör. SSL_set_verify(..., 0)) değiştirilmiş bir hostapd/hostapd-wpe Evil Twin kurmak için yeterlidir.

Rogue infra quick note

Son Kali sürümlerinde, hostapd-wpe’yi hostapd-2.6 (from https://w1.fi/releases/) kullanarak derleyin ve önce legacy OpenSSL header’larını yükleyin:

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 yapılandırma hataları (GUI/GPO)

Windows EAP-TLS profilinin önemli ayarları:

  • Verify the server’s identity by validating the certificate
  • İşaretli → zincirin güvenilir olması gerekir; işaretsiz → herhangi bir kendi imzalı sertifika kabul edilir.
  • Connect to these servers
  • Boş → güvenilir bir CA’dan gelen herhangi bir sertifika kabul edilir; beklenen RADIUS isimlerini sabitlemek için CN/SAN listesini ayarlayın.
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • İşaretli → kullanıcılar geçiş yapamaz; işaretsiz → kullanıcı güvensiz bir CA/sertifikaya güvenebilir ve kötü amaçlı AP’ye katılabilir.

Gözlemlenen sonuçlar:

  • Strict validation + no prompts → kötü amaçlı sertifika reddedilir; Windows bir olay kaydı oluşturur ve TLS başarısız olur (iyi bir tespit sinyali).
  • Validation + user prompt → kullanıcının kabulü = başarılı Evil Twin bağlantısı.
  • No validation → herhangi bir sertifika ile sessiz Evil Twin bağlantısı.

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