Home > Security > Crypto Interrupted: Data On The WPS WiFi Break

Crypto Interrupted: Data On The WPS WiFi Break

TL,DR:  Went wardriving around Berlin. 26.3% of APs with crypto enabled exposed methods that imply vulnerability to the WPS design flaw.  A conservative extrapolation from WIGLE data suggests at least 4.1M vulnerable hosts.  Yikes.

=======

Fixing things is hard.  Fixing things in security, even more so.  (There’s a reasonable argument that the interlocking dependencies of security create a level of Hard that is mathematically representable.) And yet, WiFi was quietly but noticeably one of our industry’s better achievements.  Sure, WiFi’s original encryption algorithm — WEP — was essentially a demonstration of what not to do when deploying cryptographic primitives.  And indeed, due to various usability issues, it used to be rare to see encryption deployed at all.  But, over the last ten years, in a conversion we’ve notably not witnessed with SSL (at least not at nearly the same scale)…well, take a look:

In January 2002, almost 60% of AP’s seen worldwide by the WIGLE wireless mapping project had encryption disabled.  Ten years later, only 20% remained, and while WEP isn’t gone, it’s on track to be replaced by WPA/WPA2. You can explore the raw data here, and while there’s certainly room to argue about some of the numbers, it’s difficult to say things haven’t gotten better.

Which is what makes this WPS flaw found by Stefan Viehböck (and independently discovered by Craig Heffner) quite so tragic.

I’m not going to lie.  Trying to reverse engineer just how this bug came about is being something of a challenge.  There’s a desire to compete with Bluetooth for device enrollment, there’s some defense against evil twin / fake APs, there’s a historical similarity to the old LANMAN bug…I haven’t really figured it out yet.  At the end of the day though, the problem is that an attacker can determine that they’ve guessed the first four digits before working on the next three (and the last is a checksum), meaning 11000 queries (5500 on average) is enough to guess a PIN.

So, that’s the issue (and, likely, the fix — prevent the attacker from knowing they’re halfway there, by blinding the midpoint error).  But just like the telnet encryption bug, I think it’s important we get a handle on just how widespread this vulnerability is.  The WIGLE data doesn’t actually declare whether a given encryption-supporting node also supports WPS.  So…lets go outside and find out.

Wardriving?  In 2012?  It’s more likely than you think.

Over an approximately 4 hour period, 3,738 AP’s were found in the Berlin area.  (I was in Berlin for CCC.)  2,758 of these AP’s had encryption enabled — 73%, a bit higher than WIGLE average.  535 of the 2,758 (19.39%) had the “Label” WPS method enabled, along with crypto.  These are almost certainly vulnerable.  Another 191 (6.9%) had the “Display” WPS method enabled.  We believe these to be vulnerable as well.  Finally, 611/2758 — 22% — had WPS enabled, with no methods declared.  We have no data on whether these devices are exposed.

As things stand, we see 26.3% of AP’s with encryption enabled, likely to be exposing the WPS vulnerability.

What does this mean, in terms of absolute numbers?  WIGLE’s seen about 26M networks with crypto enabled.  However, they don’t age out AP’s, meaning the fact that a network hasn’t been seen since 2003 doesn’t mean it isn’t represented in the above numbers.  Still, 60% of the networks they’ve ever seen, were first seen in the last two years.  If we just take 60% of the 26M networks — 15.6M — and we entirely ignore all the networks WIGLE was unable to identify the crypto for, and all the networks that declare WPS but don’t declare a type…

We end up with 4.1M networks vulnerable to the WPS design vulnerability around the globe.  That’s the conservative number, and it’s a pretty big deal.

Note, of course, that whether a node is vulnerable is not a random function.  Like the UPNP issues I discussed in my 2011 Black Hat talk, this is an issue that may show up on every access point distributed by a particular ISP.  Given that there are entire countries with a single Internet provider, it is likely there are entire regions where every access point is now wide open.

Curious about your own networks?  Run:

iw scan wlan0 | grep “Config methods”

If you see anything with “Label” or “Display” you’ve got a problem.

===
Small update:

There’s code in one WPA supplicant that implies that, perhaps APs that do not expose a method still support PINs:


/*
* In theory, this could also verify that attr.sel_reg_config_methods
* includes WPS_CONFIG_LABEL, WPS_CONFIG_DISPLAY, or WPS_CONFIG_KEYPAD,
* but some deployed AP implementations do not set Selected Registrar
* Config Methods attribute properly, so it is safer to just use
* Device Password ID here.
*/

I’m going to stick with the conservative 26.1%, rather than the larger 48.1% estimate, until someone actually confirms an effective attack against such an AP.

Categories: Security
  1. January 3, 2012 at 5:59 am | #1

    Dan,

    Small correction.

    iw scan wlan0 | grep “Config methods”

    should read:

    iw wlan0 scan | grep “Config methods”

    • Paul
      February 27, 2012 at 5:55 pm | #2

      Starting Feb. 1 2012, all new “certified” products will fully lock out after 10 attempts. Many in the field now lock after 3 failed static PIN attempts, or do an exponential delay. Makes scanning for vulnerable devices a little more difficult. War driving to detect really needs to knock on the door 11 times now … be interesting to get some statistics.

  2. Paul Lambert
    January 12, 2012 at 6:58 pm | #3

    >If you see anything with “Label” or “Display” you’ve got a problem.
    Display PIN is not a problem, just the “Static PIN” used on the label. The only mode of operation that is broken is the remote set up of an AP by a client using the Static PIN on the label. The other PIN mode where it’s displayed is supposed to show a unique PIN for each enrollment (which is secure). However, usually both are supported on APs.
    Some vendors read the specification and have good counter measures. The Wi-Fi Alliance recently updated the certification testing (last year) to prevent this issue … unfortunately the test developed is too weak and only adds a 60 sec delay after 3 failed attempts (crackable in a few days versus a few hours).
    The WI-Fi Alliance will likely develop a better recommendation and test plan this month. However, the bar door is already open. It’s pretty tough patching a majoiry of the APs that are out in the field.
    The industry really needs a better set of authentication protocols. Not just WSC/WPS, but the whole initial discovery and identification of peer wireless devices. The 802.11 Mesh sepcification has a start with the SAE protocol but it has minimal adoption. The use of EKE for setup would be ideal, but even though the patent is expired there may be other IP concerns.
    I’d like to see some basic PK based approaches that are “key centric” (versus PKI) as an initiative. Small wireless devices will proliferate and it would be very useful to have PK based identities (not to be confused with PKI :-)

    • January 15, 2012 at 8:03 pm | #4

      I think the problem is that even though the protocol may say “Display” it’s really still a label.

  1. January 8, 2012 at 7:25 pm | #1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 473 other followers

%d bloggers like this: