Evil Twin EAP-TLS

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

EAP-TLS는 WPA2/3-Enterprise에서 일반적으로 선택되는 “secure” 옵션이지만, 평가 중에 두 가지 실용적인 약점이 자주 발견됩니다:

  • Unauthenticated identity leakage: outer EAP-Response/Identity는 TLS 터널이 구축되기 전에 평문으로 전송되므로, 실제 도메인 사용자 이름이 무선상에서 종종 leak됩니다.
  • Broken client server-validation: supplicant가 RADIUS 서버 인증서를 엄격하게 검증하지 않거나 사용자가 경고를 클릭해서 넘어가도록 허용하면, self-signed cert를 사용하는 rogue AP가 여전히 피해자를 온보딩할 수 있어 mutual TLS가 일방향 TLS로 바뀔 수 있습니다.

Unauthenticated EAP identity leakage / username enumeration

EAP는 TLS가 시작되기 전에 아이덴티티 교환을 수행합니다. 클라이언트가 외부 아이덴티티로 실제 도메인 사용자 이름을 사용하면, RF 범위 내의 누구나 인증 없이 그것을 harvest할 수 있습니다.

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: 빠르고 인증 불필요한 username 수집 → password spraying, phishing, account correlation에 연료를 공급함. Worse when usernames match email addresses.

TLS 1.3 개인 정보 보호 vs 다운그레이드 게임

TLS 1.3은 client certs와 대부분의 handshake metadata를 암호화하므로, supplicant가 실제로 TLS 1.3을 협상할 때 Evil Twin은 수동적으로 client certificate/identity를 알아낼 수 없다. 많은 enterprise stacks가 호환성을 위해 여전히 TLS 1.2를 허용한다; RFC 9190은 rogue AP가 TLS 1.2 static-RSA suites만 제공해 fallback을 강제하고 outer identity(심지어 client cert)를 cleartext EAP-TLS로 다시 드러낼 수 있다고 경고한다.

Offensive playbook (downgrade to leak ID):

  • hostapd-wpe를 TLS 1.2 static RSA ciphers만 활성화하고 TLS 1.3을 openssl_ciphersuite / ssl_ctx_flags에서 비활성화한 상태로 컴파일한다.
  • corporate SSID를 광고한다; victim이 TLS 1.3을 시작하면 TLS alert로 응답하고 handshake를 재시작하여 피어가 TLS 1.2로 재시도하게 함으로써 cert validation이 성공하기 전에 실제 identity를 드러내게 한다.
  • hostapd-wpe에서 force_authorized=1을 함께 설정하면 client-auth가 실패하더라도 4-way handshake가 완료되어 DHCP/DNS-level 트래픽을 이용한 phish나 portal 공격이 가능해진다.

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

  • hostapd/wpa_supplicant 2.10은 EAP-TLS server and peer 수준에서 TLS 1.3을 추가했지만 기본적으로 disabled by default로 제공된다; 클라이언트에서 phase1="tls_disable_tlsv1_3=0"으로 활성화하면 다운그레이드 창을 제거할 수 있다.

TLS 1.3 realities in 2024–2025

  • FreeRADIUS 3.0.23+는 EAP-TLS 1.3을 수용하지만, 클라이언트는 여전히 깨지기 때문에(Windows 11은 EAP-TLS 1.3 세션 재개 없음, Android 지원은 다양함) 많은 배포에서 안정성을 위해 tls_max_version = "1.2"로 고정한다.
  • Windows 11은 EAP-TLS 1.3을 기본으로 활성화(22H2+)하지만 실패한 resumptions과 불안정한 RADIUS 스택 때문에 종종 TLS 1.2로의 fallback을 강요당한다.
  • TLS 1.2용 RSA key exchange는 폐기되고 있으며; OpenSSL 3.x는 security level ≥2에서 static-RSA suites를 제거하므로 TLS 1.2 static-RSA rogue는 OpenSSL 1.1.1과 @SECLEVEL=0 또는 그 이전 버전이 필요하다.

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: 두 개의 rogue를 운영하라 – 하나는 TLS 1.3-only를 광고(disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1)하고 다른 하나는 TLS 1.2-only로 광고한다. 오직 1.2 BSS에만 접속하는 클라이언트는 다운그레이드 대상이다.
  • Watch for fallback in captures: 초기 ClientHello의 supported_versions에 0x0304가 포함된 후 tls.handshake.version==0x0303를 Wireshark에서 필터링하라; 0x0303로 재시도하는 victims는 다시 outer ID를 leaking 하고 있다.

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

Rogue APs가 corporate SSID를 방송하면 어떤 certificate든 제시할 수 있다. 클라이언트가:

  • doesn’t validate the server cert, 또는
  • prompts the user 하고 untrusted CAs/self-signed certs를 오버라이드하도록 허용하면, EAP-TLS는 더 이상 mutual하지 않다. client-cert validation을 건너뛰는(예: SSL_set_verify(..., 0)) 수정된 hostapd/hostapd-wpe만 있으면 Evil Twin을 세울 수 있다.

Rogue infra quick note

On recent Kali, compile hostapd-wpe using hostapd-2.6 (from https://w1.fi/releases/) and install the legacy OpenSSL headers first:

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 설정 실수 (GUI/GPO)

Windows EAP-TLS 프로파일의 주요 설정:

  • Verify the server’s identity by validating the certificate
  • 체크됨 → 체인(chain)이 신뢰되어야 함; 체크 해제 → 모든 self-signed cert 허용.
  • Connect to these servers
  • 비어 있음 → 신뢰된 CA의 모든 인증서 허용; CN/SAN 목록을 설정하여 예상되는 RADIUS 이름을 고정(pin).
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • 체크됨 → 사용자가 우회할 수 없음; 체크 해제 → 사용자가 신뢰되지 않는 CA/인증서를 신뢰하고 rogue AP에 연결할 수 있음.

관찰된 결과:

  • Strict validation + no prompts → rogue cert 거부됨; Windows가 이벤트를 기록하고 TLS 실패(좋은 탐지 신호).
  • Validation + user prompt → 사용자가 수락하면 성공적인 Evil Twin 연결.
  • No validation → 모든 인증서로 조용히 Evil Twin 연결.

References

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기