How to Hack Wireless WEP Connections in 10 Minutes or Less
Nowadays, many people tend to use wireless connections since utp cables are sometimes not acceptable. When their routers become access points, too few of them are properly protected. Most of them tend to use WEP as a means to protect their internet connection. Well, this is surely better than leaving the connection without any key, but it’s still not enough. From now on you’re highly adviced to use WPA2 for your internet connection security and you’ll shortly see why
For starters, for such tasks it’s a whole lot easier to use a linux system. I suspect that most of you have one if you’re looking at that tutorial or at least can easily get to one. We’ll be using aircrack-ng for this task, so go ahead and install it to your system.
At first open a root shell and issue the command:
This will show your your wireless connection adapter name and information. Remember what its name is, most probably it would be something like wlan0 or wifi.
If you need to be totally anonymous while doing this, you can also masquarade your mac number with the command:
macchanger --mac 00:11:22:33:44:66 [wireless interface name]
(don’t forget that you need to install macchanger if you do that, since it’s not an aircrack tool)
The first thing to do is put your wireless card in monitor mode. If you use a packet sniffer on your network, you’ll have probably heard of promiscuous mode. This is the mode in which ethernet cards work when a sniffer is fired. At this mode, when a network card gets associated to a network, the root user can capture every packet from every connection of the network. Monitor mode is something like that, but for wireless networks, with the important difference that one does not need to associate with the access point to monitor the traffic(which is great of course :D).
In order to put our card into that mode and start sniffing around, we need to issue the command :
airmon-ng stop [wireless interface name]
Now our wireless connection gets lost if we are connected to some router and we can now sniff freely. First of all, let’s see what wireless access points are out there.
airodump-ng [wireless interface name]
This command dumps all the wireless access points along with any clients that are probably connected to them. Just pick a wireless access point and see if it uses WEP. If it does, note its BSSID(which is in fact the mac address), its ESSID, which is its appearing name and channel(column CH).
Let me now tell you what the attack will be like. WEP used to be the standard for protecting a wireless network. WEP uses an RC family encryption algorithm, RC4 particularly. However, since RC4 is a stream cipher, statistical analysis is a real threat and it so happens that it’s devastating to WEP. At the process to follow, you will see that IVs are the important information to collect. If you need to know why WEP is not a good idea, read this great analysis at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html and especially the part i paste below :
WEP uses the RC4 encryption algorithm, which is known as a stream cipher. A stream cipher operates by expanding a short key into an infinite pseudo-random key stream. The sender XORs the key stream with the plaintext to produce ciphertext. The receiver has a copy of the same key, and uses it to generate identical key stream. XORing the key stream with the ciphertext yields the original plaintext.
This mode of operation makes stream ciphers vulnerable to several attacks. If an attacker flips a bit in the ciphertext, then upon decryption, the corresponding bit in the plaintext will be flipped. Also, if an eavesdropper intercepts two ciphertexts encrypted with the same key stream, it is possible to obtain the XOR of the two plaintexts. Knowledge of this XOR can enable statistical attacks to recover the plaintexts. The statistical attacks become increasingly practical as more ciphertexts that use the same key stream are known. Once one of the plaintexts becomes known, it is trivial to recover all of the others.
WEP has defenses against both of these attacks. To ensure that a packet has not been modified in transit, it uses an Integrity Check (IC) field in the packet. To avoid encrypting two ciphertexts with the same key stream, an Initialization Vector (IV) is used to augment the shared secret key and produce a different RC4 key for each packet. The IV is also included in the packet. However, both of these measures are implemented incorrectly, resulting in poor security.
The integrity check field is implemented as a CRC-32 checksum, which is part of the encrypted payload of the packet. However, CRC-32 is linear, which means that it is possible to compute the bit difference of two CRCs based on the bit difference of the messages over which they are taken. In other words, flipping bit n in the message results in a deterministic set of bits in the CRC that must be flipped to produce a correct checksum on the modified message. Because flipping bits carries through after an RC4 decryption, this allows the attacker to flip arbitrary bits in an encrypted message and correctly adjust the checksum so that the resulting message appears valid.
The initialization vector in WEP is a 24-bit field, which is sent in the cleartext part of a message. Such a small space of initialization vectors guarantees the reuse of the same key stream. A busy access point, which constantly sends 1500 byte packets at 11Mbps, will exhaust the space of IVs after 1500*8/(11*10^6)*2^24 = ~18000 seconds, or 5 hours. (The amount of time may be even smaller, since many packets are smaller than 1500 bytes.) This allows an attacker to collect two ciphertexts that are encrypted with the same key stream and perform statistical attacks to recover the plaintext. Worse, when the same key is used by all mobile stations, there are even more chances of IV collision. For example, a common wireless card from Lucent resets the IV to 0 each time a card is initialized, and increments the IV by 1 with each packet. This means that two cards inserted at roughly the same time will provide an abundance of IV collisions for an attacker. (Worse still, the 802.11 standard specifies that changing the IV with each packet is optional!)
Ok, since we now know that if we capture enough packets we can crack this, let’s go on and try it. Ok , so now you noticed the BSSID, ESSID and CHANNEL and we can go on and issue the command :
airodump-ng -c [channel] -w [packets.out] --bssid [bssid] [wireless interface name]
After you issue this command, packets.out will be capturing packets from that access point in order to be used for the statistical hack. However, it’s most certain that somebody is not downloading a new movie and so packets around the network will be scarce if any. So, what we need to do is inject our own packets to that connection. At that point, you need to have a network card that can inject packets, just do an “lspci | grep Wireless” and take a look at your model, or just go on and see if it goes on with injecting, if you encounter an error you’ll need to purchase a card that is able to do such a thing.
Mine, whi shows as Network controller: Intel Corporation Wireless WiFi Link 5100 is doing well
Now that you have your sniffer capturing packets, open another root shell and let’s try to cause some traffic. Issue the command :
aireplay-ng -1 0 -a [bssid] -e [essid] [wireless interface name]
This creates the connection to the AP, if it fails on the channel number, try again. When it connects, we now try to inject packets with :
airplay-ng -3 -b [bssid] [wireless interface name]
If things go well, your shell will go crazy with newlines saying that it injects more and more packets. In my case this worked but for some reason, after around 10.000IVs for some reason the connection was hanged and those IVs were not enough. So if this happens at your case, use this command:
aireplay-ng -2 -p 0841 -c FF:FF:FF:FF:FF:FF -b [bssid] [wireless interface name]
It will ask you if you want to use a certain packet, answer yes and watch it injecting loads of packets.
Now, open a new shell and issue the command :
aircrack-ng -n 128 -b [bssid] [filename]-01.cap
Remember to try both with -n 128 and -n 64 for 64-bit keys. From my experience, you’ll need about 20,000 IVs to hack a wep key. Once you have enough IVs the key will be presented to you. Just remove the “:” characters and you can now use these digits as your wep key