Reaver/Bully problem. Kali problem? backports problems?
Hello. I am very familiar with WiFi pen-testing over the last 12 months, and I've tried a large amount of routers with a wide range of techniques, however, I found a problem and I am addressing it to Kali.
Regard the above, I would like to hear from you some to see if someone found and could resolve this problem. I would like to put a background here, since this would be helpful to understand that I am actually doing it right.
Normally, in my first steps of WiFi pen-testing my first approach is to try Reaver at first (when WPS enabled, of course).
Wherever, whenever the AP is WPS enable I try commands as follow:
reaver -i wlan0mon -b xx:xx:xx:xx:xx -e essid name (sometimes I overpass this, since both scripts works fine without -e) -N -D -S -vv (if sensible router is found, such as belkin, broadcom, ralink, I use the proper commands to de-cloak the PIN without brute-forcing the whole 11000 set). Sometimes I would require to deactivate -S because no small DH packets can be processed in order to associate (especially the older ones).
or
bully -b xx:xx:xx:xx:xx -N -F -C -v3 wlan0mon (with -d if pixiedust version is used).
Many times this has worked wonderful, except to new routers that would come with WPS locks (some routers last 5 minutes, other last even 48 hours).
Of course, if I can, I test the mdk3 command to see if I can overload the router a force a hard reset (I tried the musket team version which includes the -t command) so far so good, no a single router with AP lock I could found vulnerable to this attack. However this is not the point, yet.
In some cases, some pesky and wayward routers may require a fakeauth from aireplay-ng which I combine:
reaver -i wlan0mon -b xx:xx:xx:xx:xx -e essid name (sometimes I overpass this, since both scripts works fine without -e) -A -N -D -S -vv (note the "A"). Or at least an A in these commands.
aireplay-ng -1 30 (may vary between 3 to 60, depending on the stability on the router) -q 3 (sending keep alive packets is quite good to avoid connections failures, at least to me) -a xx:xx:xx:xx:xx wlan0mon
This way is quite slow, but it works (between 8 to 40 seconds to associate with a average of 9 to 14 seconds in these pesky routers).
However, and here's where comes the intriguing problem I have met with 2 routers, 1 d-link and 1 tp-link.
Both were susceptible to the PIN bruteforce (wash -i wlan-mon -C, etc) with no AP WPS rate lock, and I could try almost 3k (d-link) and 5k (tp-link) PINs using bully (<standard> procedure) with -49 dbi (d-link) -60dbi (tp-link).
Suddenly, both routers start to give me Timeouts everywhere (bully, reaver, reaver+aireplay) with no reason, not a single M1 NACK is given. Little bit frustrating. However this is good for the owners.
I have tried other router that I already know the tool works, but this is not happening with every router. Just these 2.
My idea that is related with Kali is that the problem started almost in the same date I decided to make a backport upgrate (just because why not? I have not seen any problem with users before).
For technical information:
Gnome Version 3.22.2
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu)
Kernel base upgraded https://www.kernel.org/pub/linux/ker...stable/v4.4.2/
Also, every apt-get update, apt-get upgrade, apt-get distr-upgrade was done.
apt-get autoremove also was done.
I dunno. What do you guys think about this problem?
Any idea? should I apply a backport downgrade from the beginning?
