Re: Wireless WPA2 MSCHAPv2

["Shamblin, Quinn" <qrs () BU EDU>]

For reference, the device created by Moxie, et al. can test DES keys at such a rate (one key per clock cycle, per 
system for a rate of billions each second) that they can test the entire key space in less than 24 hours.  I was at the 
talk and there was a lot of interest.  Harry has a good point that this will likely be limited for the moment to for 
people that really want to mess with you, but on the other hand, don't forget to consider the specter of the insider 
threat when assessing your risk.

Moxie also provided clear directions on how to make more of the DES cracking machine that they have put online.  Don’t 
be surprised to see more of them up and running before too much longer.  Even at a somewhat high price tag, it is a 
marketable service.  You know that new research has just been spawned trying to figure out easy ways to capture the 
required data.  Who knows how long some of the protections that we currently have will remain effective now that people 
have a stronger incentive to push for that information.  That said, there is only so much we can do for the moment 
while the industry considers how to address the situation.

Quinn R Shamblin
------------------------------------------------------------------------------------------------
Executive Director of Information Security, Boston University
CISM, CISSP, GCFA, PMP  –  O 617-358-6310  M 617-999-7523


-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Rich 
Graves
Sent: Tuesday, July 31, 2012 3:34 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Wireless WPA2 MSCHAPv2

The only thing that's really new is that there exists a public online service for accelerated DES cracking. When EFF 
trumpeted "DES is dead" 14 years ago, their required capital outlay was about $250,000. Now, it's $0 plus $200 per 
crack, and it's 8 times as fast. If anything, I'm surprised that 14 years only gave an 8x performance boost. Moxie and 
friends had a much smaller budget.

The CloudCrack service makes it practical to get from MSCHAPv2 to the NT hashes no matter how long and complicated the 
passphrases are. The NT hash can then be leveraged to abuse any authentication protocol that requires only the NT hash 
-- NTLM, NTLMv2, Kerberos with RC4-HMAC, PPTP, PEAP. Protocols that do not use the NT hash, such as form-based web 
authentication and Kerberos with AES (the default for Windows machine-to-machine authentication), are not affected. 

If your policy allows passwords 8 characters or less, regardless of complexity, then dictionary/brute-force attacks on 
the complete MD4+DES series are still probably cheaper than cracking DES. (Rainbox table attacks are impossible against 
the first two DES blocks due to the bidirectional challenge; asleap implements a precomputed tables attack against the 
third block, but this is seldom interesting.)

For my institution, $200 still places these in the unlikely-targeted-attack category.

Harry Hoffman:
> What happens in the case of having multiple SSIDs across campus but a 
> single (set) of radius controllers?
>
> Does each SSID have to point to a different radius name??? 

(Why would you do that?)

No. In MacOS, iOS, and Windows, there are independent configurations per SSID. It's perfectly fine to say that 
Walden-South must be signed by Versign and authenticate to radius.walden.edu, Walden-North must be signed by Versign 
and authenticate to radius.walden.edu, etc.

Currently, there seems to be no way to configure an Android device securely for PEAP. 

Steve Bohrer responding to Justin Azoff:

> > AFAIK, if you have people spoofing your SSID and running rogue 
> > authentication servers any weakness in MSCHAPv2 is the least of your 
> > problems..
> I don't have 100% campus wifi coverage, so, it seems it would not take 
> much for a student in a sparsely covered area to hook a home AP to a 
> linux box running FreeRADIUS, and broadcast an SSID matching the 
> college network's. Our server's certificate is our only defense 
> against that, as there are areas where I don't have the coverage to 
> detect or block such systems. (Obviously I need lots more money for 
> campus wireless coverage, so I can blanket any rogues in the 
> vicinity!)
>
> But you certainly are correct, if such a student can get people to 
> authenticate to their server, they'd have no need to bother with 
> cracking MSCHAPv2.

Disagree on both counts.

Spoofing a secure SSID is trivially easy with various Linux pen testing distributions. It does not have to be done in 
an area of poor radio coverage -- you just need to have higher signal strength than an official AP, and you don't even 
need that if you're willing to spoof beacon frames redirecting users to another channel (which is likely to fire off 
wireless IDS alerts). Currently, this requires a higher level of sophistication than FireSheep, but expect that to be 
addressed.

HOWEVER, running a malicious server doesn't get you credentials. MSCHAPv2 is a fairly decent protocol, by 1990s 
standards, with both client and server nonces. The only thing the server gets to pick is the server nonce, which is 
BIGGER than a single DES key, so if the goal is to steal credentials, a malicious server has no advantage over a 
passive eavesdropper.

If the attacker's goals are served by connecting targeted clients to a malicious network, along the lines of 
Karmetasploit or Airpwn, then no, there's no need to crack MSCHAPv2. I consider this risk to be higher. For the 
wireless vector, the defenses are the same: authenticate the network/radius server with the strictest validation 
policies possible in your OS. Secondary passwords or certificates might be worth thinking about, but PEAP, properly 
implemented, is OK.
--
Rich Graves http://claimid.com/rcgraves Carleton.edu Sr UNIX and Security Admin