Wifite WPS transactions issues

[Cyb0rgbytes]

Hello everyone !
Hope you're doing well
I'm using the latest Kali version on USB live
And I was learning and working around with wifi pentesting to test my home network for vulnerabilities and flaws the tool at that time was wifite , I'm fimiliar with wifite but not experience in it's detailed usage and tweaks I'm trying to add --wpst and --wpsretry and started playing around with the options there is some issues that appeared to me while I was targeting my network locked with wps of course and almost vulnerable to the attack. The first issue was EAPfail and WPSFail whilst it's under progress , and also pixie dust is cracking the same pin over and over again and there is alot of timeouts and ttl in my success/ttl attempts , I'm aware I should change some lines inside of the script but I can't recall how did I do it before , I used to get the password with no time , now there is something wrong holding me back.

Thanks for reading until here
If someone can spare time to discuss and help I'd be pleased to listen , and I'm a good listener.
Until then
Best regards

[derv82]

Reaver's Pixie-Dust and PIN attacks are pretty fragile. I have yet to successfully crack an access point using WPS using reaver, except when I feed it the WPS PIN directly.

I'd like to improve this in the future, but it's difficult when I cannot reproduce a working Pixie-Dust attack on my own routers (and I have tested with lots and lots of routers).

[vom513]

Hello,

I posted this comment in issue #28

#28 (comment)

I have the Belkin F9K1102V2 as my dedicated Pixie test router. I can generally get Reaver and Bully to succeed with pixie on it. Sometimes I have to run them multiple times, but it does always work (eventually).

Seems like currently (or at least the last time I tried wifite2) - that bully will run under the hood and succeed, but wifite doesn't get the output correctly and believes it's failed. The Bully logs/results files show success though.

[kimocoder]

@vom513 Yes, this is ny issue too.. It get stuck on pixieattack, but seem to be running "under the hood".
Getting this one fixed should be a priority in order to have most attacks available (and usable).

Have gone away to work for some weeks atm, so cannot run more tests at this point but would be happy to check when I'm back again.

[Cyb0rgbytes]

@derv82 thanks for replying , such a great effort you put into the script !
I guess there is an issue where it keeps cracking the same pin and locks on one pin while cracking, " it doesn't increment the pins " I've tried before to change some lines in the script since i know some python my self, and my attempt was successful, but not now!

Good luck on your work!
Cheers!

[derv82]

@vom513 You said:

Seems like currently (or at least the last time I tried wifite2) - that bully will run under the hood and succeed, but wifite doesn't get the output correctly and believes it's failed. The Bully logs/results files show success though.

Can you (or anyone else) provide me the entire output of bully (and reaver too)? With the output, I can try to get Wifite working again. Separating stdout/stderr would help.

[vom513]

Sure thing. Attached are successful pixie runs of both reaver and bully. stdout/stderr in separate files. Also are the command line and arguments I used in both cases (these were constructed to mirror what current wifite2 uses when running). Hopefully this is what you need. Thanks.

wifite2-bully-reaver-diag.tar.gz

[derv82]

Thanks @vom513 !

Regarding the reaver-stdout.txt (pasted below): I don't see a PSK there. Did you remove it, or does reaver not actually output the PSK?

[+] Switching wlan1mon to channel 5
[+] Waiting for beacon from EC:1A:59:37:70:0E
[+] Received beacon from EC:1A:59:37:70:0E
[+] Vendor: RealtekS
[+] Trying pin "12345670"
[+] Sending authentication request
[+] Sending association request
[+] Associated with EC:1A:59:37:70:0E (ESSID: belkin.00e)
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message

 Pixiewps 1.4

 [?] Mode:     3 (RTL819x)
 [*] Seed N1:  -
 [*] Seed ES1: -
 [*] Seed ES2: -
 [*] PSK1:     2c2e33f5e3a870759f0aeebbd2792450
 [*] PSK2:     3f4ca4ea81b2e8d233a4b80f9d09805d
 [*] ES1:      04d48dc20ec785762ce1a21a50bc46c2
 [*] ES2:      04d48dc20ec785762ce1a21a50bc46c2
 [+] WPS pin:  11867722

 [*] Time taken: 0 s 21 ms

