Can't Detect WPS Enabled Routers

[mecrayavcin]

I have Wmare 14 and Kali Linux 32 bit VMware VM on my pc.

When i use Wifite
with --wps or only wifite;

in wps column All routers are RED.
I know that one of router is mine and it is wps enabled.

Screenshot: ZXV10 is mine. I think there are at least one WPS enabled wifi but all of them is NO.
https://imgur.com/a/3yFkp

I think this is a bug.

What should i do?

[MisterBianco]

Use the wash tool to verify the bug.

[mecrayavcin]

How can i do that?
Wash tool?

[MisterBianco]

Yeah wash, it comes with reaver...

[mecrayavcin]

what should i do exactly?
I am new in this

Commands or etc?

Thanks

[Obakemono]

I'm having this same issue, latest Kali fully updated, wash v1.6.4 and latest version of wifite2.

If i run wash all WPS routers are correctly shown, but wifite shows all of them as no WPS, and of course it won't let me try --pixie over a router i know that have WPS enabled.

[osysltd]

Confirmed for me on the latest kali nightly, behaviour the same for the first version as well

[mrboombastik]

I also confirm having the same issue. All is red in WPS column, even I have 2 routers tested with WPS on and nothing works properly... What a pity😒

[mecrayavcin]

is there any fix for this?

[mrboombastik]

I remember back in the days using it with backtrack 5, all was working fine but now with Kali there are issues. If the devs receive our messages maybe there is hope...

[mecrayavcin]

Which version backtrack?

[mrboombastik]

Backtrack 5 r3, but now there's no support or updates to use it. I tried it and does not work with the new version of wifite...I found a version of BT5 online but wifite is not installed by default. When I was using it 2 years ago approx. I had older version of wifite installed of course. I will try to find older versions and try if it works. If yes I will post the solution....

[Obakemono]

My guess is that this is a relatively easy to solve bug since the tool itself, wash, works fine.
I'll try to look into it if i get some time.

[MisterBianco]

@mrboombastik backtrack 5 was released long before wifite2 was around.
You are thinking of wifite
And @Obakemono the tool doesn't use wash to my knowledge... It uses the aircrack suite. Whole different beast

[derv82]

Thanks for notifying me, I tried the latest Kali Rolling & reproduced the bug.

It seems like wash can't fingerprint WPS access points via the -i option + the .cap from airodump-ng.

It might be due to changes in wash, or how airodump-ng writes the .cap file.

I may just move WPS-detection to a tshark filter (on wps) on the .cap file, and extracting the AP BSSIDs that have WPS-enabled flags.

[kimocoder]

@rofl0r @kcdtv any input on wash here?

[rofl0r]

i'm not certain what @derv82 want's to do with the -i option, it is meant to be used with an interface, not a pcap file. there is however the -j json mode which we added specifically for 3rd party tools like wifite, with the guarantee that we won't change its output (merely adding new fields, if it makes sense), unlike the regular scan ouput.

[mecrayavcin]

@derv82 What should we do?
I am new.
Can you prepare a tutorial for this?

Thanks

[derv82]

@Uraniumhazee Follow this issue if you want to know when this is fixed.

---

@rofl0r Sorry, I meant Wash's -f option instead of -i when specifying input files.

Here's a .cap file with beacon frames that include WPS flags: https://github.com/derv82/wifite2/raw/master/py/tests/files/handshake_exists.cap

Airodump detects 1.0 DISP WPS feature on the AP:

# Read the handshake .cap using airodump
% airodump-ng -r handshake_exists.cap --wps
BSSID              PWR  Beacons       Data  /s CH  MB   ENC  CIPHER AUTH WPS       ESSID
A4:2B:8C:16:6B:3A    0        1       13    0  11  54e. WPA2 CCMP   PSK  1.0 DISP  Test Router Please Ignore
                                                                         ^^^^^^^^

Wireshark shows numerous wps.* attributes on the beacon frames in the .cap file.

% wireshark handshake_exists.cap
# Filter `wps`

But wash -f handshake_exists.cap shows no output:

% wash -f handshake_exists.cap

Wash v1.6.4 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

BSSID               Ch  dBm  WPS  Lck  Vendor    ESSID
--------------------------------------------------------------------------------

The -j option makes no difference as no access points are found (response is empty).

% wash -f handshake_exists.cap -j

Wash v1.6.4 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

@rofl0r:

• Should wash detect access points in this .cap file?
• Has anything changed in how wash detects WPS networks in the past few years?
• How does wash detect WPS networks?
• I.e. what PCap properties / heuristics are used?
• Is it here? https://github.com/t6x/reaver-wps-fork-t6x/blob/master/src/libwps/libwps.c#L225

I'm thinking of rolling my own WPS-detection for a given Cap file using tshark & text-parsing. But the --json approach in wash is ideal.

[rofl0r]

this .cap has no radiotap header, and wash mistakenly tried to check the FCS checksum. fixed in e9ab13a ^

[rofl0r]

regarding your other questions: wps is detected when the beacon had a vendor-specified IE from microsoft with WPS in its tagged elements. this hasn't changed since day 1. what has changed is that wash used to have a completely broken FCS check which has been disabled. i fixed it and reenabled it, but did not think about that it might get called with pcap's lacking a radiotap header. HTH

[rofl0r]

btw, this issue might be relevant for wifite t6x/reaver-wps-fork-t6x#199 . it is recommended to send out a burst of probe request to broadcast address ff:ff:ff:ff:ff:ff prior to passing the pcap to wash, so you have probe responses from each AP.

alternatively you could run wash live (instead of using a pcap) and use the --scan option with -n. afaik there are no issues when several programs use the same monitor device, at least not on recent kernels.

[derv82]

@rofl0r: Thanks for info on how WPS packets are detected in Wash. I opted to use Tshark's filters to extract WPS-enabled APs from cap files.

---

Whoops, reopening until others confirm the issue is resolved.

@ Everyone,

Please let me know if the latest version (080e674) works, and that Wifite can successfully detect WPS networks again.

Note: The new version uses the tshark program to detect WPS networks. If you don't have it installed, you'll probably see errors or WPS: n/a in the targets list.

[Obakemono]

WPS detection works fine for me now with the latest version.

Thank you! :D

[mecrayavcin]

@derv82
WPS detection works fine but this time wps pin attack doesn't work.

Look at the SS's please
https://imgur.com/PbyNqVy
https://imgur.com/0TbbR8C

it stucks and doesn't try pins.

[mrboombastik]

Yep, having same issue also me.
I am not quite sure but I think that pixie dust don't work either well....

[derv82]

Sounds like WPS detection works. Resolving!

But seriously, Wifite 2's WPS attacks are broken right now.

I am working on fixing it. See #28 for tracking on this issue.

Until then, you'll have to run reaver or bully manually like a neanderthal.

# Running reaver:
reaver -i INTERFACE -vv -K -c CHANNEL -b BSSID
# Example for channel 11 and interface wlan0mon:
reaver -i wlan0mon -vv -K -c 11 -b AA:BB:CC:DD:EE:FF

# Running bully:
bully --pixiewps -c CHANNEL -b BSSID IFACE
# Example for channel 11 and interface wlan0mon:
bully --pixiewps -c 11 -b AA:BB:CC:DD:EE:FF wlan0mon