Tuesday, July 31, 2012

Is WPA2 Security Broken Due to Defcon MS-CHAPv2 Cracking?

Quick answer - No. Read on to hear why.

A lot of press has been released this week surrounding the cracking of MS-CHAPv2 authentication protocol at Defcon. For example, see these articles from Ars Technica and CloudCracker. All of these articles contain ambiguous and vague references to this hack affecting Wi-Fi networks running WPA2 security. Some articles even call for an end to the use of WPA2 authentication protocols such as PEAP that leverage MS-CHAPv2.

But they fail to paint a true and accurate picture of the situation and the impact to Wi-Fi networks. I think this is misleading, and that any recommendations to stop using PEAP are flat-out wrong!

So let's clarify things.

Is MS-CHAPv2 authentication broken? 
Answer - Based on what I've read, let's assume it is TOTALLY broken. You can read about the details in those other articles. But for the topic of this post, applicability to Wi-Fi networks, it really doesn't matter if it is broken or not.

What is the Impact to Wi-Fi Network Security?
Specifically, does this make much of an impact for Wi-Fi networks where 802.1X authentication is employed where MS-CHAPv2 is used (namely EAP-PEAPv0 and EAP-TTLS)?
Answer - No, it really does NOT. The impact is essentially zero.

* Update - Microsoft has released a security advisory which recommends the use of PEAP encapsulation to mitigate this attack against un-encapsulated MS-CHAPv2 authentication. 

Let me explain why.

EAP Tunneled Authentication Protocols
MS-CHAPv2 is only used in what we call "tunneled authentication protocols," which includes EAP-PEAPv0 and EAP-TTLS. These EAP protocol specifications acknowledge that many insecure and legacy authentication methods need protection and should not be used on their own. They deal with that by wrapping the insecure protocol inside of another, much more secure, TLS tunnel. Hence, these protocols are called "tunneled authentication protocols."

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. The client verifies the certificate is valid (more on that in a second), and proceeds to establish a TLS tunnel with the server and begin using symmetric key cryptography for data encryption. Once the TLS tunnel is fully formed, the client and server use 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. 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.

Here is a reference ladder diagram of PEAP authentication which highlights the different phases of the connection process (outer TLS tunnel setup and inner MS-CHAPv2 authentication).

PEAP Ladder Diagram
(Click for full size image)
So, MS-CHAPv2 is not used natively for Wi-Fi authentication. We're safe right? Only if implemented properly.

Importance of Mutual Authentication
The key link in this chain then is the mutual authentication between the RADIUS server and the wireless client. The client must properly validate the RADIUS server certificate first, prior to sending it's credentials to the server. If the client fails to properly validate the server, then it may establish an MS-CHAPv2 session with a fake RADIUS server and send it's credentials along, which could then be cracked using the exploit that was shown at Defcon. This is commonly referred to as a Man-in-the-Middle attack, because the attacker is inserting their RADIUS server in the middle of a conversation between the client and the user database store (typically a directory server).

RADIUS Server Validation and Exposure to Attack
(Click for full size image)
The RADIUS server is validated as long as the certificate that it sends is trusted. For most client platforms, trusted certificates are provided by the manufacturer for public Certificate Authorities and PKI systems (such as Verisign, Thawte, Entrust, etc.) and are held in the certificate store or keychain on the device. In addition, for corporate environments, administrators can deploy certificates to managed devices in a number of different ways to enable trust for private Certificate Authorities and PKI systems, most common among these methods are Group Policy Objects (GPO) for Microsoft clients and Lion Server Profile Manager or the iPhone Configuration Utility (iPCU) for Apple clients (including OS X and iOS devices).

