|
|
Before getting too far along in this section, let's make it very clear that attacks against the availability of wireless networks are not going to go away. In fact, they are so easy to do there isn't a lot of research into new ways to do them. If one of the most effective attacks against your network consists of turning on a microwave in the snack room, software isn't going to be able to do much about it.
This section covers two techniques: CTS/RTS injection and Michael countermeasures. There are quite a few more than this (many related to resource starvation on the AP), but these attacks should be sufficient.
Deauthentication and disassociation are not covered in this section. Suffice it to say, you can use the same techniques used throughout this chapter to kick users off networks to kick them off repeatedly, thus performing an effective targeted DoS. A slight twist on this is to send the packets to the broadcast address, targeting more than one user. Some clients, however, ignore these broadcast packets (Centrino drivers, for example).
The reason that 802.11 networks are so vulnerable to denial of service attacks is that they are designed to play nice with one another. Within the standard, there are two packets that help in this regard, the Clear To Send (CTS) and Request To Send (RTS) packets. These packets are different from any others mentioned in this chapter because they are control types, not management or data types.
Devices use RTS packets when they have something big to send, and they don't want other devices to step on their transmission. For example, consider a client with a large packet to send to the AP. Before sending the large packet, the client wants to ensure the whole thing gets there without a collision. Therefore, the client sends an RTS to the AP to reserve the air for the duration of the packet. If the AP agrees, it will send out a CTS packet, letting the device know it's okay to transmit. Every device (other than the one that sent the RTS) within the range of the CTS packet cannot transmit anything for the duration specified. Note that I said every device, not just devices that belong to the same network. This is one way overlapping 802.11 networks avoid stepping on each other's toes.
The reason the client doesn't send the CTS itself is known as the hidden node problem. Two clients on opposite sides of the AP may not be able to hear each other's transmissions. They must, however, be able to hear the AP. Getting the AP to transmit the CTS packet ensures that anything that could cause a collision at the AP keeps their radios quiet.
Of course, nothing stops an attacker from injecting these packets, bringing the throughput of a network near zero. When trying to DoS a network, there are two possibilities. The first technique is to transmit the CTS packets yourself. This means that anyone in range of your signal will be unable to transmit. The second technique is to send an RTS packet to the AP you are targeting. Once the AP gets the RTS packet, it will create a CTS for you. If you have a large high-power omni and you are aiming to do as much damage as possible, transmitting CTS packets yourself is most effective. If you are in superstealth mode using a highly directional antenna from a distance, you can hit the AP with an RTS packet, and it will create a CTS packet with a greater impact than you could have. Practically speaking, transmitting your own CTS packets will have a greater impact on bandwidth because you aren't rate-limited, as you would be when an AP creates them for you.
When performing an RTS attack, you must know the BSSID of the AP you are interested in targeting. Also, this example specifies a fake source address of 00:BA:DC:0D: ED. The AP will create CTS packets that are sent back to 00:BA:DC:0D:ED, even if there is no such client associated. Currently, most, if not all, APs fail to check if the RTS was created by an associated client.
In the following example, I have included some output from wget running on a victim machine to show what sort of effect this can have on a network's throughput. In this example, the victim network is on channel 3 and has a BSSID of 00:14:BF:3A:6C:EF. First, let's start a download; right now, I'm pulling a respectable 155K/s from kernel.org:
3% [> ] 1,723,120 155.29K/s ETA 04:42
Now, launch the attack. The -w flag tells pcap2air to wait 50,000 microseconds (half a second) between packets.
[root@phoenix:/home/johnycsh/airbase/tools/pcap2air]$ ./pcap2air -i ath0 -r madwifi -c 3 -n 10000 -f ../../dist-pcaps/ctrl/rts.pcap -d 00:14:BF:3A:6C:EF -s 00:00:BA:DC:0D:ED -w u50000 Ctrl:ToDS:0 FromDS:0 retry:0 power_mgmt:0 more_data:0 Wep:0 order:0 subtype: RTS (0xB) [TA 00:00:BA:DC:0D:ED]==>[RA 00:14:BF:3A:6C:EF]
And watch as the throughput gets cut in half:
12% [===> ] 6,022,232 84.08K/s ETA 05:32
Cutting the throughput in half by sending only two packets a second isn't bad, but you'll see that the CTS attack can be even more destructive. In this example, the AP limits the attack because it won't send out CTS packets any faster. Even if you sent RTS packets ten times faster, the effect on bandwidth is negligible.
The following attack illustrates how to launch a CTS attack with pcap2air. In it, I assume that the network I'm interested in is on channel 3. Unlike most of the other attacks, you don't even need to know the address of a valid BSSID or client to launch this attack. Similar to the previous example, bandwidth as reported by wget is shown before and after the attack is launched. In this example, I tell pcap2air to send out packets ten times as fast as the previous RTS attack:
5% [=> ] 2,878,624 213.73K/s ETA 03:33 [root@phoenix:/home/johnycsh/airbase/tools/pcap2air]$ ./pcap2air -i ath0 -r madwifi -c 3 -n 10000 -f ../../dist-pcaps/ctrl/cts.pcap -d 00:01:02:03:04:05 -w u5000 Ctrl:ToDS:0 FromDS:0 retry:0 power_mgmt:0 more_data:0 Wep:0 order:0 subtype: CTS (0xC) [RA 00:01:02:03:04:05] 23% [=======> ] 11,507,256 --.--K/s ETA 15:24
At this point, I have effectively brought the throughput down to zero for anyone unfortunate enough to be on channel 3.
There is very little you can do to prevent these sorts of attacks. A wireless IDS can log the events, but because control frames aren't authenticated (and, in fact, can't be since they are supposed to be honored even when they come from your neighbor's network), this attack will be effective for quite some time to come.
When the IEEE was designing the Temporal Key Integrity Protocol (TKIP), which is used by WPA, they had to come up with an algorithm that could be used to ensure a packet had not been modified by an attacker. WEP attempted to use the ICV for this, but it is ineffective against an active attacker. The new algorithm is called Michael, and the field it creates in the packet is called the Message Integrity Check (MIC).
Michael has to run on older, WEP-based hardware and is, therefore, very limited in its operations. Networks that use Michael to verify the integrity of a packet also have to include countermeasures. These countermeasures mandate that as soon as more than two MIC checks per second fail, the AP is to deauthenticate all users and force them to rekey. The AP is also required to instigate a one-minute blackout. An interesting consequence of this is that clients are required to let the AP know when a MIC check has failed.
If countermeasures were not used, an attacker might be able to inject traffic into a TKIP (think WPA)-protected network. This attack would be nowhere near as effective as similar attacks against WEP, however. Getting past all the safeguards would require an attacker to sit there and inject millions of packets, only one or two of which would be able to make it past the Michael MIC check. In order to stop an attacker from slipping in one packet out of a few million, the countermeasures were included.
If an attacker could cause the MIC check to fail on just two packets per minute, she could effectively disrupt service to everyone at the AP. Fortunately, for an attacker to inject a packet that fails the MIC check, she first has to get by a number of other checks. When receiving a TKIP-encrypted packet, the following steps have to happen.
First, the sequence number is examined. If the number is too small, the packet is dropped to prevent replay attacks. Next, the per-packet WEP key is created, the packet decrypted, and the ICV checked. If it fails, the packet is dropped. Finally, assuming the packet passes the first two phases, its Michael hash is computed and a check is performed to ensure it matches. The WEP ICV check stops most packets that have been modified due to noise or via an attacker before the Michael check is ever done.
In reality, though Michael countermeasures attacks might be interesting, they are not a genuine concern yet. Why bother with such an elaborate attack when there are so many other ways to interfere with a wireless network? Nonetheless, the potential for enacting the Michael countermeasures is clearly there; otherwise, they wouldn't be in the standard.
|
|