actually I cannot finde any blog post oder new thread discussing the security of PEAP-MS-CHAPv2 in WAP2 secured WLANs, with the backgroud of the new service from CloudCracker.
They talk about cracking every DES3 (which is used by MS-CHAPv2) key in 1 day.
But dosn't PEAP build a secure TLS tunnel for the MS-CHAPv2 authentication? Which encryption is used by the PEAP protocol?
Actually I can't find a good documentation for my questions. Do you have one for me?
I know about the existing issues of PEAP-MS-CHAPv2, but I mostly recommended this to our customers because of the easiness...
Should I now recomend a migration to EAP-TLS?? Or dose PEAP secure this thread?
I don't have an answer but this is on the top of my research list today...
It's WPA2 EAPoL authentication mechanism using PEAP/MsCHAPv2 that is subject to vulnearabilities.
A new exploit have been developped by Moxie Marlinspike:
New Moxie Marlinspike tool cracks crypto passwords
EAP-TLS by nature is not subject to these vulnerabilities. However, even certificates that are marked as 'non-exportable' can be exported on a different machine...
I really believe that safest deployments adopts the IoA (Internet only Access) + VDI (Virtual Desktop) approach. Consequently, there's not real need for strong security on the edge. A branch Office access = home access = Inoternet only. And the Wireless LAN Access is to be secured by a WPA2-PSK that could be changing quarterly.
I have done some limited research, and this attack seems to be an optimization of a known dictionary attack against MSCHAPv2, combined with an attack on the PPTP vpn protocol. Most real an detailed information lacks though at this moment.
This known attack allows someone who has access to the MSCHAPv2 negotiations to perform a brute force attack. This researcher offers an optimized dictionary attack on MSCHAPv2.
The security of PEAP-MSCHAPv2 lies since 1999 when this MSCHAPv2 vulnerability was discovered in certificate validation.
In your supplicant (client configuration), configure:
1) Certificate validation. When your client connects to a malicious AP and accepts a random certificate, enough information is leaked to brute-force (or dictionary) attack (trying all the possibilities) your password.
2) Configure the valid server list. Clients should only authenticate against your own RADIUS servers.
3) Configure the CA trust list to only the CA's that issued your certificates. When someone gets a certificate from a different CA, it will not be accepted.
When configured this way, all authentication traffic is tunneled in a trusted SSL session and an attacker has no access to the MSCHAPv2 information. Brute forcing the user password is not possible against a correctly configured EAP-PEAP client with the information that we have up to now.
Please note that in conference networks, and other networks where end-users configure their clients their selves, it is not possible to prevent (nor detect) users to misconfigure their clients. That will make those clients susceptible to the known attacks against MSCHAPv2; and that results into very juicy publicity.
Again, I have not found the real detailed information on this 'crack'. I suspect this information to become available. Based on that information a better assessment can be done. For now, I am not worried having a network with PEAP-MSCHAPv2 when clients are well configured. This configuration can be enforced in AD environments through Group Policies (GPO); or in other environments with ClearPass Onboard or Quick1x.
I for one don't see much that is new here, other than a new tool that speeds up something that has always been possible. MS-CHAPv2 by itself is not secure - remember Cisco LEAP and how it was broken by Joshua Wright circa 2004?
In WPA2, if you want to break PEAP-MSCHAPv2, you first have to break PEAP. Assuming a properly configured network and client, that's really difficult. Still, if you want to get rid of MSCHAPv2 entirely, a move to EAP-TLS based on certificates will do that and is something we recommend anyway for strong security.
Thanks for the feedback!
just a quick question about it:
If we use the Aruba technology (thin APs with controller) in this case are we threatened or not? In my thought there is a WPA2-Enterprise AES encrypted SSID. So the authentication infos (MSCHAPv2 or else) are encrypted between the client and the controller. After that there can be "open" communicatons but in the air there is everything encrypted, am I right? So if someone need my MSCHAPv2 he/she must to decrypt the AES first.
Please give me some feedback from it!
Thanks a lot!
You are correct. As long as you are using WPA2 correctly, you should be protected.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.