Re: Wireless WPA2 MSCHAPv2

[Rich Graves <rgraves () CARLETON EDU>]

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