Fragmentation vs. ChopChop

[Biggen]

Ok, I'm a little confused on the basis for using Frag vs. ChopChop.  As i basically understand it, one would use Fragmentation only if ChopChop fails against the AP which it certainly can.  But here is the problem I am having.  One has to know the IP's in the AP's netmask in order for Fragmentation to work, correct?  Well one would only know this against a known AP.  But if one were trying to crack a WEP key against an unknown AP, you could never use the Fragmentation attack because you wouldn't know the AP's net mask.  Correct?  So in reality, if there are no clients on the AP and one is attempting ChopChop and that fails, Fragmentation wouldn't work either since you don't have all the needed info to perform the attack.

So I am just a little confused of even why one would use Fragmentation.  How are you supposed to know the netmask of the AP?

Am I stupid and just missing something??

[darkAudax]

Edit February 28/2007: This posting is out of date.  See the wiki: http://aircrack-ng.org/doku.php?id=aireplay-ng#fragmentation_vs._chopchop for the latest version

Biggen,

You are correct in saying there are challenges to executing the fragmentation attack.

I don't recommend thinking in terms deciding if one is better or worse then the other.  Rather, think of it as another tool in your toolkit.  Each can be useful in different circumstances.

Below is a quick pros/cons for each.  Maybe other people can throw in their ideas as well.

Fragmentation
Pros
- Can obtain the full packet length of 1500 bits xor.  This means you can subsequently pretty well create any size of packet.
- May work where chopchop does not.
- Is extremely fast.  It yields the xor stream extremely quickly when successful.

Cons
- Need more information to launch it - IE IP address info.  Quite often this can be guessed.  Better still, aireplay-ng assumes source and destination IPs of 255.255.255.255 if nothing is specified.  This will work successfully on most APs.  So this is a limited con.
- Setup to execute the attack is more subject to the device drivers.  For example, Atheros does notc generate the correct packets unless the wireless card is set to the mac address you are spoofing.

Chopchop
Pros
- May work where frag does not work.
- You don't need to know any IP information.

Cons
- Cannot be used against every access point.
- The maximum xor bits is limited to the length of the packet you chopchop against.
- Much slower then the fragmentation attack

d.

[Biggen]

That makes more sense.  I thought I was just overlooking something.  I have yet to try out the frag attack. May try it tonight on my home ap when I get home.  My ap at work is invunerable to the Fake Auth attack which sucks (for my testing purposes anyway) but luckily I have a cheap Belkin AP at home which I can do pretty much anything with.

I appreciate your explanation for the pros and cons, darkAudax.  Your right, another tool.  I downloaded the mdk kit last night.  Pretty cool stuff although neither my home ap nor my work ap crashes because of the DoS attacks.  :-(. 

[darkAudax]

Biggen,

In terms of the fake authentication, check out http://tinyshell.be/aircrackng/forum/index.php?topic=1014.0.  Hirte has modified the fake auth code in the svn trunk to include new options which fixed my problem.  It may also fix yours.

d.

[Biggen]

The "-o 1" works like a champ!!  Woohoo! That opens up all kinds of possibilities now!!

:-)

Thanks, bud!!

[Hirte]

Biggen: Most of the time you don't need to know an IP address, just use "-l 255.255.255.255" and it should work. so you only need to know the bssid and an associated client mac...

d.: As the length of the keystream was mentioned, we could implement a reverse chopchop function, which extends a given keystream to its full length by guessing the next keystream byte. this could be handy in case you can't use the fragmentation attack (because of a driver/firmware issue) and you chopchoped a small packet (arp, getting 36 keystream bytes), but you need a longer keystream (for fake shared key authentication, or the generation of an IP packet)...

[sorbo]

You do not need to know the IP address in order to perform the frag attack.  See:
http://tinyshell.be/aircrackng/forum/index.php?topic=1002.msg6903#msg6903
Thus, I don't think that should be used as a cons when comparing frag vs. chopchop. 

The only theoretical cons of frag attack is that it relies on known plaintext [but chopchop ultimately does so too] but this isn't a practical problem as virtually all 802.11 packets start with LLC/SNAP.  The only practical problem with frag attack is that some APs may trash fragments [in practice, most don't].

As hirte mentioned, one could expand the keystream in the forward direction in order to get a full 1500 keystream.  [So, chopchop style attacks can reveal a full 1500 byte keystream too, not making that a cons for them.]  In fact, the forward keystream expansion attack should be implemented.  Incidentally, the forward keystream expansion is useful for decrypting the IP address of a network:
1) Eavesdrop an ARP packet
2) XOR known-plaintext of ARP and cipher text [LLC, SNAP, ARP header]
3) Do forward keystream expansion to determine the IP of network.  You only need to decrypt 3 bytes making the attack fast.

[darkAudax]

sorbo,

As an anti-intrusion prevension technique, some APs to block non-local network IPs in this context and thus it is a constraint.  So that is why the wiki lists it as a limited con.

I would be interested in knowing how you can determine the network IP with only the xor stream and no other attacks.  The xor stream does not allow you to decrypt packets.

d.


 

[sorbo]

I guess I'm trying to sell fragmentation as strictly "better" than chopchop in cases that APs allow fragments

