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
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'?
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).
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.
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.
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.
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.
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).
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?
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?
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.