New experiments.

I've been using wep_tools to crack observed wifi traffic while the interface is in promiscous mode. An interesting article describing some internals of this program is unfortunately in PowerPoint, but you can translate it into HTML with Google.

wep_tools is a set of tools containing :

• wep_crack, a program dedicated to find the WEP keys of a set of captured frames, in the pcap format. It can work using brute force for 40 bits WEP and with a words dictionnary for 128 bits WEP keys.
• wep_decrypt, another program used to decypher captured frames, with the WEP keys discovered by the previous tool.

wep_crack is supposed to use a capture file generated by prismdump, but this program freezes in an unfinite wait in function recv(), so the capture file has been generated with 'tcpdump -i wlan0 -w capture.log -c 100 -s 0'.

The frame has to be idenfified by the pcap filter as DLT_IEEE802_11 and not as DLT_PRISM_HEADER (see /usr/include/pcap/net/pbf.h), so verify that you pass the option 'prismheader=false' when setting the promiscuous mode with wlanctl-ng.

Also I put 'keepwepflags=false' to have valid Data packets when reloading the capture file in ethereal : ethereal -r capture.log

• Truncated captured packets will cause problems to wep_crack, as it is relying on the whole encrypted data. A small modification in packfile_read(): don't exit if hdr.len != hdr.caplen for one packet.
• Another possibility : add a '-s 0' option to tcpdump to allow it to capture the whole packet and not only the first 96 bytes... So it makes wep_crack happy.

Test with WEP128

The length of the searched WEP key is set with '-s (strong)' flag. With WEP40, you can try the brute force algorithm (-b) and with WEP128, you must proceed with a dictionnary. The algorithm used to generate the wep key from a given string from the dictionnary is given in wep.c and appears to be different from the one used by 3Com on our access point, so the search with a dictionnary is not usable if the WEP key has been generated on a 3Com equipment [TODO: search if this string to wep key conversion algorithm is available somewhere, or has been reverse enginered].

Test with WEP40

The cracking algorithm supposes that the 4x5bytes keys are generated from a unique seed, and iterates over this seed (0x1000000 possible values excluding (x & 0x808080 != 0)), generates the five keys, and test them against a given packet. This algorithm is fast (1 or 2 minutes), but misses my WEP key, probably because of an unusual algorithm used by 3Com. Exhaustive search of a single 40 bits key would require approx. 110 days on a regular PC.

If you use the nwepgen keys generator provided in the linux-wlan-ng package, wep_crack successfully find your key in a time < 1 min :

[root@bonobo linux-wlan-ng-0.1.16-pre8]# ./src/nwepgen/nwepgen toto 5
c0:b6:76:bc:08
ba:15:22:4c:cb
86:1b:bb:ac:98
0c:b8:86:dc:0d

You manually enter the first hexadecimal key in your access point.

[root@bonobo wep_tools]# ./wep_crack -b capture.log
success: seed 0x00746f74,  [generated by AAAa5.5a]
wep key 1: c0 b6 76 bc 08
wep key 2: ba 15 22 4c cb
wep key 3: 86 1b bb ac 98
wep key 4: 0c b8 86 dc 0d

As a bonus, the algorithm gives you a valid string among others, that generates these 4 WEP keys.

Conclusions

• The unknown algorithm used by 3Com to generate the wep keys prevents me from theses key to be divulgated by this program, but this is in no way a good protection. Security through obfuscation will never be a valid policy.
• 40 bits WEP keys from a string generator are intrinsequely weak. Brute force of the seed space takes less than 2 minutes on a small PC.
• 128 bits WEP is still robut enough, as it requires a dictionnary based exploration.
• My advice would be : don't rely on WEP keys generated by a passphrase, use your OWN randomly generated hexadecimal values.

$Id: wireless3.html,v 1.3 2003/10/19 20:36:04 bellet Exp $