Deauth attack channel bleed

[ccb056]

AP operates on Channel 6

Attack mode d (Deauthentication and Disassociation) runs on channel 5 or 7 (mdk4 wlan0mon d -c 5) or (mdk4 wlan0mon d -c 7)

Clients associated with AP operating on CH 6 are disconnected (undesirable result)

Looking through kismet, ~40% of packets between clients and AP are on CH 6, 30% on CH 5, and 30% on CH 7

[aircrack-ng]

In 2.4GHz, channels overlap, and it's not unusual to see some of the frames in other channels.

Are you sure there wasn't any network manager running on the system injecting?

How was the capture on the other side? Did you have independent wireless cards on each 3 channels? Or just one hopping?

[564f4944]

Hi,

I have experienced the same annoying behaviour as @ccb056, which is not limited to the mode d but also occurs with mode b for example.

After some investigation I noticed that the packets are emitted with the smallest MCS/datarate - which totally makes sense to achieve maximum range. However, if the transceiver is compatible with the old 802.11b (which is nowadays almost always the case) this means that the packets are sent with datarate of 1 Mbit/s using a DSSS wave form.

But DSSS signals have very loose requirements for reception and do not require exact frequency sychronization. If the signal is clear enough (strong), it still can be decoded if the receiver is configured on an adjacent channel which is off by one (= 5 MHz) or even more (two or three channels) for very strong signals. Conversely, the more of the signal the receiver collects in the frequency domain, the better is the SNR after un-spreading the signal.

More recent versions of the standard, starting with 802.11g, use OFDM waveforms, which require proper frequency synchronization within a very tight range. They cannot be decoded if sender and receiver are configured on adjacent channels (even though still ~15 MHz of the 20 MHz signal overlap). The receiver will only detect an occupied channel but it won't decode the signal.

I couldn't figure out the right flags for the radiotap header to convince my transceiver to send OFDM signals - my radio always transmitted with 802.11b/DSSS. In case someone wants to take a look on that: those headers are constructed in mdk4's osdep/linux.c:811.

As a workaround, the 802.11b data rates can be disabled entirely with the iw command which then forces 802.11g/OFDM. Unfortunately, at least on my system with an ALFA AWUS036NHA, the configuration only works in managed mode and fails with an error in monitor mode. Luckily, the configuration is persistent throughout mode switches, so switching to managed mode for setup and back to monitor should work fine:

# set interface into managed mode
ifconfig wlan0 down
iw dev wlan0 set type managed
ifconfig wlan0 up

# set allowed MCS/bitrates (omit 1, 2, 5.5 and 11 --> 802.11b)
iw wlan0 set bitrates legacy-2.4 6 9 12 18 24 36 48 54

# back to monitor mode
ifconfig wlan0 down
iw dev wlan0 set type monitor
ifconfig wlan0 up

# run mdk4 now...

I have attached a snapshot of the emitted beacon signals by mdk4 in mode b in the frequency domain, which are transmitted with an ALFA AWUS036NHA in a default configuration and captured with an SDR next to it. It clearly shows the bell-shaped wave form of the DSSS signal.

After disabling the data rates of 802.11b as described above, OFDM is used (i.e. 6 Mbit/s of 802.11g) which effectively prevents a reception on adjacent channels. The second snapshot shows the spectrum of the OFDM signal (plateau-shaped wave form) using the same setup and mdk4 command as before.

Outlook

Although there is a workaround, it would be great to have an option in mdk4 to force 802.11g/OFDM or disable 802.11b to prevent channel bleed. Furthermore, IDS may also trigger on 802.11b, especially if their own network only takes 802.11g or 802.11n. It would be more stealthy, if the same wave form was used. Maybe someone who is more familiar with radiotap could take a look on that, as it should be possible with the right flags. The validation of the signal does not require an SDR and can also be done by checking the flags of a received packed, e.g. via wireshark.