Welcome back to the wireless series. In this installment, we’re going to start to catch up with the times, just like you should.

In 2003, a new security standard for Wi-Fi networks was introduced. This was the first iteration of WPA, or Wi-Fi Protected Access. Only a year later, WPA2 was introduced. Then in 2006, WPS or Wi-Fi Protected Setup was introduced. WPS is often configured alongside WPA and WPA2 for ease of access. For those who haven’t used this before, you press a button on the router when connecting and the PSK (Pre-Shared Key, your Wi-Fi password) is passed to your device, allowing it to connect to the network. Before we move on to the various WPA standards, let’s attack WPS. There are a few different ways we can identify networks utilizing WPS. The first is with Wifite.

Adding the -5 command will have Wifite scan 5GHz channels as well, although it’s consistency leaves something to be desired. Analyzing this output, we also see that the encryption and WPS fields are rather lacking. Let’s look at Reaver’s tool for recon, Wash:

Again, less descript than I would like. So let’s try out airodump-ng. Just as with the other two tools, we’ll need to do this twice, as we’re going to observe networks utilizing both the 2.4GHz and the 5GHz bands. By default, running sudo airodump-ng --wps wlan0 will look at 2.4GHz. If we add the parameters -b a we’ll be monitoring the 5GHz band.

2.4 GHz:

5 GHz:

That’s better, we have more information from airodump-ng and it is also more accurate. So, what does all this extra information mean? This extended WPS column tells us the WPS version, lock state, and capabilities. Let’s start with the version and lock state information. Both blank entries and '0.0' indicate that WPS is either not in use, or has an additional mechanism required to activate it. 1.0 is the first version of WPS which is more likely vulnerable to attack, and '2.0' is the latest version of WPS. If the WPS column shows 'Locked' that indicates that WPS has been disabled by the access point, likely due to too many incorrect pin attempts. Additionally, next to the version field we may see one of several configuration methods:

·        ETHER – Ethernet

·        LAB – Label

·        DISP – Display

·        EXTNFC – External NFC

·        INTNFC – Internal NFC

·        NFCINTF – NFC Interface

·        PBC – Push Button

·        KPAD – Keypad

Additional information can be gleaned by running iw wlan0 scan and analyzing the “WPS” field per network. Notice that every WPS entry contains the field “Version: 1.0”, whereas only WPS 2.0 devices contain an additional “Version2: 2.0” field. Locked registrars will have minimal information and return the “AP setup locked: 0x01” field.

Currently, the only capability we’re interested in is label, this is the traditional pre-defined PIN. If the access point you’re targeting does not have a pre-defined PIN, regardless of whether it was defined by the manufacturer or administrator, you may need to identify a different attack vector or move on.

Mechanics of WPS

All devices that support WPS must allow for PIN entry to authenticate. WPS PINs are 8 digits but are verified in 3 parts. The first 4 digits are sent to the registrar (access point/router) and if they’re correct, a message is sent back to the enrollee (client) who then sends the next 3 digits. The final digit is only used as a checksum value. A fully detailed layout of what the WPS communication process looks like has already been written up here: http://80211notes.blogspot.com/2014/02/sta-ap-wps-sta-pin-procedure.html

Bruteforce Attacks and Lockouts

One of the primary issues with WPS authentication is, as you may have guessed, the pin being split into sections for validation. An attacker only has 4 digits to brute force to gain some ground in illegitimately authenticating to the access point, beyond that it gets even easier. Well, sort of. Don’t be fooled, this isn’t like other wireless attacks, where you’ll have the key in less than an hour. This typically takes several hours. To help mitigate the issue of repeated PIN guessing, manufacturers began implementing rate limiting and lockouts on too many attempts, which makes the attack take even longer. Many routers aren’t very aggressive with these protections however and someone with plenty of time on their hands can deal with this as an inconvenience.

Our first attack is going to be a pure brute force against the registrar, with no adjustments to timing or additional parameters. To start, we’ll use reaver. When a valid PIN has been identified, reaver will pull back the network password for you. sudo reaver -i wlan0 -b E0:91:F5:A2:79:B3 -c 2

·        -i interface name

·        -b bssid of the registrar/AP

·        -c channel

Unfortunately with the default settings, as mentioned, it can take quite a while to discover the pin that’s set on the router. A previous run of this went for 7 hours without making it through even 20% of the possible combinations. Our next option is to add the -S flag, this leverages a small Diffie-Hellman key size, allowing for quicker processing. As you can see, it really doesn’t help all that much:

Now, if a straight brute force attack is your only possible approach in an engagement, my condolences. You may have to sit and wait it out. Hopefully that never happens to you. Before I move on from the brute-force approach, I’m going to address an issue I ran into. Not all registrars handle requests in quick succession very well. You may need to further adjust your timing, or the responses you receive will cause reaver to try the same PIN over, and over, and over, and over…. So you’ll want to make sure and use at least verbosity level 2 when starting the attack, so that you can monitor for this behavior.

