CTS DoS Mini-HOWTO

Most of the following text and images were excerpt and translated from my Master's Thesis Security Analysis of the IEEE 802.11 Standard where more information can be found (in Slovak, though).

You should already be familiar with getting your wireless card to transmit in monitor mode. If not, please refer to the thesis and/or other sources for that.

RTS/CTS Fundamentals

Due to the possibility of hidden nodes in a WLAN, the IEEE 802.11 Standard defines the Request To Send (RTS) and Clear To Send (CTS) control frames, to minimize collisions when sending longer frames.

The picture shows an example of using this technique. STA1 and STA3 may be far from each other, out of radio range. That means STA1 doesn't know when STA3 is transmitting and vice versa. If STA1 wants to send a longer frame to the AP and avoid a possible collision, it first sends an RTS to request a reservation of the channel for a given Duration period. The AP may respond with a CTS frame which reserves the channel for STA1 for the Duration. This CTS will be sent to each station so that they know only STA1 (identified by its MAC address in the CTS frame) is allowed to transmit during that time.

Flooding CTS Frames

CTS frames are very small and simple. They are used to allocate the channel for a given duration, sent by a station or the AP as a response to an RTS frame.

The picture shows an example of a CTS frame - Frame Control: Type 1 (Control), Subtype 12 (Clear To Send), Flag bits set to 0 (some other flag combinations are just as good). Time given in the Duration field is in microseconds with values from 0 up to 32767, Little Endian (less significant byte first). We use a large value of 32000, or 7D00 hex.

Alternative Receiver Addresses are also an option (a real address in the network attacked, or an unexisting address). We do not have to worry about the Frame Check Sequence (FCS) which is usually calculated by hardware before transmission.

CTS Attack Implementation

There are variations of this attack possible, using different Frame Control flag bits set, or with different MAC addresses. To send the frame

C400007D010203040506

which contains a fake MAC address, framespam may be used like this:

# echo -en "\0304\0\0\0175\01\02\03\04\05\06" \
  | ./framespam -i rausb0
  
Frame Spammer, version 0 -- send an IEEE802.11 raw frame multiple times
Copyright (c) 2007, Matej Sustr

Info:   Sending many frames (delay 10000 us)
......

Experimental Results

With a 10ms delay between the CTS frames the attacked network becomes totally unresponsive (the affected stations/AP cannot transmit) except cases when some of the attacking CTS frames are lost.

More details in the thesis , section 6.3.3.

Mitigating RTS/CTS attacks

Effective countermeasures against RTS/CTS attacks include:

• ignoring CTS frames and the Duration field of frames altogether, thus not complying to the standard - at the expense of more collisions when dealing with hidden nodes,
• analyzing frames to determine if the Duration is a reasonable value (set a maximum for all frames, not just the CTS) - only use reasonable values for the NAV.

Such measures would have to be implemented by device manufacturers (or by modifying device drivers where possible). The IEEE might define a way of mitigating these attacks in the upcoming 802.11w (or possibly in a later amendment). Encryption or authentication of control frames is probably not an option though, since multiple independent networks should be able to operate in the same shared wireless media.

Wireless IDS may detect the attack and alert the administrator if the device drivers used to capture frames are able to process control frames and feed them to higher layers (see driver/rt2500-allframes.patch in the tarball of my thesis for an example of such for the rt2500 driver).