[vom513]

I didn't remove it - but I think I know why it's not there. Looks like pixiewps itself needs some extra arguments (i.e. -7) to compute and output the PSK.

From: https://github.com/wiire-a/pixiewps

Since version 1.4, it can also recover the WPA-PSK from a complete passive capture (M1 through M7) for some devices (currently only some devices which work with --mode 3).

So if you look at the second screenshot there, you will see -5 and -7 values being passed.

However when reaver runs pixiewps, the arguments don't include these:

executing pixiewps -e d0141b15656e96b85fcead2e8e76330d2b1ac1576bb026e7a328c0e1baf8cf91664371174c08ee12ec92b0519c54879f21255be5a8770e1fa1880470ef423c90e34d7847a6fcb4924563d1af1db0c481ead9852c519bf1dd429c163951cf69181b132aea2a3684caf35bc54aca1b20c88bb3b7339ff7d56e09139d77f0ac58079097938251dbbe75e86715cc6b7c0ca945fa8dd8d661beb73b414032798dadee32b5dd61bf105f18d89217760b75c5d966a5a490472ceba9e3b4224f3d89fb2b -s 6b5efa89fa39801f58171c5289df62441363258c000c48fa38ccb62a69e84d15 -z e796fdeb65ce530ac3b5005ab478a15845d88e35d835581dcd58c1f9d9811320 -a 99d6a6e73b303d84faf057042774f45ef73209728d612daa26f40cabfb66670c -n 334c146119a3735253c562ea7d3c8a92 -r bc17b00bd214b33965f7af624214f095f653fa47407768414896ec5c119ff447b8921ff3ca9f91fd7e897a4de0065dbe62c2b3f07d7b813efbe610aaab5bc27c845631cccded13fc8b0a72d1430941098cc25d82e5724190542771c9743d2ce480b1f8d8029fe3f6b93e9b01cd81827a4c07f088da800142779eec2272923532d00ea182d4e68fdf80bb9feb19b0765b317d0bcb525a75791f79fce602a41e8f7f274bcc53f69c568aa6d3a8f8996bb9332773dc2975cbcb540de71fc0d084de

In other good news though, looks like your recent changes are parsing reaver output correctly, here's a run against my test AP:

 [+] (1/1) starting attacks against EC:1A:59:37:70:0E (belkin.00e)
 [+] belkin.00e (EC:1A:59:37:70:0E @ 78db) WPS Pixie-Dust: successfully cracked WPS PIN and PSK                                               
 [+]        ESSID: belkin.00e
 [+]        BSSID: EC:1A:59:37:70:0E
 [+]   Encryption: WPA (WPS)
 [+]      WPS PIN: 11867722
 [+] PSK/Password: N/A
 [!] --pixie set, ignoring WPA-handshake attack
 [+] Finished attacking 1 target(s), exiting

[vom513]

I could be way off base here - but it seems like bully goes an extra step and does a WPS transaction with the AP with the correct PIN - i.e. after pixie has recovered the pin:

[Pixie-Dust] PIN FOUND: 11867722
[+] Rx(M2D/M3) = 'WPSFail'   Next pin '11867722'
[!] Received disassociation/deauthentication from the AP
[*] Pin is '11867722', key is '9a6f7997'

Isn't that what the "Next pin" means ?

It might be a bit heavy handed and inelegant - but I suppose reaver could be ran a second time with the -p argument and correctly recovered PIN to get the key ?

[vom513]

BTW - bully attack looks like it's also working again:

 [+] (1/1) starting attacks against EC:1A:59:37:70:0E (belkin.00e)
 [+] belkin.00e (EC:1A:59:37:70:0E @ 75db) WPS Pixie-Dust: successfully cracked WPS PIN and PSK                                                                                   

 [+]        ESSID: belkin.00e
 [+]        BSSID: EC:1A:59:37:70:0E
 [+]   Encryption: WPA (WPS)
 [+]      WPS PIN: 11867722
 [+] PSK/Password: 9a6f7997
 [!] --pixie set, ignoring WPA-handshake attack
 [+] Finished attacking 1 target(s), exiting

[kimocoder]

Tried PixieDust today, seems like reaver for stuck, but bully actually runs.
Will do some more testing, but it seems bully goes further at this point

