WPS hacked again.
The department of "so what else is new" brings you another couple of attacks against Wi-Fi Protected Setup (WPS), a feature available on most WPA enabled routers. The original attack is known as Pixie dust and is based on the security research of Dominique Bongard. You can find his video presentation
here and slides
here.
This blog post will go through an in depth description of what WPS is, a history of some older attacks, why those attacks are generally not sufficient today and finally a close look at the premise behind the new vulnerabilities that these new attacks exploit so you can learn how they work. Finally I will introduce the brand new tools and their authors as well as a tutorial for use.
What is WPS?
Wi-Fi Protected Setup is a feature found on most modern home routers which makes connecting devices much simpler, there's several methods for connecting wireless devices to the network however the vulnerable method is the PIN method which is what these attacks target.
When doing a WPS PIN connection, you simply provide an 8 digit numeric PIN for the network you want to join, the device handshakes with the network and if the PIN is correct it joins the network, simple right? Behind the scenes what is really occurring is a handshake between the device and Access Point (AP), they both exchange the WPS PIN in a secure way to do a mutual authentication, if the PIN is correct the password which protects the WPA network is sent to the device and the device uses that to authenticate against the AP.
The WPS PIN is normally set with a default value when the router is shipped and will appear in the documentation or on a sticker on the physical AP device. Most routers allow you to enable or disable WPS and some even let you pick a new PIN which might be randomly assigned or user defined.
Prior WPS weaknesses
The history of weaknesses in WPS and specific implementations is embarrassing to say the least, here are some of the prior vulnerabilities I'm aware of.
Manufacturers picking unique PINs for each of the routers they ship which are derived in some way from the unique MAC address of the router, see
here. The MAC address is publicly beaconed for all wireless networks and can be passively sniffed allowing users to derive the PIN from the MAC.
Brute force attacks such as Reaver created by Craig Heffner exploit several weaknesses in the PIN exchange that reduce brute force attacks down to at most 11,000 PIN attempts which can be done within a few hours providing routers didn't have any kind of throttling with attempts or WPS lockout.
Some older routers would not disable WPS despite it being shown as disabled in the config page, this lead to some people thinking they are safe disabling WPS when really they were still vulnerable.
These vulnerabilities were very serious and in most new routers seem to be fixed, modern WPS enabled routers tend to throttle WPS attempts as per the specifications, often they will disable WPS all together after a certain number of failures. Step in Pixie dust.
The Pixie Dust attack
To understand how the Pixie dust attack works you need to be familiar with the WPS handshake that is performed during a WPS PIN exchange. You'll also need to know a bit about hashing and PRNGs both of which I'll give an intro to. Here is the handshake documentation for reference.
The enrolment occurs in 8 steps M1 to M8 and we're primarily concerned with steps M1-M3, to avoid confusion it's worth pointing out that the Enrollee is the AP and the device connecting is called the Registrar, it seems counter intuitive and the source of some confusion.
There's several requirements of this handshake that need to be filled in order to help keep it secure.
First of all it needs to be protected against replay attacks, these are attacks where adversaries sniff the network traffic of a genuine Registrar talking to the AP and recording the traffic, then simply replaying it back at a later date. To prevent this Nonces are used which are one time use random numbers, these are the N1 and N2 numbers in the handshake above. Because they're randomly generated for each new WPS handshake attempt it means you cannot replay back old handshake data and successfully authenticate.
Secondly, the authentication needs to be mutual. Not only does the AP need to verify that the connecting device knows the real PIN before it hands out the WPA password, but the connecting device also needs to know the AP is the genuine AP and not spoofed, before it hands over proof of the PIN. This stops hackers from putting up fake access points which wait until someone attempts to connect with a real PIN and harvesting the credentials. It also explains why the AP is handing over the PIN to the Registrar in the first place, at first this can seem counter intuitive to security of the system.
This mutual exchange of secret information is an interesting and complicated problem which is solved using cryptography. Instead of exchanging the PINs in plain text which would destroy any hope of mutual authentication, both the AP and the connecting device swap hashes of the PIN instead.
Hashing
For anyone not already familiar with hashing, this is simply a mathematical function which can be applied to a plain text of arbitrary length and scrambles that text to be an unrecognizable fixed length value called the hash. Hashes are useful as it's impossible to reverse the hash back into the plain text, because of this they're typically used to protect information you want to keep secret like passwords or in this case the PIN.
The premise is that both the AP and the Registrar provide each other the hash of the PIN and not the PIN itself. This way the plain text of the PIN remains secret and is never directly exchanged. To verify the hash you are given is correct you'd simply hash your own PIN and then compare the hashes, if they're the same then you have verified the other device also knows the PIN. In reality this step is done by breaking the 8 digit pin in half and creating 2 hashes for the Enrollee and 2 hashes for the registrar.
It's worth noting that during the handshake the AP sends the Registrar these 2 hashes first in step M3. You could imagine one possible attack against this system is a brute force attack against the hashes E-Hash1 and E-Hash2.
While you cannot mathematically reverse hashes back to their plain text you can however hash every possible combination of plaintexts (for short plaintexts) and then compare the hashes and if you find a match then you know the plaintext that caused the hash, this is known as a brute force attack. Because the total number of possible PINs is very small a brute force is trivial, each half of the PIN is only 4 digits of 0-9 which puts the total number of hashes to check for the first half at 10^4, or 10,000 and the 2nd half at 10^3 or 1,000 tries (because the 4th digit is a checksum and isn't used), a total of 11,000 tries which a modern CPU can do in less than a second.
The designers of WPS knew this kind of attack would be possible so they added an extra step in the process to stop brute force attacks, they first generate 2 random numbers E-S1, E-S2 for the Enrollee, these are simply 2 strings of 128 random bits, the hashes E-Hash1 and E-Hash2 become the hash of the combined PIN + the random number.
Now it becomes impossible for the registrar to brute force the PIN out of the M3 step, you'd need to check all possible combinations of random numbers for 128bits multiplied by the number of different PINs which is computationally infeasible. However if we could somehow find the secret random numbers E-S1 and E-S2 through some other method then our brute force is simple. The Pixie dust attack uses 2 different methods to find these random numbers.
Attack 1
This is a super simple attack, a certain class of routers use static or just blank values for the 2 random number E-S1 and E-S2, the firmware for these routers can be downloaded from the manufactures websites or the source code found online to determine these keys. Obviously this is a very bad implementation of the protocol, chipsets caught doing this are only Ralink so far, however it's plausible that others are effected, it's implementation specific so individual testing is required.
Attack 2
The 2nd attack is much more sophisticated and requires some knowledge of how random numbers are generated. I'll urge you to read my blog post on Pseudo Random Number Generators (PRNGs)
here first to get a more detailed overview of PRNGs and why they're insecure for use with security such as cryptography.
The layman's explanation is that PRNGs are not actually random, they're in fact entirely deterministic, they spit out a very long and predictable string of numbers and it's possible to determine the state the PRNG is in (how far it is through that large string). If you have some sample output it had previously generated you can simply run a PRNG continuously until you spot that pattern of randomness. Once you know the state the PRNG is in you can predict all future output with 100% accuracy.
In the case of Broadcom/Ecos chipsets they are using the rand() function in C which is a PRNG with an internal state small enough to easily brute force. If you look back to the handshake one thing you'll notice is that before the E-Hash1 and E-Hash2 are sent to the Registrar, a "random" nonce N1 is first created and sent in plain text.
The attack against these chipsets then becomes simple, the attacker starts the handshake and captures N1 from the access point, this is used to brute force the state of the PRNG of the access point, you run the PRNG forward another 256bits of randomness which are what is used to determine the 2x128bit keys E-S1 and E-S2. You then hash every possible combination the first 4 digits of the PIN with E-S1 and compare to E-Hash1, and the first 3 digits of the 2nd half of the PIN with E-S2 and compare against E-Hash2 to recover the entire PIN.
Once you have the correct PIN you start a new WPS handshake with the access point as normal providing the correct PIN first time and recovering the plain text password for the WPA network, this can be done with Reaver.
Tools
Unfortunately Dominique Bongard never released a proof of concept tool to demonstrate this so it's remained largely unused among hackers, until a few days ago. A hacker by the name of SoxRok2212 contacted me after discussing this attack on Hackforums.net, he wanted to create an attack tool, I explained the methodology of the attack in more detail and he found a coder named Wiire and they produced a working tool based on PoC code provided by DataHead. Big thanks to everyone who came together to make this work, apologies for prior inaccuracy crediting the relevant parties for the final tool.
You can find Pixiewps on github
here
You need a modified version of Reaver 1.5
here
If you're looking for a clear and concise demo of it in use with instruction then check out this excellent tutorial by soxrok2212 on
YouTube.
Mitigation
As always with WPS the mitigation for such attacks is to simply disable WPS, right now it's not clear to what extent this is a problem, it's implementation specific so there could be similar flaws in other chipsets and routers which haven't been tested yet. There's a document of known affected chipsets
here but it's by no means exhaustive.
