Last week at Defcon 20, Moxie Marlinspike released chapcrack, a tool that implements a new attack against MS-CHAPv2. It was widely reported as an attack on WPA2-Enterprise, but it’s not. In fact, from a Wi-Fi perspective, there’s nothing to see here.
There’s been a great deal of coverage of the attack (see The Register, Ars Technica, FierceCIO, ThreatPost, PC World, and C|Net), much of which has been focused on the assertion that MS-CHAPv2 is widely used in WPA2-Enterprise. Therefore, if MSCHAP-v2 is broken, so is WPA2-Enterprise, and we need to completely replace all Wi-Fi security.
In a word: no.
Yes, MS-CHAPv2 is widely used in Wi-Fi security. Well-known flaws in MS-CHAPv2 led to the development of hybrid authentication methods that provided strong protection for these flaws.
Hybrid authentication combines two authentication methods into one protocol. Typically, in the case of Wi-Fi, the desire is to use a “legacy” (read: old authentication method, and the legacy method is typically based on a username and password. Legacy authentication methods were designed before eavesdropping was as simple as firing up your favorite wireless packet capture tool and recording the traffic. Therefore, the legacy authentication method needs to be protected in a strong cryptographic tunnel. Fortunately, a strong cryptographic tool was readily available in the form of Transport Layer Security (TLS).
Generally speaking, hybrid authentication methods like Protected EAP (PEAP), Tunneled TLS (TTLS), and Flexible Authentication via Secure Tunneling (FAST) are two-step protocols. Step 1 is to set up a TLS tunnel between the client and server, and step 2 is to use the tunnel to protect a legacy authentication method. That legacy method is sometimes called the “inner” method because it runs inside the TLS tunnel established in step 1.
Wi-Fi authentication has two important roles. Like all network authentication, the Wi-Fi security architecture needs to enable the network to validate that a particular user has the right to attach to the network before receiving service. In a hybrid authentication method, user-to-network authentication occurs in step 2.
In Wi-Fi, however, there is a second and equally important authentication. Wi-Fi networks are based on radio technology, and therefore, the user needs to validate that the device on the other end of the radio connection is in fact a network they should be attaching to, and exchanging credentials with. Hybrid authentication methods accomplish the network-to-user authentication in step 1. The RADIUS server, through the network, establishes that it is trustworthy by presenting a certificate that can be validated by the client.
[Important aside: Contrary to common belief, Cisco’s Lightweight EAP (LEAP) is not a hybrid method. It performs an unencrypted MS-CHAPv1 exchange in both the user-to-network and network-to-user direction. Without protection, LEAP was easily compromised years ago, and that drove much of the development of FAST.]
The key to Wi-Fi security is that both parts of the hybrid authentication must be carried out in order to have mutual authentication. When the Wi-Fi security architecture was designed, the TLS tunnel was used to establish trust in the network to the client before the client began the much less secure inner method. This fact is not well understood by many, including the author of the chapcrack tool (see his erroneous insistence that MS-CHAPv2 is used for mutual authentication purposes to John Kilpatrick, Yahoo!’s Wi-Fi administrator, as well as a follow-up that MS-CHAPv2 is used for mutual authentication.)
In fact, the chapcrack tool doesn’t work against MS-CHAPv2 when it’s protected by TLS. I spent time this evening with the tool, and it needs to get access to an unprotected MS-CHAPv2 session to crack. There are two ways to get at the MS-CHAPv2 session. One way would be to capture an unprotected MS-CHAPv2 session between the RADIUS server and the user database. In the hybrid authentication model, the TLS tunnel is terminated by the RADIUS server. If that server then uses unprotected MS-CHAPv2 exchanges against the user database, an attacker could potentially capture them and then recover the user’s password.
It is comparatively rare for a modern user store to support queries via MS-CHAPv2. As one expert I spoke with in the days following the publication of this attack put it, “I always assumed MS-CHAPv2 was only slightly better than transmitting in the clear.” Many of today’s user stores are based on LDAP, and require an LDAP bind to query the database. LDAP sessions are typically protected by TLS.
If an attacker can’t capture the MS-CHAPv2 exchange between the RADIUS server and user store, the attacker could launch a man-in-the-middle attack by sitting in the middle of a security protocol, controlling the entire protocol exchange, and gaining access to communication between the network and the victim.
A man-in-the-middle attack against a hybrid authentication protocol would look something like the following picture. An attacker associates with an access point, and starts the authentication process. Below the network components is a protocol stack, with the attacker’s operations shown in red. After connecting to the target network, the attacker opens the TLS tunnel for step 1 of the hybrid authentication protocol. However, the attacker is not in possession of a set of valid user credentials.
To capture the user credentials, an attacker needs to impersonate the network to a client with valid credentials. It can do so by pretending to be an AP and waiting for a client to come by and begin the authentication process. The client is shown as a tablet in the picture, and its protocol operations are shown in blue. The victim opens up a TLS tunnel to the attacker as step 1 of the hybrid authentication method.
The attacker’s goal is to gain the trust of a victim so that the victim will supply either a password or an equivalent. In this case, the attacker can capture a complete MS-CHAPv2 exchange and use it to recover the victim’s password. Defense against man-in-the-middle attacks may take many forms, but one of the most common is a public key infrastructure. That is, if the victim insists that the access point it is connecting to be validated by a certificate authority, the attacker will be not be able to successfully impersonate the network and carry out the attack.
If the victim, however, does not check that it is connecting to a trusted network and will trust any certificate that is supplied, the victim will supply a password to the attacker. (Or, in this vulnerability, the attacker is in a position to capture an MS-CHAPv2 exchange that readily leads to recovery of the password.)
Validating certificates when using a TLS-tunneling method does not require extensive PKI work. One of the main drivers for the development of PEAP and TTLS was that only RADIUS servers required certificates to be installed, and all clients could receive the certificate authority’s public certificate to validate them.
Running the chapcrack tool against a WPA2-Enterprise network is harder than the documentation makes it sound, for two reasons:
- When clients are configured to validate that the certificate supplied by the network is issued by a trusted certificate authority, they will not respond to the attacker’s impersonation of the network. TLS tunneling hybrid methods do not require extensive PKI work, even in a network with thousands of APs and/or clients because only RADIUS servers require them.
- Even if a client is not properly validating that a network is trusted, the attacker must perform an active attack. The attacker must get within range of both the network and the victim and actively transmit frames, potentially exposing the attacker to detection. In many cases, this will mean the attacker requires physical access to the area where the network is installed.
None of this discussion is to take away the value of the announcement in showing the MS-CHAPv2 is completely broken. Unlike previous attacks against MS-CHAPv2, this is not another dictionary attack. Once you can capture the MS-CHAPv2 exchange, you are guaranteed to recover the password. Some protocols that are used outside of Wi-Fi make it easy to get an MS-CHAPv2 exchange, but nothing in Wi-Fi enables this attack.
How does this attack change the Wi-Fi security landscape? Not at all. WPA2-Enterprise remains a secure protocol. If you trusted it a month ago, you can keep trusting it.