search

derv82 / wifite2

Rewrite of the popular wireless network auditor, "wifite"
GNU General Public License v2.0
6.45k stars 1.32k forks source link

Can't Detect WPS Enabled Routers #62

Closed mecrayavcin closed 6 years ago

mecrayavcin commented 6 years ago

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 commented 6 years ago

Use the wash tool to verify the bug.

mecrayavcin commented 6 years ago

How can i do that? Wash tool?

MisterBianco commented 6 years ago

Yeah wash, it comes with reaver...

mecrayavcin commented 6 years ago

what should i do exactly? I am new in this

Commands or etc?

Thanks

Obakemono commented 6 years ago

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 commented 6 years ago

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

mrboombastik commented 6 years ago

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 commented 6 years ago

is there any fix for this?

mrboombastik commented 6 years ago

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 commented 6 years ago

Which version backtrack?

mrboombastik commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@rofl0r @kcdtv any input on wash here?

rofl0r commented 6 years ago

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 commented 6 years ago

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

Thanks

derv82 commented 6 years ago

@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:

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 commented 6 years ago

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

rofl0r commented 6 years ago

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 commented 6 years ago

btw, this issue might be relevant for wifite https://github.com/t6x/reaver-wps-fork-t6x/issues/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 commented 6 years ago

@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 (https://github.com/derv82/wifite2/commit/080e674aa6044b60b04d74c51566d03c37fce86d) 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 commented 6 years ago

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

Thank you! :D

mecrayavcin commented 6 years ago

@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 commented 6 years ago

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

derv82 commented 6 years ago

Sounds like WPS detection works. Resolving!

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

I am working on fixing it. See https://github.com/derv82/wifite2/issues/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