If the access point you’re targeting causes reaver to behave this way, you can try adjusting your timing and leveraging some more advanced flags. Here’s an example command with just about everything you can throw at it, please pay attention to the descriptions below, some of these flags should not be mixed but have been provided for demonstration. I would suggest starting simple, and adding flags as you see fit.

sudo reaver -i wlan0 -b 20:E5:64:04:2D:10 -c 1 -d 5 -T .85 -t 25 -S -E -F -J -A -r 3:60 -vv

A breakdown of these additional flags is as follows:

·        -d delay between PIN attempts in seconds

·        -T M5/M7 timeout period in milliseconds (.85 = 85 milliseconds). Increase the timeout period in case the registrar takes a little extra time processing requests

·         -t receive timeout period in seconds. Again, increased to give the registrar extra time

·        -S small Diffie-Hellman key size. Requires less processing power from the registrar

·        -E Force an EAP-FAIL at the end of each session. Keeps the registrar from using resources waiting for an enrollee (you) to continue the session

·        -F ignore frame checksum errors. Reduce noise and processing power requirements

·        -N RTFM, don’t use with -J

·        -J RTFM, don’t use with -N

·        -A RTFM, use aircrack or something to associate instead

·        -r extra delay of 60 seconds every 3 PIN attempt

Aside from rate limiting, you need to deal with lockouts. One way to do this is by simply ignoring it altogether. Some manufacturers either didn’t implement a real lockout, or implemented it incorrectly, allowing you to ignore it. This is done with the -L flag. Additionally, another incorrect implementation was locking out the offending MAC. There are a number of ways to change the MAC on your NIC, I won’t cover that here.

Some more protections that were added to the lockout procedure were to completely lockout any WPS authentication, rather than a specific MAC. This was done in a few ways: either for a set amount of time, until re-enabled in the web interface, or until the router is power cycled. Regardless of the intended lockout mechanism, crashing the router will always do the trick. You can do this with MDK4. Create a file named “blacklist” that contains the MAC of your target, and then run the following commands concurrently. Refer to the MDK4 manual for an explanation of flags.

·        sudo mdk4 wlan0 a -a xx:xx:xx:xx:xx:xx -m

·        sudo mdk4 wlan0 m -t xx:xx:xx:xx:xx:xx

·        sudo mdk4 wlan0 d -b blacklist -c X

·        sudo mdk4 wlan0 b -t xx:xx:xx:xx:xx:xx -c X

As with many of the attacks associated with WPS, this is not going to work on every device, hence why I have not provided any actual demonstration (if you want to fund the purchase of gear solely for this, be my guest). You also need to worry about any WIDS (Wireless Intrusion Detection System) that may be in place, this much traffic WILL be noticed and generate alerts.

Default, likely, and NULL PINs

Just as manufacturers love to set static default passwords on equipment, some manufacturers have been found to set a static default WPS PIN for all of their equipment, or a certain series of their equipment. The most comprehensive list I’ve found so far is at https://github.com/fulvius32/Default-WPS-PINs. I have also forked this repository in order to ensure it continues to be available, you’ll be able to find it at https://github.com/AlexKaos32/Default-WPS-PINs. Reaver allows you to specify a PIN for the authentication attempt with the `-p` flag. You could iterate through a cleaned version of this list by doing something like while read line; do reaver -i wlan0 -b xx:xx:xx:xx:xx:xx -c x -p $line; done < pinlist.

Another approach would be to use a little guesswork. Perhaps the pin has been set by the user/owner. If it’s a small business, try the last 4 digits of their phone number twice, or the suite number/street address 2-4 times (total of 8 characters). Lastly, you can use a NULL value for the PIN. Simply use double quotes in place of a PIN: -p "".

Pixie Dust

You may have read through this entire thing looking for this. Pixie Dust is a vulnerability that originates from two nonces in the authentication process that are not randomly generated, but are derived from hashes you’ve already been given in the auth process. They may even be all "0". This allows for the brute force of the nonces, and derivation of the PIN. Using reaver, you can use either the -K or -Z flag to perform this attack. You may need to run it more than once to be successful.

Closing

WPS is not nearly as easy to attack as WEP in most cases unless you happen to be attacking a target that is vulnerable to NULL PINs or the Pixie Dust attack. You need a lot of time and patience to get into a network with a bruteforce approach.

There are a couple of community-sourced spreadsheets out there that keep track of what routers are vulnerable to what attack. I used this one https://docs.google.com/spreadsheets/d/1uJE5YYSP-wHUu5-smIMTmJNu84XAviw-yyTmHyVGmT0/ to find a router for my lab that's vulnerable to pixie dust. One of these days if time and funds permit, I'd like to further explore WPS, specifically the modern implementation. Surely it's not flaw-free. Anyways, thanks for reading!