search

detrojones / reaver-wps

Automatically exported from code.google.com/p/reaver-wps
0 stars 0 forks source link

r65 tries second half of each PIN twice! #80

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run reaver normally until it guesses the first half of the pin and jumps to 
90+ %
2.
3.

What is the expected output? 
-------------------------
[+] Trying pin 49387179
[+] Trying pin 49382341
[!] WARNING: Receive timeout occurred
[+] Trying pin 49382341
[+] Trying pin 49387605
[+] 91.15% complete @ 2012-01-04 23:49:00 (10 seconds/attempt)
[+] Trying pin 49384956
[+] Trying pin 49381337
[+] Trying pin 49381641
[+] 91.16% complete @ 2012-01-04 23:49:21 (10 seconds/attempt)
[+] Trying pin 49382136
-------------------------

What do you see instead?
-------------------------
[+] Trying pin 49387179
[+] Trying pin 49382341
[+] Trying pin 49382341
[!] WARNING: Receive timeout occurred
[+] Trying pin 49382341
[+] Trying pin 49387605
[+] Trying pin 49387605
[+] 91.15% complete @ 2012-01-04 23:49:00 (10 seconds/attempt)
[+] Trying pin 49384956
[+] Trying pin 49384956
[+] Trying pin 49381337
[+] Trying pin 49381337
[+] Trying pin 49381641
[+] 91.16% complete @ 2012-01-04 23:49:21 (10 seconds/attempt)
[+] Trying pin 49381641
[+] Trying pin 49382136
-------------------------

What version of the product are you using? On what operating system?
reaver r65 on ubuntu 11.10

Please provide any additional information below.
PINS were tried only once before completing the guess of the 1st half of the 
PIN.  Upon starting the 2nd half of the PIN each 2nd half of the PIN is tried 
twice with no intervening timeouts or failures.  This problem started occurring 
on  r65 and was not present on earlier versions.  FYI.  Thanks!

Original issue reported on code.google.com by vsil...@gmail.com on 5 Jan 2012 at 5:53

GoogleCodeExporter commented 9 years ago 
I decided to go back and try previous versions: r64, r63, ..., r48 and all 
exhibit the same behavior with my ongoing session (92% or second half of the 
PIN).  I guess I never noticed before.  All revisions try each PIN twice before 
proceeding to the next one, at this rate it will take twice the time to guess 
the second half of the PIN.  Please, see if you can find the error in the state 
machine.  Thanks!

P.S.: It could be that timeouts are received but not presented (printed with 
-vv) but then it would be too suspicious that each PIN needs exactly 2 tries to 
go through.

P.S.: I vaguely remember that before the session saving was implemented in the 
open source version it would only try PINs once for the second half.  But I do 
not want to regress my installed version that far back...

Original comment by vsil...@gmail.com on 5 Jan 2012 at 6:47

GoogleCodeExporter commented 9 years ago 
Does this happen on every AP, or just a specific one? Can you provide a pcap?

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 4:19

GoogleCodeExporter commented 9 years ago 
The old AP with the problem above was a Netgear E0:91:F5:... .  

I tried again, using r66 now, on another AP from Cisco-Linksys 7C:03:4C:... 
that was already completed by decreasing the second number in the .wps file and 
making the third number in the .wps file a 2 --> 1 (revert to secod half of PIN 
testing).  As you can see from the output below, the problem persists.

Not sure if I'll be able to produce a pcap file, but advise what's the best way 
to capture: airodump-ng, tcpdump, or wireshark?  What filter?  Thanks!

[+] Switching mon0 to channel xx
[+] Associated with 7C:03:4C:xx:xx:xx (ESSID: xxxxxxxxxx)
[+] Trying pin 15346414
[+] Trying pin 15340504
[+] Trying pin 15340504
[+] Trying pin 15341310
[+] Trying pin 15341310
[+] Trying pin 15345257
[+] 94.62% complete @ 2012-01-05 12:58:38 (8 seconds/attempt)
[+] Trying pin 15345257
[+] Trying pin 15344632
[+] Trying pin 15344632
[+] Trying pin 15343307
[+] Trying pin 15343307
[+] 94.65% complete @ 2012-01-05 12:59:03 (8 seconds/attempt)
[+] Trying pin 15340757
[+] Trying pin 15340757
[+] Trying pin 15340634
[+] Trying pin 15340634
[+] Trying pin 15340788
[+] 94.66% complete @ 2012-01-05 12:59:23 (8 seconds/attempt)
[+] Trying pin 15340788
[+] Trying pin 15342508

Original comment by vsil...@gmail.com on 5 Jan 2012 at 7:08

GoogleCodeExporter commented 9 years ago 
What command line options are you supplying to Reaver?

