Hacker News new | past | comments | ask | show | jobs | submit login
Cracking WPA in 10 hours or less (devttys0.com)
160 points by sbierwagen on Dec 28, 2011 | hide | past | favorite | 29 comments



Good God, what a comedy of errors. First, that WPS even lets you get around a 256-bit key with a 10^8 PIN (like others, I thought WPS was pushbutton-only), but second, that this vulnerability brings the brute-force complexity down to 10^4 + 10^3, or 11,000 attempts: http://www.kb.cert.org/vuls/id/723755


Any idea why it splits up the PIN like that? It costs $100 just to download the spec.


See my response below. I think they're trying to protect against potential weaknesses in the HMAC by requiring both sides to prove they know part of the PIN before sending information derived from the second part of the PIN. If a weakness is discovered in the HMAC, this scheme is supposed to allow either side to bail without leaking the whole PIN. This (supposedly) protects against someone spoofing the AP and selecting nonces that allow the PIN to be recovered.


I'm no crypto guy.. is there any conceivable situation in which their idea works? I mean, when is it actually more secure to say 'I'll let you know if you got the first half of the password right before you enter the second'?


Can you, or maybe someone else please explain why it becomes 10^4 + 10^3. My math skills are a little rusty.


10^4 attempts (worst case) to bruteforce the first four digits using the early NACK, 10^3 attempts (worst case) to bruteforce the entire pin once you know the first four (this part only has to iterate on three digits of the second half, and compute the checksum to get the last digit).


Thanks. This explains it perfectly to me.


Not much math necessary for the explanation. Follow the link jaylevitt posted:

When the PIN authentication fails the access point will send an EAP-NACK message back to the client. The EAP-NACK messages are sent in a way that an attacker is able to determine if the first half of the PIN is correct. Also, the last digit of the PIN is known because it is a checksum for the PIN. This design greatly reduces the number of attempts needed to brute force the PIN. The number of attempts goes from 108 to 104 + 103 which is 11,000 attempts in total.


I followed that link before I posted. I was unable to determine what 10^4 and 10^3 represented and the link did not explain it in a way for me to understand. Obtu was able to explain it to me.


They used Diffie-Hellman to prevent offline cracking.


Add "using WPS" to the title please.


Yeah, this is really a WPS vulnerability. As far as I can tell, it just brute-forces the WPS pin number (8 digits), and the routers then provide the WPA key as part of the WPS protocol.


Yes, please. This is a side-channel attack. It should get more exposure so that people get wise and turn off WPS in their APs.


I had no idea that the WPS specification included two PIN number options (client->AP which is this attack and AP->client) - thought it only worked when you pressed the physical button.


But isn't WPS enabled by default on most routers?


I think so, but even if it is, this is not a WPA vulnerability. Relating it to WPA is equivalent to claiming SSH is insecure because someone looked over your shoulder and saw what you did. It's a side-channel attack that gives you the WPA key because WPS literally hands it to you once you guess its (short) password.


There's a detailed description of the weakness in the WPS protocol here: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf

It looks time there are two issues here. The first is that the pin is confirmed in two stages, each of which can be individually NAKed. That brings e complexity down from 10^7 to 11,000. It seems like this could be fixed by always ACKing the first stage and then ACKing/NAKing the second stage based on the result of both stages (unless doing so would somehow lead to leaking information about the PIN).

I think the first issue comes from an attempt at doing mutual authentication. Basically the device (like a wireless printer) wants to tell an access point (AP) that it knows the PIN. But, the device wants to make sure the AP also knows the pin. Otherwise, someone could spoof the AP and say for any connection attempt "yup, that's the PIN, now here's your (fake) configuration". I think they're also trying to cover the case where the HMAC they're using has a vulnerability, allowing a fake AP to discover the secret key by using nonces that expose a weakness in the HMAC.

Instead of just trusting HMACs to do their thing, they break the mutual authentication into stages. The AP and the device each prove they know the first half of the key. If either side fails that test, then the other side refuses to move on, supposedly protecting the second half of the key even if the HMAC is found to be broken. In reality of course, it leads to the attack described above. If both sides just always ACK the first stage, everything is fine as long as the HMAC is secure (which it most likely is). If you're worried about the HMAC being broken, you could use a dummy PIN for the second stage if the first stage fails.

The second issue is that most vendors don't implement lockouts after too many failed attempts. Even if they do, the issue above means a brute-force attack is still possible in a few months' time because of the greatly reduced complexity. Fixing both issues would probably make a brute force attack impractical.

Until both issues are fixed, the best solution is to disable pin-based WPS. Unfortunately many low-cost wireless printers and similar devices require WPS to connect to a secured wireless network. Turning off WPS may make such devices unusable.

It's possible that enabling MAC address filtering will also solve the issue(actually... not).


If you read the originally linked post and paper (linked above), this is a really large scale WPS vulnerability: http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup...


Surely MAC address filtering is well and truly proven to be pointless to any serious attempts to, erm, join your network?

Spoofing MAC addresses is trivial, even under Windows.


Errr, right. MAC addresses are sent in the clear, so filtering is pointless.


Can you leave WPS off most of the time except for the initial connection of 'device A' to the network? Or will device A need it every time it switches on?


Factual error: It is not WPA that is cracked here. It is WPS.


It's interesting that he's using a freemium business model: the commercial version supposedly has more features and speed improvements.

I don't really care whether he does that or not, but I see it as part of a larger trend: open source software supported by a freemium business model.


It can go rather hideously wrong, with the open source version being neglected, downgraded, or simply made non-functional to push people onto the paid version. This was happening for a while with SugarCRM - I don't know if anything's changed there since I last looked, but it feels just like a bait-and-switch.

Where I know of it working well, it's where there are separate legal entities to manage the open source code and the premium version.


Pardon my ignorance, but don't I need to initiate WPS somehow (like pressing the button on the router), or mere presence of enabled WPS feature is enough to start the attack?


Misleading headline. WPA isn't cracked - WPS is, due to its flawed design. Simply disable WPS and your AP is fine.


does this mean wpa/wpa2 is totally unsafe now? or just for pre-shared key method(which is 99% home users use)?


Neither. This doesn't affect WPA2 in any mode, as long as WPS (WiFi Protected Setup) is turned off.

WPA has known vulnerabilities that an attacker can use to cause a router to leak data over its WAN Ethernet port, so it should be considered unsafe at this point. But, that has nothing to do with this attack.


If you're talking about home use - I wouldn't go that far. 99.9% of people won't even know how to run this, and I doubt anyone will try that hard to break into a random home network.

If you have something to hide, obviously, you should take additional precautions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: