|
|
< Day Day Up > |
|
Wireless Encrypted Traffic Injection Tools: WepwedgieIn the previous section we reviewed the tools designed to send a variety of 802.11 management and control frames. How about injecting encrypted data into the wireless network to bring an attack to the higher OSI layers? One encrypted traffic injection tool, the Wnet's reinj, was already described when discussing WEP cracking acceleration. Reinj works by duplicating predictable packets on the WLAN. However, traffic duplication is not the only way to insert encrypted data into the attacked 802.11 net. You don't need to know the whole WEP key to inject traffic; knowing a part of the keystream for a specific IV is enough to inject valid data. How would we find out the part of a (pseudo-random or PRGA) keystream? If we know the plaintext and the corresponding cipher text we can XOR them to obtain a part of the keystream. As outlined in Chapter 11, packet headers, which have to adhere to the protocol standards, are a good source of known plaintext data. However, WEP-based shared key authentication on 802.11 WLANs provides an even better source of plaintext/ciphertext data pairs. It is based on sending a plaintext nonce to the authenticating host. The nonce is then encrypted with the WEP key and sent back to the access point, which verifies if the key is correct. Thus, capturing both plaintext and enciphered nonce, as well as the cleartext IV, gives an attacker a wonderful opportunity to obtain a valid part of the keystream. The only tool that implements this attack in practice is Anton Rager's Wepwedgie. Once thought impossible, this toolkit allows you to inject traffic into WEP-protected wireless networks without knowing the secret key. At the time of writing, the tool exists in the alpha stage. It was initially released at Defcon 11 during Rager's presentation, where we had the pleasure to be present. Wepwedgie uses the AirJack drivers to inject data. Currently it consists of two parts, the sniffer and the injector. Prgnasnarf is the sniffer part of the suite that listens for the shared key authentication frames exchange to obtain both IV and PRGA keystream. Wepwedgie is a traffic injector that employs the captured keystream to insert custom-built packets into the attacked network. The use of the sniffer is rather straightforward: arhontus:~# prgasnarf -h prgasnarf 0.1.0 alpha: A 802.11 WEP packet keystream decoder. This version looks for shared-key-authentication and derives a keystream. Usage: ./prgasnarf [ -c <channel number> ] [ -i <interface name> ] -c: channel number (1-14) that the access point is on, defaults to current. -i: the name of the AirJack interface to use (defaults to aj0). All you have to select is the AirJack interface and the channel to sniff on. Now wait patiently until the authentication occurs and your sniffer steals the needed data (or flood one of the client machines with deauthentication frames to cause reauthentication and grab your frames). Once the authentication frames exchange is intercepted, it is saved for later use in the prgafile.dat file. You might consider renaming the saved file to something more memorable (using the network location, SSID, etc.) and create a symlink to the prgafile.dat, so when you move between different sites it is easy for you to adapt the toolkit to the network of interest, without sniffing the authentication exchange once again. When the needed data is obtained, the examination of the "protected" network can commence. Various scanning methods are already included in the Wepwedgie toolkit, but do not expect it to be as advanced as nmap or other high-grade scanning utilities that allow FTP bounce or idle scanning for IDS evasion. Taking into account the inherent stealth and anonymity of wireless attacks (see Chapter 2), the attackers can stay out of reach even without the capability of these traceback avoidance methods. The syntax of Wepwedgie is relatively complex: arhontus:~# wepwedgie -h wepwedgie 0.1.0 alpha: 802.11 WEP known keystream injection tool. Usage: ./wepwedgie [-d <destination mac> ] [ -c <channel number> ] [ -i <interface name> ] To run the Wepwedgie scans successfully, the attacked WLAN needs a gateway to the wired network (e.g., the Internet), as well as you having a host on that network set up to sniff the incoming traffic (we use tcpdump). To determine the gateway address, both common sense and the author of the tool suggest monitoring the traffic to find a host passing the largest traffic volume. Such a host is likely to be the gateway you are looking for. Let's walk through several examples of each predefined scan and injection type supported by Wepwedgie.
Here we chose to use the AirJack interface 0 (-i aj0) and inject traffic on channel 11 (-c 11). The destination MAC is the MAC of an internal interface of the host connected to the wireless network and acting as a gateway separating the LAN and a demilitarized zone (DMZ;) -d 00:01:02:03:04:05). The target host IP (-t A0:A8:4D:08) is a WLAN host address. The host ID parameter is not entirely necessary, as the tool automatically increments the ID from 0 to 255. (Note: Wepwedgie only accepts IP notations in the HEX form, so in the example given, A0:A8:0B:08 is the address of the wireless host 192.168.11.08.) The helper host IP (-h A0:A8:162:0A) sends traffic to the test machine in the wired DMZ zone running tcpdump. To make it easier to look for the responses to our pingsweep, run tcpdump as "# tcpdump -n -i eth0 proto 1" and grep for the "icmp: echo reply" string. You should see the echo replies coming from the hosts responding to our ping, and icmp: host unreachable packets for the unoccupied IPs. The tcpdump output on the helper host should look similar to this: ..... 20:01:17.820102 192.168.11.7 > 192.168.22.10: icmp: echo reply 20:01:17.951850 192.168.11.8 > 192.168.22.10: icmp: echo reply 20:01:17.953839 192.168.11.9 > 192.168.22.10: icmp: echo reply 20:01:18.870372 192.168.22.101 > 192.168.66.10: icmp: host 192.168.11.1 unreachable [tos 0xc0] 20:01:19.410441 192.168.22.101 > 192.168.66.10: icmp: host 192.168.11.2 unreachable [tos 0xc0] 20:01:19.580451 192.168.22.101 > 192.168.66.10: icmp: host 192.168.11.3 unreachable [tos 0xc0] .....
Here we opt to test firewall rules of our wireless gateway. Most of the command-line options are left as in the previous example, except for specifying the different scan type. In this scanning mode, Wepwedgie automatically tests several predetermined rules to try and find out what type of traffic is allowed to leave the wireless network onto the wired side. You can define your own set of predetermined filtering rules by editing the source code of Wepwedgie; here we give you a sample string of adding the rule to check whether the traffic is allowed to pass through TCP port 31337: ### frame_builder(auth_prga, 136, auth_iv, bssid, source, dest, 2, target_ip, helper_ip,6666 The tcpdump output on the helper host should look similar to this: 20:21:03.660933 192.168.22.101.2025 > 192.168.22.10.21: S 0:0(0) win 8192 (DF) 20:21:04.526103 192.168.22.101.2026 > 192.168.22.10.22: S 0:0(0) win 8192 (DF) 20:21:04.526238 192.168.22.105.22 > 192.168.22.101.2026: S 2626590707:2626590707(0) ack 1
These scan types are used to examine the host inside the WEP-protected 802.11 LAN for open TCP and UDP ports. By default, Wepwedgie scans for open unprivileged ports (0–1024), but you can easily change it to any port range you like by editing the source code and recompiling the tool. For a TCP scan result, you should receive a TCP RST if the port is closed or a SYN/ACK if the port is open, provided that you have performed a casual SYN scan. Wepwedgie allows you to construct any type of TCP packet and emulate most of the TCP scanning techniques supported by Fyodor's NMAP. To do so you can edit the source code of Wepwedgie and change the default 0x02 value in the TCP construction part to 0x10=ACK, 0x12=SYN/ ACK, 0x04=RST, 0x14=RST/ ACK, and so on. The TCP SYN Wepwedgie scan tcpdump output on the helper host should look similar to this: 20:33:09.648584 192.168.11.6.22 > 192.168.22.10.80: S 3860910504:3860910504(0) ack 1 win In the case of UDP scanning, you should receive an ICMP port unreachable packet if the port is closed. Bear in mind that the UDP scan is slow and unreliable. To get a reliable result, you will have to run the UDP scan several times, analyzing all the received responses once again and comparing them with the previous results. The Wepwedgie UDP scan tcpdump output on the helper host should look similar to this: 20:38:17.898804 192.168.11.6 > 192.168.22.10: icmp: 192.168.11.6 udp port 1 unreachable When using the Wepwedgie toolkit, we strongly recommend reading through the source code and understanding how it works, as you are likely to modify it for your particular needs rather than use it straight out of the box, since it is still in the alpha stage. |
|
|
< Day Day Up > |
|
[-s <ssid_len>]
-d: destination MAC to use on L2 net. defaults to broadcast address.
-h: helper IP [ie 0a:0a:0a:10]. IP for internet reception of responses/injection.
-p: helper port. Port for internet reception of responses/injection. Defaults: TCP