Enterprise Wi-Fi networks rely on robust authentication to keep intruders out. One of the most widely used open-source clients for secure Wi-Fi is wpa_supplicant. It's everywhere—from laptops to embedded devices. But in late 2023, security researchers found a serious flaw affecting PEAP (Protected Extensible Authentication Protocol) in wpa_supplicant up to version 2.10. This bug, tracked as CVE-2023-52160, allows attackers to bypass authentication altogether—if certain settings are misconfigured.
This post explains the vulnerability in simple language, shows exactly how the exploit works, and gives you the code snippets and references you need to understand and test the bug yourself.
What is PEAP and Why Does It Matter?
PEAP is a two-step (phased) protocol that protects EAP (Extensible Authentication Protocol) messages inside a TLS tunnel. First, the client and server do a TLS handshake (Phase 1), then inside the tunnel, the client provides credentials (like a password or certificate) in Phase 2.
wpa_supplicant is the default client for handling this on Linux and many embedded systems.
Where’s the Bug?
The vulnerability is in the logic of eap_peap_decrypt inside wpa_supplicant—specifically in the way it handles certain EAP (Extensible Authentication Protocol) packets.
When PEAP starts, it expects a Phase 2 authentication exchange (username & password, for example). But with this bug, a malicious Wi-Fi access point can skip that by sending a specific success packet instead of requiring Phase 2 authentication.
Crucially, the exploit only works if the wpa_supplicant client is set to *not* check the server’s certificate during Phase 1. Unfortunately, many administrators lax on certificates are exactly those targeted by Wi-Fi phishing or Evil Twin attacks.
wpa_supplicant is configured NOT to validate the server's TLS certificate.
- Example: ca_cert="/etc/ssl/certs/ca-bundle.crt" is not set or set to "CA_CERTIFICATE_FILE" not trusted by the server, or tls_disable_session_ticket=1 is set.
TLS handshake finishes: Since certificate checking is off, this step doesn't protect the client.
4. Phase 2 skipped: Instead of asking for credentials, the attacker sends an EAP-TLV (Type-Length-Value) Success packet.
Technical Details
When PEAP is used, Phase 2 authentication (where the user’s password is sent) SHOULD happen after the outer secure TLS tunnel is built.
What the attacker sends to the client, instead of Phase 2, is a valid EAP-TLV Success packet, like this (pseudo-hex):
| EAP | Code: Request | Id: X | Length: Z | Type: 33 (EAP-TLV) | Data: ... TLV-Success ... |
wpa_supplicant up through 2.10 doesn't properly check that Phase 2 actually happened. So, if it gets this EAP-TLV Success, it thinks everything is fine and finalizes the authentication.
A common misconfiguration is to set up a Wi-Fi profile like this
network={
ssid="EnterpriseWiFi"
key_mgmt=WPA-EAP
eap=PEAP
identity="johndoe"
password="password123"
phase2="auth=MSCHAPV2"
# ca_cert is not set!
# ca_cert="/etc/ssl/certs/ca-bundle.crt" (commented out)
# Or: ca_cert="IGNORE" (dangerous)
}
If ca_cert is not set or set to "IGNORE", wpa_supplicant will skip checking the network’s TLS certificate. This opens the door to this exploit.
Exploit PoC (Proof of Concept) in Python
Attackers use rogue AP software (like hostapd-wpe, or custom EAP-PEAP responder scripts).
Here’s a super-simplified Python *scapy* snippet to forge an EAP-TLV Success response for research purposes:
from scapy.all import *
# EAP-TLV Success Attribute
EAP_TLV_SUCCESS_TYPE = x03
EAP_TLV_SUCCESS_LEN = 6
# Craft EAP-TLV Success packet
eap_tlv_success = (
b"\xd" + # EAP Code (Request)
b"\x01" + # EAP ID (1)
b"\x00\x08" + # Length (8 bytes)
b"\x21" + # Type (33 = EAP-TLV)
b"\x00\x03" + # TLV Type (Success)
b"\x00\x00" # Length ()
)
sendp(RadioTap()/Dot11()/LLC()/SNAP()/Raw(load=eap_tlv_success), iface="wlan")
*Note:* This snippet is for educational demonstration only. Actual attacks require a full 802.1X/EAP framework like hostapd-wpe.
Sensitive data (logins, emails, etc) can be intercepted (if clients trust the rogue AP).
- Enterprise credentials are at risk because clients "think" they're talking to the genuine infrastructure.
`
ca_cert="/etc/ssl/certs/your-ca.pem"
The bug is patched in releases after 2.10.
- Patch details: wpa_supplicant commit fixing CVE-2023-52160
CVE Database Entry:
wpa_supplicant Upstream Advisory & Patch:
hostapd / wpa_supplicant security advisory - January 2024
Original Patch Commit:
Technical analysis at Red Hat Bugzilla:
Conclusion
CVE-2023-52160 highlights how insecure defaults or missing options, like skipping certificate checks, can have devastating effects—even in security-focused software like wpa_supplicant. If you manage wireless infrastructure, always enforce strong certificate validation on your clients. Attackers are always looking for these kinds of oversights. Don’t make their job easy!
If you’re unsure about your configuration, review it today. Stay safe, stay patched, and as always, verify your TLS!
Exclusive Tip: Even without this bug, never trust a Wi-Fi network you don’t control. Attackers love to exploit missing certificate checks and other configuration shortcuts—don’t give them the chance!
*Written for the InfoSec and sysadmin community, June 2024.*
Timeline
Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/04/2024 22:47:18 UTC