sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability -> sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/
I noticed a few really bad design decisions which enable an efficient brute force attack, thus effectively breaking the security of pretty much all WPS-enabled Wi-Fi routers. As all of the more recent router models come with WPS enabled by default, this affects millions of devices worldwide.
Brute forcing Wi-Fi Protected Setup - Please keep in mind that the devices mentioned there are just a tiny subset of the affected devices. I would like to thank the guys at CERT for coordinating this vulnerability.
Reply 2 "will be released once I get around to cleaning up the code" For most people this means "never". I'd rather get a chunk of dirty code and try to figure it out than have to try to re-implement this attack from scratch.
In fact, since it's such an important part of the paper, arguably the code "not being ready" means the paper isn't, either. But even if you disagree with that, then this still leaves people shorthanded verifying a) their devices are vulnerable and b) they've successfully mitigated the problem by turning off the feature. Wouldn't be the first time shoddy firmware says one thing but does another. As such, the only remedy now is to take every last AP offline until someone gets around to releasing a tool to check mitigation.
Reply 3 If the code is not ready, in the interim it would at least be useful to have a way to confirm whether a particular access point implements the "External Registrar" method of WPS. Looking at several of the ones in my possession, it was unclear which ones are affected. One device has the Push Button Connect physical button but it does nothing and manufacturer documentation says WPS is not implemented and is reserved for future use. Another device has no physical button but implements the "Internal Registrar" method of WPS through the network admin interface, and may also implement the External Registrar method, but I have no way to easily confirm that.
Reply + I tried running your code but seems not to be working on my system. when I try to run the script it says it can't associate and reports the correct essid.
I've only tested it against Atheros ath9k drivers and the Realtek drivers for the Alpha cards, so both of those work fine, but others may not work. Switching to something like lorcon for packet injection will probably fix these types of issues...
The other mitigation that should be recommended is to never send EAP-NACK in response to the first half of the PIN. Always send the second half of the negotiation, and send EAP-NACK in response to the second half of the PIN if either half was incorrect. That brings the required number of brute force attempts back up to 10^7, which means it will take over 150 days to search the entire space with your assumed attack time of 13 seconds per attack, even without any lock down (or 75 days, on average, to find the PIN). Rather than a complete lock down after a few failed attempts, I think it would be better to introduce a delay after receiving a few (5 or 10) failed attempts. This has the advantage that a legitimate client with the correct PIN can still authenticate, even if the device is under a brute force attack. A 30-second delay strikes me as a good compromise between resistance to brute force attacks and responding to legitimate requests. If it's difficult for the attacker to spoof their MAC address, then a per-MAC-address complete lock down is even better. It can provide a much longer average time to find the PIN (a 60-minute lock down after 5 failed attempts leads to a 114-year average time to find the PIN) while still allowing legitimate clients with a different MAC address to authenticate. But if the attacker can send each request with a different MAC address they can bypass the lock down.
Reply + MAC spoofing is trivial -- so trivial that it should never be used as the basis for security. A network card's MAC address can be changed in microseconds, and there are about 281,474,976,711,000 addresses to choose from.
Are you sure that all of these routers leave WPS on all the time? WPS is only supposed to be "on" when the person presses the physical or virtual button on the router to start a WPS transaction. What's supposed to happen is the router only does WPS for a certain window period after the button is pressed on it.
Reply + Yes I am sure that the PIN - External Registrar option does work all the time. WPS supports different configuration options and only one involves a physical button.
someone would eventually hit the button which was the linksys logo that wouldn't make you think it was a button when someone just needed to move it out of the way because there was shitty locations for wireless routers). Instead of typing in different pins for every device, i always though it was easier to name a wireless network and give it a password with any of the encryption choices offered (just not wps).
If an AP supports external PIN registration for an unlimited time, that would be a problem regardless of an efficient brute-force attack. However, the claim that this will affect all WPS routers is overreaching. Even in your limited tests you hit one that malfunctioned before letting you in. I know Apple APs don't support adding clients without taking action on the AP, so the "all of the more recent router models come with WPS" claim also goes too far.
to Viehbck, he took a look at WPS and found "a few really bad design decisions which enable an efficient brute force attack, thus effectively breaking the security of pretty much all WPS-enabled Wi-Fi routers.
No doubt the various hardware vendors will take a long time to rollout any firmware update. What really worries me is that some only seem to keep updating firmware for a year or two after release and then completely stop, which leaves a lot of kit vulnerable to old exploits that could and should be easily fixed.
I consider it VERY unscholarly to release this paper without backing up your theses by providing your "brute force tool". This would have made verification of your paper possible more easily. Being a scholar yourself you should do better than this.
Thе vulnerabilities identified bу security researcher Stefan Viehbock affect a generous number οf WPS-enabled routers аnԁ wireless access points.
vrejtjen e vet CERT-i thirret n rezultatet e hulumtimit t kryer nga eksperti pr siguri Stefan Viehbock, i cili zbuloi lshimin n Wi-Fi Protected Set-up, respektivisht n protokollin WPS.
You forgot that "the 8th digit of the PIN is always a checksum" applies also to the raw brute force combination calculations for the whole PIN, not just the calculations for forcing the two parts of the PIN separately, so the maximum possible authentication attempts figure should only have been 10^7, not 10^8.
|