The exploit successfully compromised a legacy authentication protocol, MS-CHAPv2, which was created by Microsoft years ago. But the vulnerabilities of this protocol (and other similar ones) are well known, and Wi-Fi Protected Access 2 makes use of additional mechanisms to protect them. That protection is still in force, according to both the Wi-Fi Alliance and a wireless architect, who blogged in depth on this issue after the Defcon exploit was reported.
IN PICTURES:
In the wake of the Defcon demonstration, enterprises were being urged by some to abandon MS-CHAP, the Protected Extensible Authentication Protocol (PEAP), WPA2 or all of the above. None of that is necessary.
The Wi-Fi Alliance has reviewed the chapcrack tool and cloudcracker service announced last week at Defcon 20 and these tools do not present an exploitable vulnerability in Wi-Fi CERTIFIED products, according to statement issued by the Wi-Fi Alliance, via Kelly Davis-Felner, the WFA marketing director. These tools exploit previously-documented weaknesses in the use of Microsoft CHAP (MS-CHAP). All uses of MS-CHAP in WPA2 are protected by the Transport Layer Security (TLS) protocol. TLS is the same strong cryptographic technology that protects all online e-commerce transactions. TLS prevents interception of the MS-CHAP messages used in WPA2 Enterprise and effectively protects against attacks using chapcrack or cloudcracker.
Thats a bare bones, but accurate description of why the exploit cant affect a properly set up enterprise WLAN. Andew vonNagy, senior Wi-Fi architect at , fleshed out the description in a post on his personal blog, .
As with almost everything in wireless security, there are conditions and qualifications. But for Wi-Fi networks that are properly using 802.1X authentication, and that have transport layer security properly implemented, then the impact [of this exploit] is essentially zero, vonNagy says.
The reason for that is because enterprise Wi-Fi security is a two-step process, first creating a secure encrypted tunnel, using the aforementioned Transport Layer Security, between the wireless client and a RADIUS server (authenticating the server) and only then using MS-CHAP to authenticate the client. If the first step is properly implemented, and MS-CHAP protected, the Defcon tools are helpless to attack it, according to vonNagy.
The argument he advances in his blog post even assumes that the tools demonstrated at Defcon can in fact crack MS-CHAP completely. His point: It doesnt matter.
Heres why.
As Microsofts own webpage , PEAP is one member of a family of Extensible Authentication Protocol (EAP) protocols. It relies on Transport Layer Security (TLS) to create an encrypted channel between an authenticating PEAP client, for example a laptop or tablet, and a PEAP authenticator, in this case an enterprise Remote Authentication Dial-In User Service (RADIUS) server. PEAP can work with a variety of EAP authentication methods, one of them being EAP-MS-CHAPv2, which work inside the encrypted tunnel.
This tunneling occurs by relying on asymmetric cryptography through the use of X.509 certificates installed on the RADIUS server, which are sent to the client device to begin connection setup, vonNagy says in his post. The client verifies the certificate is valid& and proceeds to establish a TLS tunnel with the server and begins using symmetric key cryptography for data encryption.
Only then, once the TLS tunnel is fully formed, do the client and server make use of the less secure protocol such as MS-CHAPv2 to authenticate the client. This exchange is fully encrypted using the symmetric keys established during tunnel setup, vonNagy says. The encryption switches from asymmetric key cryptography to symmetric key cryptography to ease processing and performance, which are much faster this way. This is fundamentally the same method used for HTTPS sessions in a web browser.
VonNagy created a to show the stages of this interaction. Reading from the top down, there is the initial association of the Wi-Fi client with the access point; then the start of the TLS tunnel negotiation between the client and RADIUS server; the creation of the tunnel between them; and then the MS-CHAPv2 challenge by RADIUS, and the corresponding, authenticating response by the Wi-Fi client.
The key link in this chain then is the mutual authentication between the RADIUS server and the wireless client, vonNagy says. The client must properly validate the RADIUS server certificate first, prior to sending its credentials to the server.
And therein lies the potential vulnerability. If the client fails to properly validate the server, then it may establish an MS-CHAPv2 session with a fake RADIUS server and send its credentials along, which could then be cracked using the exploit that was shown at Defcon, says vonNagy. This is a classic man-in-the-middle attack, with the attackers inserting their RADIUS server in the middle of a conversation between the client and the user database store (typically a directory server).
So the critical thing is to ensure that the client properly validates the RADIUS server. This is done via trusted certificates, deployed either by the client platform vendor and PKI systems such as Entrust, Thawte, Verisign and others, or by network administrators using tools such as Microsoft Group Policy Objects, Apples Lion Server Profile Manager for OS X clients or iPhone Configuration Utility for iOS clients.
What vonNagy then focuses on is enabling Microsoft and Apple clients to accept specific trusted certificates and no others, while at the same time blocking them from manually accepting untrusted certificates. For example, when an Apple iPhone tries to associate to a Wi-Fi access point -- and no profile has been deployed to the client for that SSID -- the user receives an onscreen prompt that declares the server as not verified but then offers a button to accept the connection and proceed anyway.
This is likely not ideal, since users typically have a hard time distinguishing what a certificate means and whether or not they should proceed, vonNagy says, with classic understatement.
Instead, for corporate networks with 802.1X authentication deployed, all clients including personally owned devices, should be loaded with a profile for each 802.1X SSID that the user will need, vonNagy recommends. Then, if the client is presented with an untrusted certificate, the connection will be rejected automatically. On the iPhone, for example, a popup informs the user Unable to join Network Aruba1X and presents only a Dismiss button to cancel the popup.
Don't fall into the trap for BYOD of letting users connect on their own and try to decipher the certificate prompt, vonNagy warns. Establish a sound personal device on-boarding process which deploys a configuration profile to the device upon successful enrollment and policy acceptance. There are numerous ways to do this, ranging from simple solutions such as sending them a profile in an email or providing a web URL where users can download the profile, to more complex solutions such as MDM integration that allow self-registration and zero IT involvement.
This binding of certificate to SSID is still a manual process. A better solution is needed, he says. In addition, Wi-Fi clients today cant check to see if a certificate has been revoked. The IEEE 802.11u extensions to Wi-Fi will eventually provide a mechanism for this.
VonNagys conclusion: In a properly implemented wireless network, this MS-CHAPv2 exploit is a non-issue. There is no need for Wi-Fi network administrators to abandon PEAP. Period.
John Cox covers wireless networking and mobile computing for Network World.Twitter: : john_cox@nww.comBlog RSS feed:
in Network World's Wide Area Network section.