[derv82]

Yikes, based on vom513's output, Wifite isn't actually detecting that the PIN was cracked (!)

[!] --pixie set, ignoring WPA-handshake attack

Should be fixed in 0bfc82c but I can't verify on my end.

seems like reaver for stuck

Let me know if reaver (default) is still not working and I'll take a closer look.

[vom513]

Yeah - I don't think reaver outputs the PSK anymore (but bully does). Here's what I get from current (i.e. default reaver):

 [+] (1/1) starting attacks against EC:1A:59:37:70:0E (belkin.00e)
 [+] belkin.00e (EC:1A:59:37:70:0E @ 78db) WPS Pixie-Dust: successfully cracked WPS PIN and PSK                                                                                   
 [+]        ESSID: belkin.00e
 [+]        BSSID: EC:1A:59:37:70:0E
 [+]   Encryption: WPA (WPS)
 [+]      WPS PIN: 11867722
 [+] PSK/Password: N/A

 [!] Error: 'NoneType' object has no attribute 'save'

 [!] Full stack trace below

 [!]    Traceback (most recent call last):
 [!]    File "../Downloads/wifite2/Wifite.py", line 224, in <module>
 [!]        w.main()
 [!]    File "../Downloads/wifite2/Wifite.py", line 42, in main
 [!]        self.run()
 [!]    File "../Downloads/wifite2/Wifite.py", line 152, in run
 [!]        attack.crack_result.save()
 [!]    AttributeError: 'NoneType' object has no attribute 'save'

 [!] Exiting

Bully seems to still work well. On my test router at least - bully seems to be more frequently successful. In other words, I typically have to run reaver several times to get a success. Bully frequently (but not always) gets a hit on the first try:

 [+] (1/1) starting attacks against EC:1A:59:37:70:0E (belkin.00e)
 [+] belkin.00e (EC:1A:59:37:70:0E @ 70db) WPS Pixie-Dust: successfully cracked WPS PIN and PSK                                                                                   

 [+]        ESSID: belkin.00e
 [+]        BSSID: EC:1A:59:37:70:0E
 [+]   Encryption: WPA (WPS)
 [+]      WPS PIN: 11867722
 [+] PSK/Password: 9a6f7997
 [+] saved crack result to cracked.txt (5 total)
 [+] Finished attacking 1 target(s), exiting

P.S. - Thanks for all your work on this. It really is appreciated. As you said - wifite is intended to be the "big red button". It really is - and that's super cool :)

[derv82]

Thanks for the report (really glad I turned on Stack Traces).

That crash when Reaver succeeds should be fixed in 88bb2c0

[derv82]

I just got a router should be vulnerable to Pixie-Dust (thanks to @kimocoder) so hopefully I can:

1. Reproduce the problems with WPS that people have reported.
2. Fix those problems.
3. Improve the WPS attack (make Reaver & Bully provide similar output).

---

I don't think reaver outputs the PSK anymore (but bully does).

Hoping to fix this in #76

[kimocoder]

You have to test the PixieDust on it, it's only tested om WEP vulns. Anyway, got my hands on a D-Link GO-RT-N150 too now, will check it for PixieDust and og it's vulnarable I'll send you that one too.

It's listed inn that Google Documents lage, so lets hope so

[derv82]

