![]() |
|
|
#1 (permalink) |
|
Posts: n/a
|
BSD airtools.
I'm working on a project in my home lab with the BSD airtools kit from Dachb0den labs, and I'm curious if anyone else has had a chance to give this stuff a go.
My question is...given a network running 128 bit WEP, how many interesting packets have been typically required to get enough info to make a correct guess at a WEP key? Thanks! -A.G.- |
|
|
|
#4 (permalink) |
|
Posts: n/a
|
I had an argument with a guy about that..
It seems to me that if someone is going to flood your connection looking to break your wep keys, you could easily monitor the traffic and see that happening.. So much for a passive attack... Then you bust out the directional antennae, walk up to his van, drag him out and beat him half to death....with his own equipment.. ;-)
|
|
|
|
#5 (permalink) |
|
Posts: n/a
|
That's more like network jamming...
Cracking the keys is supposed to be passive. I passively collected about 2000 weak keys last night with a traffic generator and a spare laptop. I have observed that running crack with a breadth of 1 or 2 always fails...so I tried a breadth of 3 and it also failed. Now, I have crack running at top levels 4 and 5...and I'm trying to figure out about how long that takes. Fortunately, I have a dual-processor box heating my office working on this problem (BP6 dual 550). While the program is out there, there are very few people who seem to have actually used it successfully. I'm curious because I may be picking up an assignment at work to determine how secure the WAP network really is. I may be presenting up through the Senior Vice President...but I have to write a project proposal first. Knowing the approximate time to crack would be nice. As far as network jammers, I am all for beating the ass out of them. ![]() -A.G.- |
|
|
|
#6 (permalink) |
|
Posts: n/a
|
Those examples of cracking WEP keys were all 'lab tests'. I'm not suggesting that you udp flood the network to crack the WEP key....actually, I don't think you could do that until you had the WEP key. That was basically an example of what you're already finding out....cracking WEP isn't half as easy as what you'd think reading some of these articles stating that WEP is basically a joke. Maybe it's a joke for some people but I don't know any of them.
Secure enough for the FBI - probably not...at least hopefully not! Secure enough to run my home network on - probably. Then go and run a closed network, limit access to MAC addresses, watch the logs and things are gonna be pretty secure....at least for now. It does seem to me that if you had one WEP encrypted packet (or maybe 1000) that you should be able to run some kind of software against those packets for a week or two, or a month and eventually crack that WEP key since I believe the WEP key is XORed with the valid data. With 1000 packets, you could pretty well determine that you'd come up with the right key if they all 'made sense'. I don't really understand the encryption that WEP uses so this idea may be totally bogus but it seems good to me ![]() |
|
|
|
#7 (permalink) |
|
Posts: n/a
|
The fast part of the lab test was to gather enough weak packets to run a statistical analysis on them to determine the best value for the key. I can get a good number of packets in less than a day...a process which may take several days in a real world setting.
Unfortunately, it seems that running the crack to do that statistical analysis requires a significant amount of power if you don't have all the weak keys. Anyway, here is the AirSnort theory on weak keys: // --- Capture Details --- Useful packets are those with the following property of their IV; the first byte is a number three greater than one of the offsets of the bytes of the key. For 128 bit encryption, this means a number from 3-16. The second byte must be 255 and the third byte can have any value. This means that for every byte of the key, there are 256 weak IVs. When every weak IV has been gathered (13 key bytes * 256 = 3315 packets), there is no point to continuing the capture process. In reality, it takes somewhat fewer packets than this. // --- Now, determining what weak keys have actually been gathered in the overall total is somewhat interesting because invariably many of them get repeated, and there is no need for dupes. I don't have all the values, though...as this sample happily shows: Performing crack, keySize=128 bit, breadth=5 Key Byte 0: 174 samples Key Byte 1: 146 samples Key Byte 2: 169 samples Key Byte 3: 160 samples Key Byte 4: 165 samples Key Byte 5: 164 samples Key Byte 6: 161 samples Key Byte 7: 148 samples Key Byte 8: 162 samples Key Byte 9: 154 samples Key Byte 10: 170 samples Key Byte 11: 161 samples Key Byte 12: 150 samples Check samples: 10 Once my GF heads home tomorrow, I'm intending to generate enough traffic over the next week such that I can get all the key bytes and then see how quickly a key can be obtained at that time. The most promising aspect of this kind of discovery is that while the crack may work, the persistence required to pull off the captures and a successful crack may actually take a _lot_ more resources than originally anticipated. -A.G.- |
|
|
|
#8 (permalink) |
|
Posts: n/a
|
Let me know how your tests turn out. I haven't been able to personally fully test the bsd-airtools verison of airsnort to make sure it works, but I've heard from a couple people saying it does. Also, we'll be adding in a bsd port of prismdump fairly soon so those of you using bsd can use wepcrack to try and brute force keys (as well as ethereal and the other prismdump based apps that have been linux specific up until now).
|
|
|
|
#9 (permalink) |
|
Posts: n/a
|
dweputils
For those of you that run bsd and want to do some wep cracking.. I'll be releasing my own implementation of "Weaknesses in the Key Scheduling Algorithm of RC4" either later on today or tomorrow that you can try out if you like. I have been able to verify that my implementation works almost all the time as long as you have at least 60 weak ivs for each key byte. I'll also be providing test logs so you can try it out for yourself without having to wait a few hours to generate enough traffic. I've also implemented some of Tim Newsham's wep_tools methods into dweputils which allows you to brute force using the 21-bit password generated key space in a fairly small amount of time (around 30 seconds on my G4 Powerbook, or 10 seconds on one of our quad xeons). There will also be support for brute forcing the entire 40-bit or 104-bit keyspace (if you have a fast enough machine or distributed environment), cracking using a wordfile, and multi-process SMP support for FreeBSD.
http://www.dachb0den.com/projects/bsd-airtools.html |
|
|
|
#11 (permalink) |
|
Posts: n/a
|
Dweptools
When ever I try to install one of the dweputils I get an error : bat/common.h: No such file or directory.
I notice the c program dwepdump.c has an include statement for this. Where am I supposed to get this from? I'm using freebsd 4.5. Keep in mind that I am not very unix savvy. Thanks |
|