Stateful handshake-parsing

About two weeks ago the update to Pyrit 0.3.1-svn r226 made Pyrit more picky about how it parsed the information from a capture-file and reconstruct the fourway-handshake. This change solved some cases where Pyrit would combine packets from overlapping or incomplete handshakes which made the task of finding the correct PMK impossible. Being more strict solved some cases of non-working capture-files but opened a whole can of worms on the other end: Pyrit would sometimes pick up packets from an incomplete handshake, look for the remaining parts and ignore other, more valuable packet-combinations.

The latest development-revision Pyrit 0.3.1-svn r231 brings relief to this problem and solves a to-do that had been marked as such since the packet-handling code was first checked in. Pyrit now has the ability to analyse, parse and work with multiple authentications and rate their quality. This brings a huge increase to Pyrit’s ability of working with packet-captures-files.

Here is an example of how the result of analysing a capture-file may look like from now on:

#1: AccessPoint 00:0b:86:c2:a4:85 (‘linksys’):

#1: Station 00:13:ce:55:98:ef, 3 handshake(s):

#1: Good quality (HMAC_SHA1_AES)
#2: Good quality (HMAC_SHA1_AES)
#3: Good quality (HMAC_SHA1_AES)

As you can see, Pyrit has detected three possible handshakes (WPA2-PSK in this case) and rated them as being of good quality. The quality of a handshakes is (currently) determined like this:

• “good” handshakes include the challenge from the AccessPoint, the response from the Station and the confirmation from the AccessPoint.
• “workable” handshakes include only the response from the Station and the confirmation from the AccessPoint.
• “bad” handshakes include only the challenge from the AccessPoint and the response from the Station (but not the confirmation).

Multiple handshakes of the same quality (like in the example above) are rated by how close to each other the packets resembling the handshake are. That way, vaguely related packets that accidentally resemble to a complete handshake are not completely ignored, but of little priority.

To pursue with the original behaviour, Pyrit picks the single most valuable handshake by itself and works only with this single handshake. The attack-modes therefore now understand a new option “–all-handshakes“. When this option is passed:

• attack_passthrough attacks all workable handshakes at the same time. This does not affect performance as the bottleneck is computing the PMK.
• attack_batch and attack_db work down the list of possible handshakes one after the other.
• attack_cowpatty attacks all workable handshakes at the same time. This impacts performance (e.g. 2 handshakes == 50% throughput)

Additionally, the behaviour of strip and stripLive has changed: Pyrit no longer places the (selected) packets from a single authentication but all authentication-related packets into the new file.

1 Comment

Comments RSS TrackBack Identifier URI