“An attacker could have impersonated a WiFi access point, offered to authenticate with LEAP, broken the MS-CHAPv1 hash, and used the derived credentials to authenticate to the intended access point even if that access point supported stronger authentication methods,” Apple said in its security advisory for iOS 8.
The vulnerability stems from Apple’s implementation of the WPA2-Enterprise security protocol that’s widely used on corporate wireless networks because it allows clients to have unique access credentials instead of using a preshared password like in the case of WPA2-Personal, the wireless security protocol used on home networks.
WPA2-Enterprise supports multiple authentication schemes, with the most common being the PEAP (Protected Extensible Authentication Protocol), which combines the Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAPv2) with the TLS (Transport Layer Security) encryption protocol.
At the Defcon hacking conference in 2012, security researcher Moxie Marlinspike launched a cloud-based service for cracking captured MS-CHAPv2 handshakes in under a day, raising security concerns for virtual private networks that use the PPTP (Point-to-Point Tunneling Protocol) and wireless networks that use WPA2-Enterprise.
The Wi-Fi Alliance and other wireless network experts responded at the time that despite MS-CHAPv2′s weakness to brute force attacks, wireless networks using WPA2-Enterprise with PEAP authentication are not at risk because capturing MS-CHAPv2 handshakes from such networks would first require breaking the TLS encryption.
However, researchers from the University of Hasselt (UHasselt) in Belgium found that Apple devices running iOS and Mac OS X also support an older and insecure WPA2-Enterprise authentication method called LEAP (Lightweight Extensible Authentication Protocol) that doesn’t use TLS and relies on MS-CHAPv1. According to them, this exposes Apple devices to a dumb-down authentication hijacking attack even if the wireless network is configured to use PEAP.
In a research paper presented in July at the 7th ACM Conference on Security and Privacy in Wireless and Mobile Networks, the UHasselt researchers explained that MS-CHAPv2 server-to-client challenges can easily be converted into MS-CHAPv1 challenges. Similarly, MS-CHAPv1 challenge responses can be converted to MSCHAPv2 responses.
An attacker could set up a rogue wireless network with the same name (SSID) as the real enterprise network they wish to target, but requiring LEAP authentication instead of PEAP. When two wireless networks have the same SSID, devices will automatically attempt to connect to the network that has a stronger signal, a behaviour that attackers can exploit in a so-called evil twin attack.
When an Apple device attempts to connect to the attacker’s access point, the attacker can initiate a connection to the real access point using a separate wireless client. He can then take the PEAP MS-CHAPv2 challenge issued by the legitimate access point, convert it to a LEAP MS-CHAPv1 challenge and relay it to the Apple device through the rogue access point.
The Apple device will use its stored authentication credentials to generate a valid MS-CHAPv1 response and send it back to the rogue access point. The attacker can capture this response, convert it into MS-CHAPv2 and use it to authenticate on the real access point.
The attacker essentially hijacks the identity of the Apple device and gains access to the corporate network without having a valid user name and password, the UHasselt researchers said in a separate document with answers to frequently asked questions.
Upgrading to iOS 8 will fix the problem for iPhones, iPads and iPods that support the new OS version, but Mac OS X devices are also vulnerable to this attack. The researchers tested the attack successfully on Mac OS X 10.8.2, but believe all current versions of Max OS X are affected because they share the same wireless implementation as iOS.
The research paper describes several possible mitigations, including the use of different TLS-based WPA2-Enterprise authentication methods that also require the validation of client-side certificates – for example EAP-TLS. This would prevent the attacker from impersonating a client, but would require separate TLS certificates for all authorised devices to be installed on the access point. Another solution would be to use a wireless intrusion prevention system to scan for LEAP requests, which would indicate the presence of a rogue access point.