The easiest way to capture the traffic is to use Wireshark with a display 
filter of 'eap || eapol'.

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 7:19

GoogleCodeExporter commented 9 years ago 
In addition to the -i, -b, and -s:
    1) On the Netgear: -vv -c 6 -E -S -a -l 60 -s
    2) On the Linksys:  -vv -c 6 -E -S -d 0 -t 30

Original comment by vsil...@gmail.com on 5 Jan 2012 at 7:24

GoogleCodeExporter commented 9 years ago 
I have noticed on some Linksys devices that with -d 0 I get repeated pins (but 
it happens when brute forcing both the first and second half of the pin). On 
the Linksys, try only specifying the -i -b -s and -vv options and see if there 
are still repeated pins.

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 7:30

GoogleCodeExporter commented 9 years ago 
I took the "-d 0" out (removed it) and tried again the Linksys.  Problem 
persists (see log below).  I am surprised nobody else reproduced and commented 
on this problem.

Note that I used "-d 0" originally after determining empirically that the AP 
would buy it (no lockdowns) and since it was faster (on the Linksys), but the 
same was not working well on the Netgear (maybe lower signal strength) so I 
resorted to defaults (-a) on the Netgear.  I.e., they were the optimum 
parameters for my test cases in terms of overall speed.  

There were definitely no duplicate PINs on the 1st half of the PIN tests on 
either AP.  Thanks!

[+] Switching mon0 to channel xx
[+] Associated with 7C:03:4C:xx:xx:xx (ESSID: xxxxxxxx)
[+] Trying pin 15345066
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Trying pin 15345066
[+] Trying pin 15345066
[+] Trying pin 15340917
[+] Trying pin 15340917
[+] Trying pin 15341211
[!] WARNING: Receive timeout occurred
[+] 94.56% complete @ 2012-01-05 13:34:09 (27 seconds/attempt)
[+] Trying pin 15341211
[+] Trying pin 15343987
[+] Trying pin 15343987
[+] Trying pin 15344359
[+] Trying pin 15344359
[+] 94.59% complete @ 2012-01-05 13:34:32 (15 seconds/attempt)
[+] Trying pin 15346414

Original comment by vsil...@gmail.com on 5 Jan 2012 at 7:42

GoogleCodeExporter commented 9 years ago 
With the "-d 0" still out I tried the 1st half of the PIN on the same Linksys 
AP: no repeated PINS.
[+] Trying pin 12116416
[+] Trying pin 84946416
[+] Trying pin 68406417
[+] Trying pin 24676410
[+] Trying pin 85856417
[+] Trying pin 27896419

Restoring the "-d 0" option and continuing on the 1st half of the PIN: no 
duplicate PINs.
[+] Trying pin 57906416
[+] Trying pin 50296415
[+] Trying pin 74836413
[+] Trying pin 65436417
[+] Trying pin 41176412
[+] 52.11% complete @ 2012-01-05 13:51:34 (9 seconds/attempt)
[+] Trying pin 78866416
[+] Trying pin 81926411
[+] Trying pin 85826410

Original comment by vsil...@gmail.com on 5 Jan 2012 at 7:54

GoogleCodeExporter commented 9 years ago 
I tried to reproduce the problem with r67 (with debug output)--by the way the 
-o option only sends stdout to the file, not stderr, so it is harder than it 
should be to capture both stdout and stderr, I just didn't use -o and copied 
all the output from the terminal--.

Surprisingly, I do not see duplicate PINs on the 2nd half of the PIN tests over 
the Linksys AP.  Output attached.  Thanks!

P.S.: Hopefully that stays the same after you take the debug output out :-)

Original comment by vsil...@gmail.com on 5 Jan 2012 at 8:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Part of the r67 update was to also ensure that M2D messages do not get sent; 
checked in r68 which removes the debug output, verify that you still aren't 
getting repeated pins.

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 9:21

GoogleCodeExporter commented 9 years ago 
Finally, r68 fixes the issue: no repeated PINs.  Thanks!

[+] Switching mon0 to channel 6
[+] Associated with 7C:03:4C:xx:xx:xx (ESSID: xxxxxxxx)
[+] Trying pin 15344953
[+] Trying pin 15343628
[+] Trying pin 15346933
[+] Trying pin 15347060
[+] Trying pin 15347565
[+] Trying pin 15341365
[+] 94.85% complete @ 2012-01-05 15:25:59 (2 seconds/attempt)
[+] Trying pin 15348227

Original comment by vsil...@gmail.com on 5 Jan 2012 at 9:29

GoogleCodeExporter commented 9 years ago 
Good, sounds like the removal of M2D message support (not needed for the 
attack) fixed it. :)

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 9:31