WPS Pin Attack
An often overlooked feature on many WiFi routers and access points is WiFi Protected Setup (WPS). This is a convenient feature that allows the user to configure a client device against a wireless network by simultaneously pressing a button on both the access point and the client device (the client side “button” is often in software) at the same time. The devices trade information, and then set up a secure WPA link.
On the surface, this is a very clever feature. It allows less savvy users to establish a secure connection between their devices quickly and easily, and as it requires physical access to the hardware, it would seem relatively secure.
But a tool called Reaver has been designed to brute-force the WPA handshaking process remotely, even if the physical button hasn’t been pressed on the access point.
While some newer devices are building in protection against this specific attack, the Reaver WPS exploit remains useful on many networks in the field.
Note: To be clear, WPS is the vulnerable system in this case, not WPA. If a network has WPS disabled (which they should, given the existence of tools such as this), it will be immune to the following attack.
Finding a Network
If you’ve read the previous tutorial on cracking into a WEP network, you’ll recognize the command used to get the hardware into monitor mode:
From here you could use airodump-ng to look for networks, but Reaver actually includes its own tool for finding vulnerable WPS implementations which is much more straightforward. To start it, run the following command:
The output will look something like this:
This shows two networks which are, at least in theory, vulnerable to the WPS brute force attack Reaver uses. Note the “WPS Locked” column; this is far from a definitive indicator, but in general, you’ll find that APs which are listed as unlocked are much more likely to be susceptible to brute forcing. You can still attempt to launch an attack against a network which is WPS locked, but the chances of success aren’t very good.
Once you’ve found a network you wish to run the attack against, operating Reaver is very straightforward. The basic command needs only the local interface,
channel, and ESSID to be specified. The command to launch Reaver against the “linksys” network above would look like this:
The only part of the above command that might not be immediately obvious is “-vv”; this enables verbose output which greatly helps when trying to gauge how well Reaper is (or is not) progressing.
Once you’ve started Reaver, you’ll start seeing output like this:
This output shows that WPS pins are successfully being tried against the target (here we see 12345670 and 00005678 are being tested), and Reaver is operating normally.
Ideally, the basic command works and the attack progresses as expected. But in reality, different manufacturers have been trying to implement protections against Reaver-style attacks, and additional options may be required to get the attack moving.
As an example, the following command adds a few optional switches that can help to get Reaver working on more picky devices:
The core command hasn’t changed, the additional switches just change how Reaver behaves:
Ignore locked WPS state.
Don’t send NACK packets when errors are detected.
Delay 15 seconds between PIN attempts.
Set timeout period to half a second.
After 3 attempts, sleep for 15 seconds
This is by no means an exhaustive list of Reaver options, but it gives an idea on what kind of things you might want to try.
Even under ideal conditions, Reaver can take a very long time to complete its run. There is an element of chance involved, the brute forcing could theoretically discover the PIN very quickly, but in general it is going to take many hours to even make a dent in the possible pool of PINs.
Luckily, Reaver keeps a progress log file automatically, so you can stop the attack at any time and resume whenever it’s convenient. Spending a few hours a day running Reaver against the same network should uncover its PIN and through that the WPA passphrase...eventually.