Full Report
tl;dr We reported a long standing PEAP bug in all Apple devices that would allow an attacker to force any Apple device (iOS, macOS or tvOS) to associate with a malicious access point, even if the authentication server (RADIUS) couldn’t prove knowledge of the password. To understand it fully, we go on a deep dive into EAP and MSCHAPv2. Table of Contents PEAP at a High LevelMSCHAPv2Decrypting the Inner TunnelThe Inner MSCHAPv2 ExchangeByte-Level Description of the MSCHAPv2 ExchangeMSCHAPv2 CalculationsMSCHAPv2 Failure BehaviourThe Apple VulnerabilityApple’s FixDisclosure Timeline & DetailsOriginal Vulnerability Report While prepping for our Defcon talk last year, Michael kept pushing me to implement hostapd-wpe‘s EAP success attack. In this attack, the authentication server will accept any username, then skip the step where it proves knowledge of the password back to the station (because it doesn’t know the password), and instead sends an EAP-success message back to the station. I refused for a long time, because I thought it was a dumb attack that would never work. This is because in MSCHAPv2 the authentication server also proves knowledge of the password back to the station, and if it couldn’t, I assumed the station would just refuse to continue, after all, that’s the whole point.
Analysis Summary
# Vulnerability: PEAP EAP Success Bypass Allowing Rogue AP Association on Apple Devices
## CVE Details
- CVE ID: Not explicitly provided in the summary text. (The report references a known attack mechanism, but no final CVE ID is assigned in this snippet.)
- CVSS Score: 5.5 (Medium) based on the provided CVSS 3.0 vector: AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
- CWE: Insufficient Validation of Authenticator Proof in Encapsulated Authentication Protocol (related to flaws in MSCHAPv2 validation within PEAP).
## Affected Systems
- Products: Apple devices running iOS, macOS, and tvOS.
- Versions: All Apple devices were initially affected prior to the fix release described.
- Configurations: Devices configured to connect to Enterprise (PEAP/EAP-TLS) Wi-Fi networks.
## Vulnerability Description
The vulnerability lies in how Apple devices process the Protected Extensible Authentication Protocol (PEAP) exchange, specifically when combined with MSCHAPv2. Normally, during the inner tunnel MSCHAPv2 exchange, the Authentication Server (RADIUS) must prove knowledge of the password (via a Message Authenticator attribute) to the client station. The vulnerability allowed an attacker controlling a malicious Access Point (AP) to exploit a known technique (the EAP Success attack, often associated with `hostapd-wpe`) where the server sends an `EAP-Success` message *without* providing the required proof of password knowledge. Apple devices failed to adequately validate the absence of this authentication proof in the final message and consequently associated with the rogue AP. This allows an attacker to force association with a malicious AP even when the RADIUS server cannot prove it knows the shared credential.
## Exploitation
- Status: PoC available (Demonstrated using modifications to `hostapd-wpe` to simulate an authentication server that skips sending the required proof).
- Complexity: Low (Requires setting up a malicious access point and tricks the user into manually trusting a potentially cloned certificate).
- Attack Vector: Adjacent (Attacker must be in radio range of the target device).
## Impact
- Confidentiality: Low (If successful, the attacker controls the connection, potentially enabling MitM on the established tunnel, though the initial credential exchange is protected by TLS).
- Integrity: Low (Man-in-the-Middle attacks become possible on subsequent traffic).
- Availability: Low (Device connects to a network under attacker control).
Overall Impact: Devices could end up connected to networks the user believes are trusted, enabling further MitM attacks.
## Remediation
### Patches
- **Apple Patches:** Patches were released by Apple to address this specific validation failure in iOS, macOS, and tvOS. (Specific patch version numbers are not stated in the provided text, only that "Apple's Fix" was implemented.)
### Workarounds
- **Client-Side Validation:** Ensure that client configurations (e.g., `wpa_supplicant` configurations) strictly validate the Message Authenticator sent in the final EAP-Success message. (Note: This is primarily relevant for non-Apple systems configured as clients, as the issue was specifically with Apple's implementation.)
- **User Awareness:** Educate users that they must not manually select or trust new network certificates presented during authentication attempts on previously trusted PEAP networks, as this bypass step requires user interaction.
## Detection
- **Indicators of Compromise:** Unexpected successful connection to a known Enterprise SSID when the backend RADIUS server is known to be offline or configured to intentionally fail the MSCHAPv2 validation step.
- **Detection Methods and Tools:** Monitoring RADIUS server logs for unexpected `EAP-Success` responses missing the Message Authenticator attribute when PEAP/MSCHAPv2 is used, although this vulnerability targets the *client* failing to enforce the validation.
## References
- Vendor Advisory (Implied via Apple fix timeline).
- Original Source: SensePost | Understanding PEAP In-Depth (Published 18 April 2019) - defanged: `https[:]//sensepost.com/blog/2019/understanding-peap-in-depth/`
- Exploit Tool Reference: `hostapd-wpe` (used for PoC demonstration) - defanged: `https[:]//github.com/OpenSecurityResearch/hostapd-wpe/blob/master/hostapd-wpe.patch`