10

I was reading about Reaver and wi-fi protected setups (WPS). In my Netgear router I have the option to disable the WPS pin code, but still have the WPS push button enabled. Am I secured with such configuration?

Or does Reaver also attack WPS without the pin?

  • If you are worried about Reaver it means you should verify you are using the most current firmware offered by Netgear for your router. Once you do that just disable ALL WPS, WPS at the very core is not secure, and there is only one implementation that is secure and its not used by Netgear. – Ramhound Aug 27 '12 at 15:46
5

If Netgear has implemented it properly, WPS Push-button-connect should be secure. However, I have no idea whether Netgear has implemented it properly, and if they haven't, you might be insecure.

The known attack on WPS is described in this paper:

For another great explanation, see also:

The attack described there breaks the PIN-based forms of WPS. It is not effective against a properly implemented version of WPS Push-button-connect (PBC), because a remote attacker cannot physically push the button your router, and WPS PBC requires someone to press the button before it can proceed.

Therefore, if Netgear has implemented WPS PBC correctly, and has properly disabled all the other forms of WPS, you should hopefully be safe (fingers crossed).

(Do make sure you are running the latest version of the Netgear firmware. The WPS attacks were only discovered less than a year ago, so versions of the firmware written before the attack was discovered are very likely to be vulnerable.)

That said, router vendors have screwed this stuff up before. The bad track record, and the fact that it is not easy for an average user to tell whether they've finally gotten it right this time, does give some room for concern. I think it would be understandable if this makes some security folks throw up their arms in disgust and say "oh, to heck with it, just turn off WPS, I don't trust the router vendors to get this right".

So, how much do you trust Netgear to not screw this up?

  • To be fair, Netgear were the least hopeless. The PDF you linked to says their mitigation would increase the time-to-crack to about a day. That was before the vulnerability was released. I think they scored well in having options. And the – sourcejedi Aug 27 '12 at 17:07
  • @D.W. - I actually think you are mistaken about the WPS Push-button-connect version of WPS being secure. If I am not mistaken depending on how the WPS Push-button-connect is actually implemented there are insecure ways of doing it. The "proper" way is the code is generated by software, the only implementation done that way, is used by Apple. It was already discovered there is no way to "fix" WPS so the feature itself is 100% flawed and is likely...hopefully dropped entirely. Everything else you say is 100% correct. The Security Now eps on this issue might be a good resource for the author – Ramhound Aug 28 '12 at 13:22
  • 2
    @Ramhound, Interesting. Do you have a reference to the vulnerabilities in WPS Push-button-connect? My understanding is that WPS Push-button-connect does not have any PIN, so the PIN-guessing attack found by Viehböck does not apply. Have I misunderstood? Or is there a different attack that I'm unaware of? (I'm not sure what you meant by "the code"; as far as I know, WPS PBC does not use a PIN. Have I misunderstood?) – D.W. Aug 28 '12 at 18:44
0

You can check the list below for your router model. Most NetGear routers listed are vulnerable but WPS PIN can be turned off.

WPS flaw vulnerable device list

0

Push-button setup is safer, but there are still at least a few theoretical attack scenarios. Off the top of my head I can come up with:

  • A patient attacker could conceivably wait for the setup process to occur and potentially disrupt communication from the client attempting to authenticate, then initiate an authentication attempt from a malicious client before the WPS button is pressed. The user may believe the process simply failed, attempt again, and assume by their success on the second attempt, assume nothing is wrong. This is especially viable when/if the attacker observes a new device being brought into the home or office, since they can assume you will need to connect that device.

  • A less patient attacker could disrupt communication with an already authenticated device in the hope the end user will attempt to fix the problem by performing the setup process again, and then try to authenticate instead of the authorized device as above. This is particularly likely if the authenticated device is a printer or other similar hardware on which passphrase authentication is more difficult.

I wasn't able to easily find information on what if any mitigations are employed by vendors, but since the hardware button typically doesn't offer a sufficiently clear indication of which device was authenticated or of whether a device successfully authenticated, it's at least a plausible scenario.

These sort of attacks might be difficult/impractical, but any unnecessary attack surface is a risk, so, it's preferable to not use WPS at all.

Disable it entirely, even in the push-button form, unless you have a device where you are forced to use it by not having the ability to enter a passphrase. If you have such devices, make it a priority to replace them, and try to avoid them in the future.

If you already have devices that force the use of WPS by providing no way to enter a passphrase, such as some printers, then you will have no other choice but to keep WPS turned on. In this case, minimize your risk by disabling both the PIN and the external button if at all possible . Use the access point or router's password-protected web interface to complete the setup process and use that interface to visually confirm which device was authenticated. Be suspicious if the WPS setup process unexpectedly fails. Finally remember, as with any wireless network, regularly checking for unauthorized devices on your network is an important part of keeping it secure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.