The 802.11 encryption algorithm known as WEP (Wired Equivalent Privacy) suffers from a serious encryption flaw which leaves it vulnerable to attack. This means that any network that is “secured” using WEP can compromised in a matter of minutes with a few simple tools. To demonstrate just how horrible a choice WEP really is, we will setup a test WEP network and walk through the process of cracking it wide open.
First and foremost, you need to setup a test wireless network “secured” with WEP for the purposes of this demonstration. Exactly how to configure your WAP (wireless access point) is beyond the purposes of this article, but be sure to specify 128-bit WEP as your encryption method, and use a random 32-digit hexidecimal number for use as the encryption key. One easy way to quickly produce a random key is to run:
ls /proc | md5sum -
This will produce something like this:
0123456789abcdef0123456789abcdef -
Use that as your WEP key, and once you’ve verified that it is working, throw it away and forget it. You now won’t be able to get on your own WEP network until you crack it and recover the “lost” key.
Next, you will need to download (on a different network!) a copy of BackTrack Linux. Grab the latest ISO image, burn it to a DVD, and then boot your computer from it. Choose the Start BackTrack FrameBuffer (1024x768) option from the GRUB menu, and let it boot up.
Before we proceed further, we need to know the MAC address of the victim WAP (the one you setup earlier, with a now-unknown WEP key.) To do this, first enable the wireless network device and then scan for your WAP’s MAC address:
ifconfig wlan0 up
iwlist wlan0 scanYou may need to run the last command (iwlist wlan0 scan) a few times in order to “see” your WAP. When it does show up, write down the access point’s MAC address, which will look something like this:
00:11:22:33:44:55
Also write down the channel the WAP is broadcasting on, for example, 6.
If your WAP isn’t broadcasting its information, you’ll have to do a bit more work, the details of which are not covered here. Search the web, there is plenty of information on wireless packet capture and inspection.
We next need to verify that your particular wireless network card supports packet injection. To do this, run the following:
aireplay-ng -9 wlan0If your wireless network card does indeed support packet injection, you should see a message like the following:
00:00:00 Trying broadcast probe requests... 00:00:02 No Answer...
We are now ready to begin, as we have all the pieces we need: the MAC address of the victim WAP, a wireless network card that supports packet injection, and a booted copy of BackTrack Linux.
To accomplish this, we will need to have several tools running simultaniously. To switch between virtual consoles on Linux, use the Alt key along with the appropriate F key. For example, the first virtual console is activated by hitting Alt+F1, while the third is Alt+F3. Got it? Good.
In the first virtual console, start the packet capture process by running:
airodump-ng --ivs --write capture -c <channel> --bssid <MAC> wlan0
For example, assuming your victim WAP is broadcasting on channel 2 with a MAC address of 12:34:56:78:90:ab, you would run:
airodump-ng --ivs --write capture -c 2 --bssid 12:34:56:78:90:ab wlan0
You should see a rapidly-updated display of the data capture statistics. The two key things to note are first, Beacons, and second, #Data.
There are a number of different frame types that 802.11 stations (both network cards and access points) use to support wireless data communications. While data frames carry information from higher layers (see the OSI model), the 802.11 specification also includes management and control frames that support data transfer. Among these, the beacon frame (a type of management frame) provides the “heartbeat” of a wireless network, enabling stations to establish and maintain communications in an orderly fashion.
If the beacon frame count isn’t increasing second-by-second, then something is wrong: maybe you are too far from your victim WAP (signal antenuation), you typed the WAP’s MAC address wrong, etc. Check everything and try again.
Assuming the beacon frame count is happily incrementing away, take a look at the data frame counter. It needs to be high, really high, in order for us to successfully recover the WEP key. We are only capturing initialization vectors (IVs), and we’ll need a few tens of thousands of them for our attack to succeed.
In cryptography, an initialization vector (IV) is a block of bits that is required to allow a stream cipher or a block cipher to be executed in any of several modes of operation to produce a unique stream independent from other streams produced by the same encryption key, without having to go through a (usually lengthy) re-keying process. The WEP encryption algorithm uses a short, 24-bit IV, leading to re-used IVs with the same key, which in turn will allow us to crack it. It is this specific cryptographic flaw that we are now working to exploit.
So as to not waste time capturing more IVs when we actually need, let’s fire up a second virtual console (Alt+F2) and start the WEP cracking process on the IVs we’ve captured so far:
aircrack-ng capture-01.ivs
It will immediately start testing WEP keys against our captured IVs, and will almost certainly halt after a few seconds with the following message:
Failed. Next try with 5000 IVs.
Now, we could go off and get a cup of coffee, watch some TV, take a nap, go on vacation to Europe, etc. while we wait for enough IVs to trickle in, or we can crank this shit up and force a flood of IVs to arrive. Ready? Let’s do it!
Leave aircrack-ng running; it is intelligent enough to automatically resume cracking when more IVs have been captured.
First, a word of caution: what we’re about to do, to stimulate the production of IVs by the victim WAP, also amounts to a denial of service attack against the entire wireless network, as communication will become virtually impossible while we attack the WAP. Needless to say, don’t do this to a wireless network if you’ve got other computers or people actively using it.
Open a third virtual console, and fire up a copy of aireplay-ng to associate ourselves with the victim WAP every five seconds (as it will shortly be doing its level best to deauthorize us):
aireplay-ng -1 5 -a 00:11:22:33:44:55 wlan0
Of course, replace 00:11:22:33:44:55 with the MAC address of your victim WAP. You should start seeing lines like these:
00:00:00 Sending Authentication Request (Open System) 00:00:01 Authentication successful 00:00:01 Sending Association Request [ACK] 00:00:02 Association successful :-) (AID: 1)
Open system authentication, despite its name, does not provide authentication. It provides identification using the wireless adapter’s MAC address and the WAP’s MAC address. Open system authentication is very commonly used with WEP, as it is the default authentication algorithm on most WAPs.
What is basically going on is that (1) the authentication-initiating wireless client (that’s us) sends an 802.11 authentication management frame that contains our identity, namely, our MAC address. (2) The receiving station (the WAP) checks the initiating station’s identity and sends back an authentication verification frame.
With some WAPs you can configure a list of permitted (or blocked) MAC addresses; however, this is basically useless as a security precaution as MAC addresses are trivial to spoof. In fact, if instead of the above you see a line like the following:
Attack was unsuccessful. Possible reasons:
* Perhaps MAC address filtering is enabled.
* Check that the BSSID (-a option) is correct.
* Try to change the number of packets (-o option).
* The driver/card doesn't support injection.
* This attack sometimes fails against some APs.
* The card is not on the same channel as the AP.
* You're too far from the AP. Get closer, or lower
the transmit rate.Chances are the WAP has MAC address filtering enabled. Working around this minor roadblock is beyond the scope of this article, as there is plenty of information on spoofing wireless MAC addresses available on the web. Besides, you didn’t configure your WAP to limit MAC addresses, did you?
So let’s review before we launch the truly intrusive part of this process, the ARP request replay attack. In the first virtual console, we’ve got airodump-ng running, capturing IVs as they are seen by our wireless network adapter. In the second console we’ve got aircrack-ng working on recovering the WEP key from the IVs being fed it by airodump-ng. And finally, in the third console, we’ve now got aireplay-ng running, repeatedly authorizing us to the victim WAP.
Let’s now start a fourth and final virtual console (Alt+F4) and fire up another copy of aireplay-ng:
aireplay-ng -3 -b 00:11:22:33:44:55 wlan0
Obviously, replace the above MAC address with your victim WAP’s MAC address. You should see a message like the following:
00:00:00 Waiting for beacon frame (BSSID: 00:11:22:33:44:55) on channel 4 Saving ARP requests in replay_arp-0123-456789.cap You should also start airodump-ng to capture replies. Read 100 packets (got 0 ARP requests and 0 ACKs), sent 0 packets...(0 pps)
What’s going on here is that aireplay-ng listens for an ARP packet to arrive from the victim WAP. When one is seen, it retransmits it back to the WAP. This, in turn, causes the WAP to assume something is wrong and to repeat the ARP packet with a new IV. aireplay-ng retransmits the same ARP packet over and over, very rapidly, and each time the WAP sends a new IV. Needless to say, this causes the number of IVs that we are capturing to grow very rapidly. (Remember, however, that a major side effect of this is to make the wireless network unusable so long as you’re running the ARP replay attack.)
At this point you might need to take a break. It could be a few seconds to a few hours before the WAP walks blindly into our trap by sending an ARP packet. The busier the wireless network, the sooner an ARP packet will be sent; but as this is a test network it’ll probably be a while.
Once that first ARP packet shows up, however, things will get interesting really fast. If you flip back to the first console (Alt+F1) you’ll see the data frame count simply exploding. Flip to the console with aircrack-ng and it should shortly resume cracking, and within a minute or two, display the following message:
KEY FOUND! [ 01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF ]
Write the key down, and quickly flip through your virtual consoles, hitting Ctrl+C to shut them down and go dark.
Reboot into your usual operating system, and try connecting to the wireless network using the WEP key you recovered. Boom! You’re in, and you’ve just received a very valuable lesson on why you should never use a worthless encryption method like WEP for securing an actual, mission-critical wireless network.
