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) |
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) |
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.
Cheers,
Andrew vonNagy
