search

mukulyadav49 / pyrit

Automatically exported from code.google.com/p/pyrit
0 stars 0 forks source link

pyrit packet analyzer false negative #349

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In some cases, pyrit (tested with 0.4.0) rejects valid? handshakes.
Capture file: http://wpa.darkircop.org/cap/wpa.cap.gz
BSSID: e0:05:c5:64:2f:b0 ESSID: 2384432
Capture frames 1 & 2
PSK for the net is 19900425
Executing pyrit:
pyrit -r wpa.cap -b e0:05:c5:64:2f:b0 -i wordlist.txt attack_passthrough
returns
No valid handshakes for AccessPoint e0:05:c5:64:2f:b0 found in the capture file.
Trying with aircrack-ng 1.1:
aircrack-ng -b e0:05:c5:64:2f:b0 -w wordlist.txt wpa.cap
returns the key KEY FOUND! [ 19900425 ]
Please note, no auth was tested with this net on the field.

Original issue reported on code.google.com by a...@stanev.org on 7 Sep 2011 at 6:36

GoogleCodeExporter commented 9 years ago 
Thanks for reporting. This seems to be a quite strange case, but Pyrit's 
behaviour seems to be actually correct:

The Replay Counter in Challange is set to 2. This indicates that there already 
has been a EAPOL-Key frame sent from the Authenticator during the current 
security association. The Supplicant is supposed to answer with the same Replay 
Counter. However the field in the Response carries a value of 1, indicating 
that it is answering to a previous Challange (which not present in your 
dump-file).

According to 802.11i, the Authenticator is required to silently drop this 
Response captured by you. Therefor, the two messages present in your dump-file 
do not represent a valid handshake. Pyrit is correct in keeping the two 
authentications separate. Aircrack-ng does not care about the Replay Counter 
and therefor constructs a EAPOL-authentication from the received bits and 
pieces.

There are two points to this:

Why the two messages still construct a valid EAPOL-handshake remains a mystery. 
My explanation at the moment is that the Authenticator sent two Challanges, one 
with Replay Counter 1 and one with Replay Counter 2, but failed to generate a 
new ANonce in between. This would be a *serious* security bug in the Access 
Point's firmware. Under this scenario, the Response carries the correct MIC as 
both Challanges (1 & 2) carried the same ANonce.
The two packets in your dump-file gives the illusion that this was a valid 
EAPOL-authentication. In the end however, the authentication failed because the 
Authenticator dropped the Response. The fact that aircrack-ng is still able to 
work on it is due to it's very relaxed behaviour.

The definitions given by 802.11i are very clear about the Replay Counter: Only 
the Authenticator has the right to increment it's value and key-frames with 
unexpected values are required to be discarded; there is no way around that. 
Giving a relaxed approached about the possible values of the Replay Counter to 
Pyrit would open a whole can of worms with tons of false negatives (indicating 
a crackable authentication which is not there); aircrack-ng falls prey to this 
all the time.

If you can, you may further investigate this case by checking if the Access 
Point e0:05:c5:64:2f:b0 can be made into generating more Challanges with 
repeating Nonce-values (this may be due it's random number generator strictly 
bound to a time-source). If this held true, the brand of Access Point in 
question (it seems to be a TK-Link) is highly vulnerable.

BTW: You may want to take down the file you posted. You may be held legally 
accountable depending on local laws for general-publishing it. You may want to 
sent it by email in the future :)

Original comment by lukas.l...@gmail.com on 7 Sep 2011 at 7:58

GoogleCodeExporter commented 9 years ago 
The posted link is part of server side of besside-ng - tool which currently 
lives in aircrack-ng's svn head, written by sorbo. The main site allows users 
to upload captures, which are cleaned and merged into one with another tool 
from aircrack-ng - wpaclean. There are other strange things in the capture, so 
it is worth checking it and compare the behavior of different tools.

Original comment by a...@stanev.org on 8 Sep 2011 at 5:01

GoogleCodeExporter commented 9 years ago 
I have a pcap from a huaweii modem which seems to be affected by the same. 
Aircrack detects the handshake but pyrit claims there is none, if you wan't I 
can send it through mail

Original comment by rfmu...@fluidsignal.com on 6 Jan 2012 at 1:10

GoogleCodeExporter commented 9 years ago 
I think I have the same problem with a handshake obtained on GOYSCRIPT with 
fake AP and pyrit running through the script Orange.sh on Wifislax 4.9

Original comment by foradejo...@gmail.com on 31 Jul 2014 at 8:39