Enhanced aireplay-ng fragmentation attack xor recovery capability

[darkAudax]

The concept is to enhance the fragmentation attack capability of aireplay-ng. The following briefly describes how it would work. Following that is a more detailed description of some of the concepts which will be applied.

The defaults would be: - capture sufficient xor bytes to be able to subsequently create an ARP packet - use aggressive assumptions as to types of packets captured and their content

Options - Specify the number of xor bytes you want. Minimum and maximum. - Disable aggressive assumptions of captured packets

Operation I can't remember if you previously implemented the aireplay filters to apply to the packets going to the frag attack. If not, the filtering should apply to the frag attack. This way you can use the filters to select ARP packets as input.

The same as now, the program would give you the option of writing a file with the xor bytes successfully obtained if you can't complete the full requested length.

If it gets the full number of bytes requested, write out the file and say how many bytes were captured.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

What follows is a more detailed description by Hirte of the proposed techniques:

"My thought about the behaviour is something like a keystream extender, you get an initial short keystream and you want a longer keystream with p keybytes. So the arguments for this "function" are the given short keystream and the desired keystream length p. Now the function picks as less packets as needed and runs the attack. I just mentioned this functionality to define a very general way of using the fragmentation attack, so we could build other attacks based on that. Right now this short keystreams comes from the captured wep packet and the desired keylength is 1500, but we could set both arguments variable, so it would take as less packets as possible to generate the desired keystream. Like you got 128bytes from a shared key authentication and you want to build a packet with a length of 220 bytes (for whatever reason), so you'd only need to send two packets instead of (i don't know exactly right now, but something around) 23 for 384 bytes."

"In the current code aireplay guesses the first 7 bytes, as this is the best known part in most packets. However we could assume that IP and arp traffic is a very large percentage of all traffic and that we could tell them apart in most cases. So knowing that we got an IP packet gives us 10 known bytes instead of 7 and if we detect an arp packet we know 22 bytes of the keystream! So in case we got an arp to perform the fragmentation attack, we would only need to send 4 packets to build an arp on our own, thus knowing 88 keystream bytes."

"To support more packets with different unknown protocols we could also include a conservative guessing, using only the first 6 bytes, as they are the same in most packets.

The length of the keystream guessing could be automated, first try guess as many bytes as possible, if that fails fall back to only guess the first 7 bytes and if even that fails use only 6 bytes. after that wait for another packet."

"We could also add a conservative mode to fragmentation attack. Lets say we're right on the edge of the APs range and we got a 30 percent packet loss. In this case getting 12 frames to the AP and capturing the answer could be relativly hard. So only sending 2 frames and receiving the answer, thus knowing 3 packets in a row, would be more realistic. Using this method we would need to send more frames to gather the desired keystream length, but we would know if the attack was successful after sending 2 instead of 11(12) packets. In theory this should be more stable than the current attack method."

Described in another manner:

When at the edge of the AP's range, you typically have many packets get lost. To deal with this problem, here is how the frag attack would work in a conservative manner:

Send just two packets and see if you get a response. The concept being that two packets are much less likely to get lost compared to sending the current 12 packets.

If that was successful, increase the size and send another two. And so on.

This means sending a lot more frames in grand total but each step has fewer frames to be successful. So you take many small steps instead of a few large steps.