07-30-2012 06:26 AM
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?
07-30-2012 12:23 PM
It's WPA2 EAPoL authentication mechanism using PEAP/MsCHAPv2 that is subject to vulnearabilities.
A new exploit have been developped by Moxie Marlinspike:
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.
07-30-2012 01:32 PM
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.
If you have urgent issues, please contact your Aruba partner or Aruba TAC.
07-31-2012 06:49 AM
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.
Jon Green, ACMX, CISSP
08-07-2012 01:37 AM
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!