Implementation of new fragmentation attack

[darkAudax]

Hirte,

Interesting meaning...

The STP packet has a constant destination mac address so it could easily picked out of a packet stream.

The iTunes packet has the same destinaton mac address each time:
09:38:53.097901 00:40:f4:77:e5:c9 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 88: (tos 0x0, ttl 255, id 28207, offset 0, flags [none], proto: UDP (17), length: 74) 192.168.55.1.mdns > 224.0.0.251.mdns: [udp sum ok]  0 [2q] PTR? _daap._tcp.local. PTR? _raop._tcp.local. (46)

One thing that I just noticed is that it is UDP.  Can UDP packets be used to gather the initial xor?

I have also seen similar scenarios for for HP printers and there are lots of them out there.

d.

[Hirte]

Can UDP packets be used to gather the initial xor?

I have also seen similar scenarios for for HP printers and there are lots of them out there.

yes, udp packets are normal ip packets and all ip packets have the same llc/snap header "\xAA\xAA\x03\x00\x00\x00\x08\x00". so they should work like all the other tcp/icmp packets.

i meant "interesting" in a way, that the first 7 bytes differ from "\xAA\xAA\x03\x00\x00\x00\x08", as in that case the attack won't work and i'd like to know what the first 7 bytes are, based on the destination mac address.

[darkAudax]

Hirte,

OK, this is the second edit for the day on this posting.  I have been researching how to see the llc/snap header. I have found that if the data is transmitted in the clear, you pick up the llc/snap header.

I am attaching a couple of strange ones for you and one "interesting" packet for you.  Look at the strange ones.  They are arps from the same mac address.  One has the same bit sting you mention and second one has an organization code of Cisco IOS 9.  That would explain why in some cases, the frag attack would not work.  IE the llc/snap header is different then you expect.

The other one is a potentially interesting packet since it has a distinct destination mac address and a specific llc/snap header.  Is this what you meant?  If yes, will start looking for this class of packets and add them to a trac ticket.

d.

[darkAudax]

Hirte,

Got one more question.  Is there any other way to get the llc/snap headers except for transmitting the data without encryption?

d.

[Hirte]

we could read through all the protocol definitions, but that's very time consuming and not effective at all. a simple way would be to find a webpage, like the one i posted 7 posts ago, where the llc/snap header is specified together with the protocol/vendor and the used destination address.

i'll have a look at the captures you attached, thanks.

EDIT:
The arp packet is very interesting, but there is no way to know whether the captured arp uses 0x0000F8 or 0x000000. So the only thing we could do is testing f8, after 00 failed. But we could simply wait for another packet.

Best thing would be check if there are already captured packets, then decide based on this, if we should try the new packet or reuse the old, this time with f8.

The Netbios support is trivial, as we can use the unique destination address to identify these frames. Up to this point, i guess netbios frames are producing false positives, as the first 2 bytes are F0 instead of AA. And even further, if the tested frames (while cracking the key with aircrack), ie the first, the sixth and the eleventh frame are netbios frames, the cracking WILL fail, because it checks the first 2 bytes if they are AA, E0 or 42. This would be okay, as long as airodump replaces AA by F0 for the mentioned frame, but this isn't the case right now.

[darkAudax]

Hirte,

Yes, I did take a look at the URL when you first posted it.  It struck me as a very long list.  I agree with you that an automated scan is not worthwhile.  My thinking was that as we came across interesting real life packets that could be documented then those get added in at your convenience.

d.

[Hirte]

i reopened the corresponding ticket http://trac.aircrack-ng.org/ticket/18 and we should build a list with all the packets found, that do not start with \xAA\xAA\x03\x00\x00\x00\x08 and that can be identified. currently ip, arp and spanning tree packets are supported, as those are the most common packets out there.

[darkAudax]

Hire,

I will start adding them as I find them.

BTW, the arps in the "strange arps" file are not something I would suggest adding.  I think they are not very general.  Maybe I will change my mind once more are found.  At this point, it more FYI.

d.

[darkAudax]

Hirte,

I finally got time to pursue investigating the "interesting" packets from itunes and my HP printer.  It turns out that frag attack works perfectly on those packets already.  So even though they have strange MAC broadcast addresses, the underlying packet is normal.

