GoogleCodeExporter
commented
8 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
- Changed state: WontFix
Original issue reported on code.google.com by
a...@stanev.orgon 7 Sep 2011 at 6:36