Enabling Server Certificate Validation on Clients
In Windows the RADIUS server validation is defined within each SSID profile. If you are looking directly on a Windows 7 workstation, you will want to view the SSID properties, select the Security tab, and go into the PEAP settings. Enable server validation, specify valid server names (which are checked against the Common Name - CN within the server certificate presented to the client), restrict which Root CAs the server certificate can be issued from, and prevent the system from prompting users to accept untrusted certificates (which is important, otherwise they could unknowingly accept a bad certificate and connect to an attacker's RADIUS server).

Windows RADIUS Server Validation

In Apple devices, including OS X Lion, Mountain Lion, and iOS, use the Lion Server Profile Manger or iPCU to define a configuration profile which includes credentials and a Wi-Fi policy. I'll show the iPCU in this example. First, add the Root CA certificate into the "Credentials" section. Next, define a Wi-Fi policy which specifies the trusted certificates and certificate names allowed.

Apple RADIUS Server Validation

Client Behavior for Server Validation
In both vendor implementations, the behavior of the client device is dictated by what policy has been defined on the system.

If no policy for the SSID has been defined or pushed to the client device by an administrator, the default behavior is to prompt the user to validate the certificate. This is likely not ideal, since users typically have a hard time distinguishing what a certificate means and whether or not they should proceed. For example, when an Apple iPhone attempts to join a network when no profile has been deployed for that SSID, the user receives a prompt to accept the connection and proceed:

iPhone Certificate Prompt

Therefore, for all corporate 802.1X environments, it is recommended to push profiles for all 802.1X SSIDs that end-users need on their systems. This goes for both production access and BYOD scenarios. The behavior on Windows 7, OS X Lion / Mountain Lion, and iOS devices when a profile has been installed for a specific SSID, is to check the local certificate store or keychain to validate the RADIUS server certificate. It must also match the Root CAs and server names specified in the deployed profile. In the event that an untrusted certificate is presented, all of these systems will NOT prompt the user and the connection is rejected. For example, here is rejected connection by an Apple iPhone for an SSID that has had a profile deployed by an administrator:

iPhone Certificate Rejection

Outstanding Vulnerabilities
You should still be aware of a few indirectly related vulnerabilities that have not yet been resolved relating to Wi-Fi authentication with 802.1X.

First, the default behavior of all systems (especially personal devices) is to prompt users to validate the RADIUS server certificate. This is often confusing and can lead to bad actions being taken by users and attempted authentication through an attacker's RADIUS server. This can be mitigated by having corporate environments deploy configuration profiles for all SSIDs in their network, both production and BYOD. Don't fall into the trap for BYOD of letting users connect on their own and try to decipher the certificate prompt. 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.

Second, certificate binding to the SSID is still a manual process on wireless networks. It must be defined within the configuration profile. This is in contrast to SSL and TLS protocols that are used for secure web access where the end-user system can automatically verify if the FQDN within the URL matches the Common Name presented in the certificate. The manual binding process in Wi-Fi networks is born out of a lack of extensibility within the PKI system to handle network access scenarios such as this. A better solution is needed.

Finally, certificate revocation checking cannot occur by Wi-Fi clients since they do not yet have a network connection with which they can query a CRL distribution point or use OCSP. This means that client devices cannot check the status of the presented server certificate to see if it has been revoked, which could be caused by valid certificates that have subsequently been compromised or certificates that were invalidly issued by a CA. However, there is hope that the forthcoming 802.11u extensions to Wi-Fi can provide the means for this to occur through message exchanges prior to full network connection (thanks to Christopher Byrd for pointing this out to me during a Twitter conversation).

Revolution or Evolution? - Andrew's Take
We've known that MS-CHAPv2 is an insecure protocol for a long time. The recent Defcon exploit has just taken that one step further. Development of modern Wi-Fi security recognized the possible value in using legacy protocols such as these. Therefore, EAP protocols that employed such protocols were designed to tunnel the insecure protocol within a much more robust protocol such as TLS. These "tunneled authentication protocols" such as PEAP ensure protection for these insecure protocols through the use of certificates.

The onus for proper security then falls on RADIUS server validation to ensure the other end of the connection is trusted before allowing the client authentication to proceed. 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.

Security is a complex field. It may be hard to distinguish the FUD from fact. If you're interested in learning more about Wi-Fi security, then I highly recommend engineers take training provided in the CWSP (Certified Wireless Security Professional) course offered by CWNP, Inc. or the SEC-617 (Wireless Ethical Hacking, Penetration Testing, and Defenses) course offered by the SANS Institute.

Andrew vonNagy


  1. Excellent article Andrew, thank you!

  2. Andrew,
    Well written and explained as usual. I agree with your conclusion. One point I want to add is that mis-informed articles and news headlines (as you linked to) are incorrectly associating Marlinspike's "WPA2-Enterprise" and "MS-CHAPv2" references with PEAP and EAP-TTLS. Marlinspike is being intentionally ambiguous because his attack/tool will receive more press that way--unfortunately, by being ambiguous, he's bred confusion and incorrect conclusions. But, I don't think he's talking about PEAP or TTLS at all. He's talking about LEAP. He makes the point that previous MS-CHAPv2 attacks have been focused on dictionary attacks, pointing to ASLEAP as an example. But his point is that people have trusted PPTP and LEAP for a long time because they can still use long, complex passwords and avoid normal offline dictionary attacks. His Defcon chat was all about demonstrating that the protocol itself is fundamentally broken and the original password can be recovered regardless of its length/complexity.


    1. Actually, thinking about this more... The Wi-Fi Alliance WPA2 certification program does not include interoperability testing or certification for LEAP as an authentication protocol. So when the articles state WPA2 Enterprise Wi-Fi networks, they implicitly are excluding LEAP from their analysis impact and giving a clear impression that other protocols such as PEAP are vulnerable. They likely didn't know they were doing this, but it is still confusing and misleading.


  3. Andrew,

    Thanks much for this. The tech press likes to sensationalize these things regardless of the actual real world impact. I also appreciate that you spent some time detailing the need for strong server-side cert validation and a robust PKI.

    This is very important for Hotspot 2.0 / Passpoint, as EAP-TTLS w/MS-CHAPv2 is the only real alternative to SIM or USIM authentication mechanisms in the short term. (I'm dubious that client-side certs with EAP-TLS will prove scalable). And as EAP-TTLS support is mandatory for all handsets in the HS2.0 Tech Spec, I expect to see some creative implementations to exploit it.

    Very intrigued by Chris' thoughts on using ANQP exchanges to do the OSCP checking prior to setting up the TLS tunnel. That's a great example of how GAS/ANQP will prove useful to enable enhanced services.


  4. Yes, agreevwith both u and Marcus. This week I have received a fewvconcerns with subject "MSCHAPv2 insecure". The idea of tunneled protocols is to send inner-eap credentials within a securevTLS tunnel... The integrity of that tunnel lies on the wireless supplicant and radius server.. The following may help:
    - validate server certificate
    - enable the Enable Identity Privacy with string Anonymous to,obscure the TLS tunnnel Id (visible in packet captures)..
    - use digital client certificates..

    To be honest, it is easier to attack clients rather than infrastructure.... I.e deauth clients, identify open preconfigured WLAN profiles and invite clients to your sttractive WLAN network....

    My 2 cents...

  5. Hi,

    Moxie Marlinspike published the SSLstrip application back in 2009.


    When reviewing how this application is working you'll understand that it exploits the Certificate Trust Chain mechanism. This means that any Wireless LAN client that is unable to validate the Trust Chain can be lured and could connect to an Evil Twin infrastructure.


    Windows 7 is the only Wireless LAN client I know that is capable of validating intermediate certificates. But, this implies deploying all intermediate certificates on the workstation.

    Consequently, the only real alternative to somehow guarantee that a client workstation will not be lured by an evil twin is to create a private root CA and control how certificates are being distributed. But, this implies deploying the root CA on all client workstation for them to be able to validate the RADIUS server authenticity.

    This means, that when the TLS tunnel is established with an evil twin infrastructure, it is possible to capture the MsCHAPv2 handshake. And that's where this new ChapCrack tool comes into place.

    My current line of thoughts regarding overall security is now the following: The only thing that can really be trusted is what's in the Data Center. The use Virtual Desktop becomes a priority. Each branch office should be considered as a big home office connected to an Internet Only Access (IOA). Consequently, securing end point accesses with 802.1X becomes less important and depending on the enterprise type of business, it is sometimes not relevant anymore.

    Best regards,

    Paul Gallant, Eng.

    1. Hi Paul,
      I agree with your statements and the research that you linked to.

      However, corporate environments typically DO deploy private PKI infrastructures, and most MDM solutions on the market today can either integrate with a private PKI infrastructure or use their own private PKI (typically for simplicity for smaller customers). Part of deploying configuration profiles to devices includes the Root and Intermediate CAs along with the WLAN profile settings. So I think a good solution for any organization is to deploy a private PKI of some form for WLANs, at least for corporate issued devices and BYOD type personal devices.

      Public PKI systems and certificates are another matter. Guest networks may use PEAP and rely on public certificates, but often are simply open with captive web portals of some form. So, I don't think it's a big issue today. But it could become more of an issue with HS2.0 deployments. I'll also have to do some research on how this interacts with the 802.11u features being brought to market with HS2.0.

      Also, I'm not positive if various operating system supplicants check the "basicConstraints" field in the certificate or not. That's something that I will have to do more research on. But thanks for pointing this out.


    2. Doing a bit more research on the client server validation for Windows devices, I found this:

      Clients validate various settings in the certificate based on the CryptoAPI checks enabled in the remote access policy or network policy:

      And, the CryptoAPI has a function called "CertVerifyCertificateChainPolicy":

      Which includes checking basicConstraints in the certificate with the "CERT_CHAIN_POLICY_BASIC_CONSTRAINTS" parameter:

      In that last link, the basicConstraints parameter is listed with others as "predefined" in the function call, so I'm hoping that means that it is always checked by default. I'd need to perform testing to be positive.

      It should also be noted, that clients should verify that the EAP server presents a Cryptobinding TLV to ensure that both outer and inner EAP methods are performed by the same entity.


  6. Hi Paul,

    Nice links. Your statements imply greater importance on validating server certificates to reduce the chance of being victim to Evil Twin Attacks.In Win7 you can also specify the CA server IP/hostname.

    Anyone considering allowing Macbooks on the network?

    ManY thanks,

  7. Awesome article !

  8. In terms of pki supporting WiFi,could just add the SSID as alternate name, like rfc822name, dnsname and UPN. Technically, SPN would seem appropriate for Ssid. Personally for business would consider using open WiFi and putting all devices on a vpn, because that approach is likely safer. Most WiFi routers seem to run antique Linux without security patches, plus vpn allows remote access.

  9. vpn on wifi is silly

    1. Agreed! VPN over WiFi is an old approach that results in poor user experience and mobility. And unless it's auto-launched it can leave users open to direct attacks on open WiFi networks.

  10. This comment has been removed by a blog administrator.