Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: End of Days for MS-CHAPv2 - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
End of Days for MS-CHAPv2

Moxie Marlinspike and David Hulton gave a talk at Defcon 20 on a presentation on cracking MS-CHAPv2 with 100% success rate. This protocol is still very much in use with PPTP VPNs, and WPA2 Enterprise environments for authentication.

Moxie's recommendations [1]:

1- All users and providers of PPTP VPN solutions should immediately start migrating to a different VPN protocol. PPTP traffic should be considered unencrypted.
2- Enterprises who are depending on the mutual authentication properties of MS-CHAPv2 for connection to their WPA2 Radius servers should immediately start migrating to something else.

Knowing that MS-CHAPv2 can now be cracked, what alternatives are you considering to secure your now insecure communications? The two alternatives suggested by Moxie are "[...] OpenVPN configuration, or IPSEC in certificate rather than PSK mode."



Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu


523 Posts
ISC Handler
Jul 30th 2012
I believe the same idea can be used to kill off the ntlm (v1) response hash as well as it appears to be constructed in an identical manner...
I haven't worked in the wireless security space for a few years, but I do recall a number of years ago, when we assessed an implementation of wireless authentication, we settled on EAP-FAST and it worked out well.

10 Posts
Am I correct in thinking that WPA2 using PEAP/MSCHAPv2 is still useable as long as the server's certificate is valid? According to a post by skids on that's the case. If you don't validate the server's cert, you are open to MITM, but you were anyway.

If this really blows up PEAP/MSCHAPv2, that will be huge. That's the only way you can do secure wireless without installing shims on windows clients or setting up a PKI for EAP/TLS.

88 Posts
From what I have been able to gather, implementations of 802.1x w/PEAP would be suceptible to brute force attack if they were using a weak RADIUS shared secret. Even though PEAP secures the MSCHAPv2 Handshake inside a TLS session between the client and the RADIUS server from what I can see the TLS session is negotiated with 2 valid pieces of information. 1) the Public key associated with the RADIUS servers private key AND 2) the RADIUS shared secret. There aren't that many choices for Public keys when attempting to associate to an environment that is secured with PEAP. Cycle through the 6-10 most common public certificates using the 20 most likely RADIUS shared secrets and Viola your in like Flynn....

Anybody else have any additional information to share?
5 Posts
Would explicitly listing the RADIUS servers to validate on the client solve the problem of public certs (short of a common CA being compromised and issuing certs for domains it should not issue for)? Windows clients have this setting, and can be set with a GPO.

Either way, I'd agree that the RADIUS shared secret should be long and complicated and very non-human friendly (cut and paste already).

This article has more details. I am curious if using a non-DES algo (MPPE 128 bit for Microsoft IAS/Windows Clients) is secure? It doesn't use DES, but RC4:

Either way, PKI + PEAP-TLS (mutually-validating certificates on each end) appears to be the real secure way to go. I wish there was a PEAP-TLS-MSCHAPv2 option to require both client-side certificates and username/password auth (without extra-add on software).
42 Posts
@ Jason R
Good thoughts on explicitly listing the RADIUS servers used to validate against however in this case I don't believe it would matter which RADIUS server you went after because all you need to attack the infrastructure is which Public Key represents the private Key installed on the RADIUS server and the shared secret. I think a more valid approach would be to stop using publicly accessible certificates and issue your own certificates from a self signed or an internally hosted CA. This would stop the attack vector completely because unknown clients would not have the Public (Root) cert installed for your RADIUS server at all and therefore have no way to form a TLS sessions against it.
5 Posts
@ Jason R
I guess I should have clarified what I meant. In many implementations, you specify the RADIUS server(s) in the Wireless hardware profile for the AP's NOT on the Wireless GPO object that hits the client. In this configuration, the clients have no idea who the RADIUS server is that is validating them, that gets handled through the AP's.
5 Posts
As already mentioned it assumes you have already passed through the TLS authentication with the Radius server. If you can verify the Cert of the server wouldn't that just mitigate this attack completely as it is assuming it can read the data within the tunnel?
2 Posts
@Jason R
MPPE is the encryption scheme used to secure the traffic tunneled via PPTP, MS-CHAPv2 is the authentication scheme used before the tunnel is setup, they keys used in MPPE are derived from the users password and the ChallengeResponse, which it what makes the resulting tunnel insecure via domino effect. A solid breakdown is located here:

My understanding is that MS-CHAPv2 wrapped in PEAP/TLS is performed within an SSL/TLS tunnel, so from a security perspective, you as secure as the SSL/TLS tunnel goes.

My .02

17 Posts
Uhg, fat fingering be d****d:

s/they keys/the keys
s/which it what/which is
s/you as secure/you are as

17 Posts
I am wondering if any of them are secure given that some bot developer could easily add brute force key cracking capability to their software. 10 million computers with 20+ million processors are surely a super computer if harnessed together in a bot.

63 Posts
Thanks everybody for the good feedback. If we are to assume that the MSCHAPV2 handshake is NOT used in any porttion of the setup and teardown of the TLS/SSL session that is created to protect the handshake then I agree the impact to wireless implementations using PEAP is minimal. If,however,there is a way for me to establish the TLS tunnel to the wireless infrastructure THEN, in theory, I can use the MSCHAPv2 weakness to authenticate without actually authenticating right?

Case in point, consider the mechanisms for setting up and tearing down an SSL session with a web server. There is no "authentication" process that happens BEFORE that session is established. The ONLY service the SSL session provides is basic non-repudiation to verify that the web SERVER is who he says he is.

thoughts? Am I missing something? What is going to prevent me from breaking into this wireless infrastructure based on the above scenario?

P.S. I was under the impression that the MSCHAP v2 handshake that happens inside the TLS/SSL tunnel IS the mechanism that provides the underlying security.
5 Posts
@Cypher: My understanding of how PEAP works is that the PEAP session is actually tunnelled from the authenticating node, aka a laptop, etc. (I don't want to call it a "Client" as the AP is the "Client" in RADIUS terms) all the way to the RADIUS server. The AP actually cannot see the authentication. See steps 7 & 8 at 8.3.1 of this link describing PEAP:
42 Posts
@Cypher: I believe the attack requires capturing a hash from a successful authentication session. That suggests you'd have to perform some sort of MITM attack to access the TLS-encrypted session, first. How difficult that is is going to depend on whether certificates are being validated. (My understanding of this attack is not very deep, though, so I may be completely off base here.)
After taking a closer look this attack can be mitigated for wireless PEAP implementations by having a mandatory verification of the server cert. If it can verify the cert then the integrity of the TLS tunnel is ensured and the MsChapv2 process is encrypted in its entirety. If someone does a man in the middle and impersonates a radius server and has the wireless client build a tunnel to them then they can steal their information through this method. At this point I would say it decreases the security of PEAP w/MSCHAPv2 but there are mitigating/compensating controls. I would say that's an acceptable risk.
@Tenchi64 I also come to the same conclusion. Generally, MITM attacks can be prevented by specifying three optional settings in Windows, on the PEAP window:

- Check "Validate server certificate"
- Check "Connect to these servers" and enter the name or IP of the RADIUS server (a wild card character "*" can be used here e.g.nps*
- Select one or many "Trusted Root Certificate Authorities" from the list
- Check "Do not prompt user to authorize new servers or trusted certificate authorities."
(Anything missing?)

Is it then safe to say that environments with these settings in place where never at risk? If this holds true. It may be a sufficient compensating control for some, or at least it buys time for others to implement something else.

Anyone else have a take on this matter?
@Tenchi64 - Thanks for that clarification, I was just going to ask how you "verify the server ceritifcate" since the only mechanism that allows this in the SSL Scenario is the root certificate of the issuing authority that issued the the SSL servers private key. So the "Validate server certificate" check box somehow provides something in addition to this? Do you know what that is exactly? Just from what I understand of the problem I would guess this is the same as the Browser security mechanism that notifies the user that an SSL servers certificate is not verified. If I had to guess, checking the "Validate server certificate" box just ensures that the Server is who it says it is. In other words, before setting up the SSL session with the RADIUS server it uses its Root Certicate to verify that the RADIUS server was in fact issued from the CA that issued the installed root on the client. IF that is a true statement, it doesn't solve the issue of securing the client. We would need the server to authenticate and verify the clients certificate, not the other way around.

Sign Up for Free or Log In to start participating in the conversation!