I will continue to keep my eyes open.

d.

[sorbo]

I'd recommend you read:
http://darkircop.org/bittau-wep.pdf
In particular, read section 2.3 which is not present in the toorcon paper you cite.  This section outlines how to decrypt data using the fragmentation attack, in real-time, without knowing the key.  It assumes Internet connectivity of the AP being owned [and the attacker].

I'm not going to discuss theory here as there is enough in the paper.  I'll mention some implementation notes and practical issues.  In short, decrypting with that mechanism works great in practice.  You can get ping times under 100ms and establish [graphical] WWW connections to the AP and so on.  That is, the network is actually usable.  The greatest use of this attack is to connect to the AP, login with default login and password, and then read off the WEP key from its configuration.  This works quite well in practice.  Even though people turn on WEP, not all change the password of their APs.  Furthermore, many ISPs sell plug and play boxes with WEP enabled, but default passwords for AP configuration.  In practice, the "log-into-ap-without-knowing-wepkey-and-reading-key-off-config" attack takes under 5 minutes and is definitely worth it, or at least a useful first try before going into the more time consuming weak IV attacks.

Here are rough implementation notes:
* Do the frag attack to get 1500 byte keystream.
* Use forward keystream expansion to decrypt network IP [needed to set correct source IP---haven't tried if it will still work and NAT/route you with a bogus one].  If ARP packet is sniffed, only 3 bytes need to be decrypted.  The multicast keystream expansion implementation takes well under a minute for this.
* Send arp who-has to network IP ending in .1 and assume that is AP MAC addr.  Works well in practice.  You can send a DHCP request if you want, and assume the reply comes from the router or decrypt the reply using chopchop/forward expansion.
* Create a tap interface; set its MTU to 1400.  TX using 1500 byte keystream.  RX by resending to buddy on Internet; add IP & UDP header.
* Redirecting MTU packets works well in practice---many APs are routers and will IP fragment.
* Queue packets to redirect and retransmit them if necessary, do some congestion control [keep an end-to-end RTT estimate for timeouts and retransmissions], only redirect packets that are destined to yourself.  Broadcasts are not necessary; however, make sure you keep the ARP cache of who you are talking to fresh or you won't get data back [that is, whoever you are talking to may send an ARP who-has which you may not redirect and therefore never reply to; to avoid this, periodically send back ARP replies or who-has with your MAC/IP pair].
* If hacking using a single wifi card, connect to the internet using another wifi network in range.  [Create tool that associates to network and uses it even when in monitor mode.]

Personally, I think this is the killer wep attack and is definitely my first choice.

[*dudux]

hi 

i have a problem with chipset atheros y afrag.....I never get the keystream............

I have only one interface in mode monitor.....i  am associated with the AP...............i run airodump and then run afrag........the same that i do the fragmentation attack with rt2570.................but never I get the keytream.........

i`m using aircrack-ng mother fucker edition 1.1 ( the same aircrack-ng 0.7 ) and afrag............

which is the problem???


Thanks and regards

[darkAudax]

dudux,

With Atheros, it is critical that the MAC address of your card match the source MAC address you are injecting with on the frag attack.

Also the standard... be sure to do the fake auth, be physically close enough, etc.

There was some code changes incorporated into the final aircrack-ng frag attack to make it work well with Atheros.  You should really use aircrack-ng.

d.

[*dudux]

dudux,

With Atheros, it is critical that the MAC address of your card match the source MAC address you are injecting with on the frag attack.

Also the standard... be sure to do the fake auth, be physically close enough, etc.

There was some code changes incorporated into the final aircrack-ng frag attack to make it work well with Atheros.  You should really use aircrack-ng.

d.

ok.... i will work with aircrack-ng 0.7.........and then i´ll say you................

thanks  darkAudax


Regards

[*dudux]

for ASPj ......

When do we will be able to enjoy AFRAG with chipsets rt73?


because the rt2570  already it is not made..............

[ASPj]

Well, I only have a rt2570 card.

You could try and analyse the changed between version 1.4.0 and 1.4.9 from my homepage. If you are LUCKY the driver for your rt73 is similar and maybe you can easily port the changes to the rt73 driver and enjoy it finally.