I still don't quite agree.  Yes, APs can firewall packets that it routes or that are destined to itself.  Typical firewalls operate at layer 3 and up [that is, will examine IP header and up].  Thus, sending layer two packets such as ARP, or indeed a packet with an unknown or other ethertype should "bypass" firewall rules.  If the packet is broadcast or multicast, it will get relayed.  I think that APs merely act as bridges when it comes to layer two packets and do not tend to do smart things [otherwise they could break many applications, as firewalls do ].

Has anyone ever had practical experience where an AP would not relay broadcast packets [regardless of packet type and IP used]?  I've never encountered this.  What I have encountered is APs that do not process fragments---this case must not be confused with "it's trashing my packets because I don't know the IP".

Regarding the IP discovery, I don't know.  I've thought about it for a while and failed.  I've even thought about crazy stuff like taking an encrypted packet [which will have an IP in it] and building up a multicast packet via multiple fragments in such a way that the destination IP would start with 224; the sniffed encrypted packet would now follow as a fragment and be placed in such a way that the first three bytes of its IP would follow the 224 in the partial header we created in the first fragment.  This way, the first three bytes of the IP could be read off the MAC address of the relayed packet, due to the direct mapping of multicast IP to MAC addr.  This is a generic decryption technique, but it doesn't work =D

[sorbo]

[Strong Assumption: I assume that the router doesn't check the multicast MAC addr when you send stuff to it and it will re-write it based on the multicast IP.  If the assumption doesn't hold [quite likely =(], the attack won't work---I/someone should experiment if implementations allow this.]

By the way, I just thought about an attack to discover the IP address.  Have a read on
http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf
The bitflipping attack is interesting Section 4.1 and checksum modification Section 4.4.1.

In short, it is possible to change a bit in an encrypted wep packet if you knew the plain-text of that bit.  This means that we can change a byte in the IP address given we knew the original byte.  The idea is to change the first IP byte to 224 so the packet becomes multicast, and then we can read three bytes from the MAC addr.  The complication is that we also need to fix the IP header checksum, but Borisov's paper explains how it can be done---if you like the attack, we can figure out how to do it practically.

Here's the attack:
1) Sniff an IP packet destined to the network [fromDS = 1 && addr1 != broadcast]
2) Guess the first IP byte [at most 255 attempts], and bit-flip it so that it becomes 224
3) Fix the IP checksum using techniques in the paper.  The most interesting one is the third that they explain.  Perhaps we can exploit the ToS field to compensate for the changed byte---the ToS field is most likely 0.
4) If the AP relays the multicast packet, read off the last 3 bytes of the IP address [in the dest MAC addr].

This means that with an average of 128 attempts, we obtain the last three bytes of the IP address.  We know the first byte too [it's our guess that succeeded].  This performs better than the forward keystream expansion technique on ARP packets [with expansion, you need at most 255*3 attempts instead of 255*1].

[darkAudax]

sorbo,

Lots of good material that I need to digest.  Appreciated.

Yes, I believe that the frag attack is superior to chopchop as well.  Many more things you can do with it.

With regards to chopchop, you mentioned in one of your postings that it can do 1500 bytes as well.  Although true, I have yet to see a 1500 byte packet come out of an AP.  So yes in theory but in practice, no.  Thus, I feel it is a con.  The frag attack assures you of 1500 bytes.   In the end it does not matter since usually in both frag and chopchop, the objective is get enough of a xor stream to forge an ARP packet.  Bottom line, a small amount of data is just fine.

d.

[sorbo]

Regarding the 1500 with chopchop-style attacks, I meant that if you do keystream expansion in the forward direction, then you can reveal 1500 bytes.  That is, "reverse chopchop" [actually, strictly speaking, chopchop is reverse-arbaugh ].  So, if you sniff a 100 byte packet, you do the usual chopchop business to figure out 100 bytes of keystream.  Then:
1) Guess the next byte of keystream [in this case, byte 101].
2) Send a broadcast packet which uses that extra guessed byte.  [In this case, send a packet of size 101].
3) If the AP relays the packet, the guess is correct and you found the next byte of keystream.  [In this case, byte 101].
4) Repeat until you reveal 1500 bytes of keystream.

I think this attack was first introduced by arbaugh, and chopchop is simply this attack in reverse [i.e. in the backward direction].  I find that the forward direction one is more useful than chopchop, especially when used to decrypt the initial portion of packets [e.g. for determining IPs].

But as you say, all you care about is finding ~50 bytes of keystream, enough to send an ARP packet for flooding.  Indeed, doing the forward keystream expansion is "better" because you decide how much keystream to reveal [with chopchop, you gotta do from end to beginning and can't stop half way].  In fact, I think you guys should consider implementing this if you haven't already... just to put the icing on the cake

As an aside, I think that a tool where you can "interactively" choose packets to decrypt [e.g. based on length, mac addrs, etc.] using the forward keystream expansion technique could become useful.  This is the only tool that I had on my TODO and never ended up developing.  This is useful for decrypting data on LANs that have no internet connectivity and therefore you can't do the frag redirection trick.  The tool could be smart and decrypt only the IP header and then prompt the user if decryption should continue based [e.g. user may not care about some protocols, IPs, etc.].  Or maybe there could be a bunch of rules defined and the tool doesn't have to be interactive.  There are many occasions where you don't have time to crack the WEP key and you only need temporary access anyway [e.g. airports].

[.NetRolller 3D]

BUMP!

I am bumping this thread because it looks like noone looked at the possibility of implementing forward keystream expansion in aireplay-ng for more than a year. I think it's an interesting possibility, and it shouldn't be ignored.