Main Nav

Hello Everyone,

Reading through the news, I saw that at Defcon MSCHAPv2  has been effectively compromised. https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ This includes the use of it in WPA2 connections to radius servers for authentication.  Per the article, the current recommendation for enterprise wireless deployments is to move to using client certificates for authentication.

 

It seems that using client certificates for authentication will be difficult for many schools because of the issue of publishing and distributing certificates to user on their multitudes of different devices. Does anyone have any good thoughts or recommendations on migrating to certificate based authentication with the  proliferation of students owned computers and mobile devices we all experience.

 

Thanks,

 

Ben Parker

Network Support Technician

University of Mount Union

330-829-2866

AttachmentSize
PGP.sig508 bytes

Comments

Hi Frank, I have a training meeting at 1:30 that I'm afraid might run late. How about we do next week. Just email me when you know you will be back. Are you trying to do this on your office computer or your Mac? I can try some testing before hand. Caroline "Vulnerability is not weakness. I define vulnerability as emotional risk, exposure, uncertainty. It fuels our daily lives. And I've come to the belief -- this is my 12th year doing this research -- that vulnerability is our most accurate measurement of courage -- to be vulnerable, to let ourselves be seen, to be honest." - Brene Brown ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY@LISTSERV.EDUCAUSE.EDU] on behalf of Steve Bohrer [skbohrer@SIMONS-ROCK.EDU] Sent: Tuesday, July 31, 2012 11:36 AM To: SECURITY@LISTSERV.EDUCAUSE.EDU Subject: Re: [SECURITY] Wireless WPA2 MSCHAPv2
Urg. Sorry. Caroline (slinks away shamefaced...) "Vulnerability is not weakness. I define vulnerability as emotional risk, exposure, uncertainty. It fuels our daily lives. And I've come to the belief -- this is my 12th year doing this research -- that vulnerability is our most accurate measurement of courage -- to be vulnerable, to let ourselves be seen, to be honest." - Brene Brown
On Tue, Jul 31, 2012 at 11:36:46AM -0400, Steve Bohrer wrote: > From http://science.slashdot.org/comments.pl?sid=3014645&cid=40821639 : > "For WPA2-Enterprise the MSCHAPv2 session is usually wrapped in a > PEAP (SSL) session. This should be safe as long as your client is > configured to validate the server-side certificate only against CAs > that are not likely to be compromised (i.e. a rougue cert > generated). Preferably, one should also validate the certificate's > subject (usually the name of the RADIUS server)." AFAIK, if you have people spoofing your SSID and running rogue authentication servers any weakness in MSCHAPv2 is the least of your problems.. I still think WPA should have been designed to require the certificate to match the SSID, not the radius server hostname :-) -- -- Justin Azoff -- Network Security & Performance Analyst
On Tue, Jul 31, 2012 at 12:27:28PM -0400, Steve Bohrer wrote: > >I still think WPA should have been designed to require the certificate > >to match the SSID, not the radius server hostname :-) > > Joking, I hope? Not sure how much weight to give your :-). > > In the above case, I really want our users to know that they have to > look for a specific "simons-rock.edu" certificate before they submit > their password to any RADIUS server. If the certificate merely has > to match the SSID, I don't know how to prevent the case above. To me it makes sense that the SSID would be wpa.simons-rock.edu I've always thought the way WPA works is the same as if https certificates were for the IP address of the server and not the hostname. Imagine if a user connects to https://simons-rock.edu but the browser only verifies that the certificate subject matches the ip address from DNS. What I think makes a lot more sense is that a user would connect to an SSID for wpa.school.edu and the cerficicate would have to match wpa.school.edu. Since a random attacker can not obtain a valid certificate for wpa.school.edu this would be more secure. > Moreover, with eduroam, I really want one of our professors who is > getting online from far away to know that it is a problem if they > are presented with any server certificate except ours. If the cert > merely had to say "eduroam", and could be issued to anyone who might > be running an eduroam AP, I don't think it would have much value. > With the current server-name system, once our users have accepted > our RADIUS server's cert here on campus, they can connect to any > proper eduroam site with no changes, so if they do get _any_ cert > popup it indicates a problem. Eduroam does complicate things, that's the only time I can think of where the user connects to a SSID but they actually see a radius server that is not directly associated with the SSID. -- -- Justin Azoff -- Network Security & Performance Analyst
Message from hhoffman@ip-solutions.net

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??? On 07/31/2012 12:50 PM, Justin Azoff wrote: > On Tue, Jul 31, 2012 at 12:27:28PM -0400, Steve Bohrer wrote: >>> I still think WPA should have been designed to require the certificate >>> to match the SSID, not the radius server hostname :-) >> >> Joking, I hope? Not sure how much weight to give your :-). >> >> In the above case, I really want our users to know that they have to >> look for a specific "simons-rock.edu" certificate before they submit >> their password to any RADIUS server. If the certificate merely has >> to match the SSID, I don't know how to prevent the case above. > > To me it makes sense that the SSID would be wpa.simons-rock.edu > I've always thought the way WPA works is the same as if https > certificates were for the IP address of the server and not the hostname. > > > Imagine if a user connects to https://simons-rock.edu but the browser > only verifies that the certificate subject matches the ip address from > DNS. > > What I think makes a lot more sense is that a user would connect to an > SSID for wpa.school.edu and the cerficicate would have to match > wpa.school.edu. Since a random attacker can not obtain a valid > certificate for wpa.school.edu this would be more secure. > >> Moreover, with eduroam, I really want one of our professors who is >> getting online from far away to know that it is a problem if they >> are presented with any server certificate except ours. If the cert >> merely had to say "eduroam", and could be issued to anyone who might >> be running an eduroam AP, I don't think it would have much value. >> With the current server-name system, once our users have accepted >> our RADIUS server's cert here on campus, they can connect to any >> proper eduroam site with no changes, so if they do get _any_ cert >> popup it indicates a problem. > > Eduroam does complicate things, that's the only time I can think of > where the user connects to a SSID but they actually see a radius server > that is not directly associated with the SSID. >
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
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
Hi, All. It's been stated already in this thread that if your clients are configured to validate the public certificate of the host that terminates your PEAP connection, you're likely in good shape*, but I wanted to add a little description to explain why. PEAP is designed such that if an 802.1x supplicant sees a problem and chooses not to build the TLS tunnel, the MSCHAP exchanges will not begin at all. Digging a little deeper, The PEAP tunnel is a TLS tunnel between a client and RADIUS server (or something else if you're terminating PEAP on your wireless controller, AP, etc...) built in order to allow for a secure exchange of credential information, MSCHAP or otherwise. After this tunnel is built, a negotiation takes place within the tunnel between the 802.1x supplicant and a AAA server to pick an inner authentication protocol. Next, the negotiated credential comparison (MSCHAPv2 in our case) is done within the same tunnel. This is also why attributes sometimes need to be handed back outside the tunnel in some environments--the wireless infrastructure can be unaware of portions of the conversation between the supplicant and AAA server. -Joseph *Most deployments terminate PEAP directly on the RADIUS server, but if you terminate PEAP on a different device, your risk is now increased if the path between your PEAP termination and RADIUS server is not secured. On 7/31/12 6:36 PM, "Steve Bohrer" wrote: >