Skip to content

EAP-TLS The most secure option? #1738

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
carlospolop wants to merge 1 commit into
base: master
Choose a base branch
from
Open

EAP-TLS The most secure option? #1738

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 41 additions & 33 deletions src/generic-methodologies-and-resources/pentesting-wifi/evil-twin-eap-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,56 +2,64 @@

{{#include ../../banners/hacktricks-training.md}}

EAP-TLS is the common "secure" choice for WPA2/3-Enterprise, but two practical weaknesses regularly show up during assessments:

- **Unauthenticated identity leakage**: the outer EAP-Response/Identity is sent in cleartext before any TLS tunnel is built, so real domain usernames often leak over the air.
- **Broken client server-validation**: if the supplicant doesn’t strictly verify the RADIUS server certificate (or allows users to click through warnings), a rogue AP with a self-signed cert can still onboard victims – turning mutual TLS into one-way TLS.

At some point I needed to use the proposed solution by the post bellow but the steps in [https://github.com/OpenSecurityResearch/hostapd-wpe](https://github.com/OpenSecurityResearch/hostapd-wpe) wasn't working in modern kali (2019v3) anymore.\
Anyway, it's easy to make them work.\
You only need to download the hostapd-2.6 from here: [https://w1.fi/releases/](https://w1.fi/releases/) and before compiling again hostapd-wpe install: `apt-get install libssl1.0-dev`
## Unauthenticated EAP identity leakage / username enumeration

### Analyzing and Exploiting EAP-TLS in Wireless Networks
EAP drives an identity exchange *before* TLS starts. If the client uses the real domain username as its outer identity, anyone in RF range can harvest it without authenticating.

#### Background: EAP-TLS in Wireless Networks
**Passive harvest workflow**

EAP-TLS is a security protocol providing mutual authentication between client and server using certificates. The connection is only established if both the client and the server authenticate each other's certificates.
```bash
# 1) Park on the right channel/BSSID
airodump-ng -i $IFACE -c $CHAN --bssid $BSSID

#### Challenge Encountered
# 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]"
```

During an assessment, an interesting error was encountered when using the `hostapd-wpe` tool. The tool rejected the client's connection due to the client's certificate being signed by an unknown Certificate Authority (CA). This indicated that the client did trust the fake server's certificate, pointing to lax security configurations on the client side.
Impact: fast, no-auth username collection → fuels password spraying, phishing, account correlation. Worse when usernames match email addresses.

#### Objective: Setting Up a Man-in-the-Middle (MiTM) Attack
## Evil Twin via broken server validation ("mTLS?")

The goal was to modify the tool to accept any client certificate. This would allow the establishment of a connection with the malicious wireless network and enable a MiTM attack, potentially capturing plaintext credentials or other sensitive data.
Rogue APs broadcasting the corporate SSID can present any certificate. If the client:
- **doesn’t validate** the server cert, or
- **prompts the user** and allows override of untrusted CAs/self-signed certs,
then EAP-TLS stops being mutual. A modified **hostapd/hostapd-wpe** that skips client-cert validation (e.g., `SSL_set_verify(..., 0)`) is enough to stand up the Evil Twin.

#### Solution: Modifying `hostapd-wpe`
### Rogue infra quick note

Analysis of the source code of `hostapd-wpe` revealed that the client certificate validation was controlled by a parameter (`verify_peer`) in the OpenSSL function `SSL_set_verify`. By changing this parameter's value from 1 (validate) to 0 (do not validate), the tool was made to accept any client certificate.
On recent Kali, compile `hostapd-wpe` using hostapd-2.6 (from https://w1.fi/releases/) and install the legacy OpenSSL headers first:

#### Execution of the Attack
```bash
apt-get install libssl1.0-dev
# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert
```

1. **Environment Check:** Use `airodump-ng` to monitor wireless networks and identify targets.
2. **Set Up Fake AP:** Run the modified `hostapd-wpe` to create a fake Access Point (AP) mimicking the target network.
3. **Captive Portal Customization:** Customize the login page of the captive portal to appear legitimate and familiar to the target user.
4. **De-authentication Attack:** Optionally, perform a de-auth attack to disconnect the client from the legitimate network and connect them to the fake AP.
5. **Capturing Credentials:** Once the client connects to the fake AP and interacts with the captive portal, their credentials are captured.
### Windows supplicant misconfig pitfalls (GUI/GPO)

#### Observations from the Attack
Key knobs from the Windows EAP-TLS profile:
- **Verify the server's identity by validating the certificate**
- Checked → chain must be trusted; unchecked → any self-signed cert is accepted.
- **Connect to these servers**
- Empty → any cert from a trusted CA is accepted; set CN/SAN list to pin expected RADIUS names.
- **Don't prompt user to authorise new servers or trusted certification authorities**
- Checked → users cannot click through; unchecked → user can trust an untrusted CA/cert and join the rogue AP.

- On Windows machines, the system might automatically connect to the fake AP, presenting the captive portal when web navigation is attempted.
- On an iPhone, the user might be prompted to accept a new certificate and then presented with the captive portal.

#### Conclusion

While EAP-TLS is considered secure, its effectiveness heavily depends on the correct configuration and cautious behavior of end-users. Misconfigured devices or unsuspecting users accepting rogue certificates can undermine the security of an EAP-TLS protected network.

For further details check https://versprite.com/blog/application-security/eap-tls-wireless-infrastructure/
Observed outcomes:
- **Strict validation + no prompts** → rogue cert rejected; Windows logs an event and TLS fails (good detection signal).
- **Validation + user prompt** → user acceptance = successful Evil Twin association.
- **No validation** → silent Evil Twin association with any cert.

## References

- [https://versprite.com/blog/application-security/eap-tls-wireless-infrastructure/](https://versprite.com/blog/application-security/eap-tls-wireless-infrastructure/)


- [EAP-TLS: The most secure option? (NCC Group)](https://www.nccgroup.com/research-blog/eap-tls-the-most-secure-option/)
- [EAP-TLS wireless infrastructure (Versprite hostapd bypass)](https://versprite.com/blog/eap-tls-wireless-infrastructure/)
- [RFC 4282 - Network Access Identifier](https://datatracker.ietf.org/doc/html/rfc4282)
- [Microsoft ServerValidationParameters (WLAN profile)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gpwl/0765966e-a16a-4e75-aec6-0f5f7bfbf31c)

{{#include ../../banners/hacktricks-training.md}}