Wednesday, 8 April 2015

Pixies Pwn WPS

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.


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.


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, 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.


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.


  1. actually, if you are going to credit, i believe the person named DataHead provided the base of the PoC code mainly for Broadcom eCos and then ralink to soxrok2212 and wiire before the tool was released publicly.

    he is also mentioned in the source code of pixiewps in the special thanks

    1. I don't think any PoC code was made public, there was many attempts to get a hold of these tools but it was mostly met with excuses which is why these implementations were made in the first place.

      I'm not giving credit for alleged tools that I can't verify exist or work, if you know of any you wish to send me links to I'll add them to the blog of course.

  2. I made modifications to reaver to automate the entire process -

    1. Cool, I figured people would expand on the work already done, it's good to see some automation, good work!

  3. Nice blog frosty, i was told to check it out as there was some mention of me in the comments. Im not looking for credit or anything as such.

    But rather to clear up the prior comment about me . Which is pretty close to the truth.

    I did provide PoC code to sox and wiire. I am not entiley sure that the realtek code was used as a basis ( probably not ) but the broadcom ecos code definitely was.

    And in regaurds to the PoC codes public availability, well there was a reason i didnt want to release it in its infancy, and rather would have given it to only a select few AND trusted people than to just throw it out on a forum somewhere where nobody would further develop on an abandoned PoC . I've held it as a rather quiet project and stopped development on it, as it was just a more a personal tool. Until i started to a wide and great interest appear on forums around the web. Thus how i started talki g to sox, a bright and intelligent person whom only need some little guidance from someone who had already written and completed PoC code. And seen he wasn't mentally incompetent, and he could bring together a team of other in his league of not only striving for information on how its done, but more important the question of why. It was because of that ambition to learn, that i provided my code.

    Now hopefully that clears up any confusion or misconceptions. As i stated above, im not looking for any editing of credit for me to be added, wiire has been doing a hands down amazing job on the tool, a lot more work than i was willing to do to carry on a tool for public availability. i still work with wiire and on my own projects ( some of my projects and PoC not public, but doesn't mean they don't exist ) relating to the 'PixieDust' flaws When im not busy with my job, wife and kids.

    Furthermore, the validity of my statements here are true, if you or everydaydumbass have any questions , please feel free to ask away to myself, wiire, and soxrok2212 :-)


    1. Thanks for the clarification, I've updated the blog to reflect this. I only followed the evolution of this tool from the sidelines so to speak as I've been crazy busy with other security work (epic new blog post coming soon), so I didn't have the full story.

      With regards to PoC code, I can only accurately report on code I can run and test, I don't like to speculate. I don't have access to any private tools so I can only write about code that's released into the public domain.

  4. This comment has been removed by the author.