@kimocoder Thanks I already fixed a bug in WEP thanks to the new router (#27)

I'll test if your router susceptible to Pixie-Dust.

Edit: It works! Thank you!!!

[derv82]

So it looks like WPS attacks are working now for both reaver (deault) and --bully...

I have plans to improve the output & options for WPS attacks in #28. But AFAIK the Pixie-Dust attacks should work now.

Try out the latest version and let me know if this can be resolved.

[Cyb0rgbytes]

Hey there,
so i sat down and decided to so some testing.
i tried on a router it gave me eapol timeout on wps when trying to use the wps pixie dust the timeout says something about 30 sec timeout.
Another router i also attempted to test on gave me another error " sending eapol start request failed: too many timeouts" on step 5/8 and the sending identity request on 6/8.

Anyone has a clue , what i think is that i have to add some arguments when i start wifite but not sure which ones. I doubt there is an issue with the script since @derv82 updated it. Or should i change some lines in the script ?

Thanks in advance.
S.d

[derv82]

@softaddict Are you able to use reaver (or bully) to extract the PIN/PSK of the router you're testing?

If not, understand that only a subset of routers are vulnerable to the Pixie-Dust attack.

If so, what commands (reaver + switches) did you run to extract the PIN/PSK?

[Cyb0rgbytes]

hey,
No the extraction of the pin wasnt successful with both reaver and bully.
I guess its on my end, not sure though.
I get WPSFail and EAPFail and lots of timeouts.
One more thing, so if not many routers are vulnerable can wifite use wps attack as a method for pentesting instead of dictionary attack?
I always was impressed with this python script. Will be an achievement if i get used to it.

[derv82]

AFAIK, this is the current state of wireless attacks:

1. WEP still vulnerable, severely broken. (wifite-supported)
2. WPA/WPA2:
   • Requires a captured handshake + dictionary attack. (wifite-supported)
   • There is krackattack which is a MITM -- PSK cannot be derived via krackattack (AFAIK). (NOT wifite-supported)
3. WPS: Pixie-Dust. (wifite-supported)
   • The hashes returned by routers (from certain models/vendors) can leak enough information to derive the PIN (via the pixiewps tool).
4. WPS: PIN-attack. (NOT wifite-supported)
   • Basically a real-time dictionary attack.
   • Some (all?) routers leak when the first 4 digits of the PIN are correct.
   • This reduces the problem-space from 8 digits (100 million possible PINs) to 4 digits + 4 digits (20,000 PINs max).
   • This method can take weeks, and Wifite was not the most-reliable (or accurate) tool for running the PIN attack, so I have removed the PIN attack from Wifite.
5. Fluxion or "Evil Twin" (NOT wifite-supported... yet)
   • Requires 2 wireless cards.
   • 1 of your wireless cards is an Access Point, masquerading as the target router.
   • The other wireless card deauths/DOSes the target router, forcing victims to connect to yours.
   • The Evil Twin AP intercepts traffic and serves a fake webpage that asks for the wireless password.
   • Victim provides wireless password to Evil Twin.

[Cyb0rgbytes]

@derv82 Thanks for the breakdown, such a great info.
But still i need an answer for the timeouts that im getting to be able to do a proper test.
the commands i entered :

./wifite.py --wps --mac --kill and ran the script i used to use wpsratio and wpsretry in the built in script in kali but not anymore

the errors:

WpsFail. Eapfail. Timeouts. Pins dont increment i think its trying the same pin over and over , not sure tho.

[derv82]

If you can't crack an access point using reaver manually, then wifite will not help. You'll need to figure out how to get reaver working, make sure you have a vulnerable router to test on, etc.

Running man reaver is a good place to start.

If reaver works for you but Wifite does not, then I can look into what switches you're setting in Reaver and apply those to Wifite if applicable.

But until I get confirmation that you can run reaver (manually, without Wifite) then I'm basically help you figure out how to use reaver. There's better forums for this kind of help, such as the Kali Linux forums.

[rentandleave]

I downloaded the latest version and it detects SSID with WPS encryption, but when I chose a WPS enabled SSID , the following error is returned while wifite2 tries to run reaver attack

Error : - [!] your version of 'reaver' does not support the WPS pixie-dust attack
I installed the latest reaver-wps-fork-t6x and the problem still persists. Please point me to the right direction.
Thanks

[derv82]

Wifite checks that reaver's help page includes the term "--pixie-dust" in the stderr stream:

wifite2/wifite/tools/reaver.py

Lines 45 to 48 in 28b2d83

	def is_pixiedust_supported(self):
	''' Checks if 'reaver' supports WPS Pixie-Dust attack '''
	output = Process(['reaver', '-h']).stderr()
	return '--pixie-dust' in output

I cloned the latest newest version of reaver and it looks like --pixie-dust is still printed to stderr. From in the master branch of reaver-wps-fork-t6x:

https://github.com/t6x/reaver-wps-fork-t6x/blob/master/src/wpscrack.c#L181

@rentandleave What is printed when you run reaver -h 2>&1 >/dev/null | grep pixie-dust on your command-line?