End of Days for MS-CHAPv2

Published: 2012-07-30. Last Updated: 2012-07-30 21:36:09 UTC
by Guy Bruneau (Version: 1)
17 comment(s)

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."

[1] https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
[2] https://github.com/moxie0/chapcrack

-----------

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

Keywords: Cracked MSCHAPv2
17 comment(s)

Comments

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...

exorcyst

Jul 30th 2012
1 decade ago

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.

IMFerret

Jul 31st 2012
1 decade ago

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 http://science.slashdot.org/story/12/07/30/167210/new-moxie-marlinspike-tool-cracks-crypto-passwords 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.

John

Jul 31st 2012
1 decade ago

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?

Cypher

Jul 31st 2012
1 decade ago

@Cypher:
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: https://en.wikipedia.org/wiki/Microsoft_Point-to-Point_Encryption

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).

Jason R

Jul 31st 2012
1 decade ago

@ 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.

Cypher

Jul 31st 2012
1 decade ago

@ 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.

Cypher

Jul 31st 2012
1 decade ago

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?

Tenchi64

Jul 31st 2012
1 decade ago

@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: http://esec-pentest.sogeti.com/challenge-vpn-network/decipher-mppe-breaking-ms-chap-v2

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

e.b.

Jul 31st 2012
1 decade ago

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

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

e.b.

Jul 31st 2012
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives