Evil Twin EAP-TLS

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

EAP-TLS ni chaguo la kawaida “salama” kwa WPA2/3-Enterprise, lakini udhaifu wawili wa vitendo mara kwa mara hujionyesha wakati wa tathmini:

  • Unauthenticated identity leakage: EAP-Response/Identity ya nje inatumwa kwa cleartext kabla ya kujengwa TLS tunnel yoyote, hivyo real domain usernames mara nyingi leak over the air.
  • Broken client server-validation: ikiwa supplicant haithibitishi kwa ukali cheti la seva ya RADIUS (au inaruhusu watumiaji kubonyeza kupitia warnings), rogue AP yenye self-signed cert bado inaweza onboard victims – kubadilisha mutual TLS kuwa one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP inaendesha ubadilishanaji wa utambulisho kabla ya TLS kuanza. Ikiwa client inatumia real domain username kama outer identity yake, mtu yeyote ndani ya RF range anaweza harvest bila ku-authenticate.

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

Athari: haraka, ukusanyaji wa username bila uthibitisho → huchangia password spraying, phishing, account correlation. Mbaya zaidi wakati usernames zinafanana na anwani za barua pepe.

TLS 1.3 faragha dhidi ya mbinu za downgrade

TLS 1.3 hu-encrypt client certs na metadata nyingi za handshake, hivyo wakati supplicant kwa kweli anaposhirikiana TLS 1.3, Evil Twin hawezi kwa passively kujifunza cheti/utambulisho wa client. Mifumo mingi ya enterprise bado inaruhusu TLS 1.2 kwa compatibility; RFC 9190 inaonya kuwa rogue AP inaweza kutoa tu TLS 1.2 static-RSA suites ili kusababisha fallback na kuonyesha tena outer identity (au hata client cert) kwa cleartext katika EAP-TLS.

Mpango la kushambulia (downgrade to leak ID):

  • Compile hostapd-wpe with only TLS 1.2 static RSA ciphers enabled and TLS 1.3 disabled in openssl_ciphersuite / ssl_ctx_flags.
  • Tangaza SSID ya shirika; wakati victim anapoanzisha TLS 1.3, jibu kwa TLS alert na anza upya handshake ili peer ajaribu tena kwa TLS 1.2, akifichua utambulisho wake halisi kabla ya cert validation kufanikiwa.
  • Unganisha hili na force_authorized=1 katika hostapd-wpe ili 4-way handshake ikamilike hata kama client-auth itashindwa, ikikupa trafiki ya ngazi ya DHCP/DNS kwa ajili ya phish au portal.

Kibadili cha ulinzi (kinachotazamiwa wakati wa assessment):

  • hostapd/wpa_supplicant 2.10 iliongeza EAP-TLS server na peer support kwa TLS 1.3 lakini inapelekwa imezimwa kwa default; kuziwezesha kwa clients kwa phase1="tls_disable_tlsv1_3=0" kunafuta dirisha la downgrade.

Evil Twin kupitia uhakiki wa server ulioharibika (“mTLS?”)

Rogue APs zinazotangaza SSID ya shirika zinaweza kuwasilisha certificate yoyote. Kama client:

  • haithibitishi server cert, au
  • inauliza mtumiaji na kuruhusu override ya untrusted CAs/self-signed certs, basi EAP-TLS inakoma kuwa mutual. hostapd/hostapd-wpe iliyorekebishwa inayepita client-cert validation (kwa mfano, SSL_set_verify(..., 0)) inatosha kuanzisha Evil Twin.

Kumbusho fupi kuhusu rogue infra

Kwenye Kali ya karibuni, compile hostapd-wpe ukitumia hostapd-2.6 (from https://w1.fi/releases/) na install the legacy OpenSSL headers kwanza:

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

Mapungufu ya mipangilio mibaya ya Windows supplicant (GUI/GPO)

Vigezo muhimu kutoka kwenye profaili ya Windows EAP-TLS:

  • Thibitisha utambulisho wa server kwa kuthibitisha cheti
  • Imechaguliwa → mnyororo lazima uwe wa kuaminiwa; haijachaguliwa → cheti chochote kilichojisaini mwenyewe kinakubaliwa.
  • Unganisha na server hizi
  • Tupu → cheti chochote kutoka kwa CA inayotegemewa kinakubaliwa; weka orodha ya CN/SAN ili kupiga pini majina ya RADIUS yanayotarajiwa.
  • Usimwulize mtumiaji kuidhinisha server mpya au mamlaka mpya za vyeti zinazotegemewa
  • Imechaguliwa → watumiaji hawawezi kubonyeza kuendelea; haijachaguliwa → mtumiaji anaweza kumwamini CA/cheti kisichoaminika na kujiunga na rogue AP.

Matokeo yaliyoonekana:

  • Uthibitishaji mkali + hakuna vitisho → cheti cha rogue kinakataliwa; Windows inarekodi tukio na TLS inashindwa (ishara nzuri ya utambuzi).
  • Uthibitishaji + onyo kwa mtumiaji → kukubaliwa kwa mtumiaji = kufanikiwa kuunganishwa na Evil Twin.
  • Hakuna uthibitishaji → kuunganishwa kimya kwa Evil Twin na cheti chochote.

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks