Hello Kali community!
T6_x has requested that I write this thread since English is not his first language and it would be better if a native explained it. That being said, I do not take any credit for the research that went into this theory!
*Use all this information at your own risk. Nobody is to be held responsible for what you do with anything that comes out of this thread*
Now, heres the point of this thread. T6_x has been looking into Hostapd recently, and what he found is that in versions 0.5.9 to 2.0, it uses a poor way of checking hashes. What happens is when a WPS exchange is initiated and we send our 2 hashes to the AP in the M4 message, R-Hash1 and R-Hash2, the AP checks our hashes byte by byte. This can be exploited, though in a very difficult way.
Assuming the AP does not lock out and is rather active, we as an attacker can count the time it takes for the router to either respond with a WSC Nack or the M5 message. Whoop-Dee-Coo right? Wrong! Since Hostapd checks our hashes byte by byte, we can estimate how much of the hash it has checked based on how quick it has responded with one of the two possibilities! The longer the time it takes to get a response, we know more of our hash was correct! Through statistical analysis and with an estimated 1000-4000 tested pins, we can make a very educated guess as to what parts of our hash were correct and guess a PIN based off of the response times.
We are still looking for ideas to make this approach better. Therefore, we am supplying download links for all versions of Hostapd. There are probably fresh and better ideas that you guys can come up with, ways that will reduce the amount of PINs needed to be tested before we can guess. Right now, we are beta testing this idea and analyzing data in excel based on a graph. T6_x has reported success with this approach, but it could have just been luck so we want to open the idea to the community. After all, we did make the Pixie Dust attack a reality!
Any questions or comments of any kind are welcome!
Warm regards,
soxrok2212, t6_x, wiire, and datahead
