Amazing-Mirror/fragattacks
1
0
Fork 0
mirror of https://github.com/vanhoefm/fragattacks.git synced 2024-11-28 18:28:23 -05:00
Code Issues Projects Releases Wiki Activity
c23fd0ae92
fragattacks/research/NOTES.md

4.6 KiB
Raw Blame History

Monitor mode injectin

Device that purely operate in monitor mode might overwrite certain fields of injected frames. Here we document the default behaviour of some devices.

When using a single physical interface to create a virtual managed and monitor interface, there are additional unexpected consequences to injection of frames. These depend on the specific driver/device being used, and we discuss some of these issues here as well.

Intel 8265 / 8275 (rev 78) devices

Summary: this can be used without driver/firmware changes in pure monitor mode, but care is still needed that frames with different priority are not reordered (TODO: Explain parameter to force this).

  • When connecting normally on Arch Linux, while connecting it sends frames with all three address equal to it's own address. This frame contains the numbers 1 to 0x27 as 32-bit numbers for some reason. This is a strange bug, but at least it is not caused by our driver modifications.

  • Had to patch driver to prevent sequence number and QoS TID to be overwritten TODO: Also in pure monitor?

  • Unable to transmit any frames from a different transmitter address. This is because in ieee80211_monitor_start_xmit it cannot find a channel to transmit on (finding a valid chandef fails). TODO: Also in pure monitor?

  • Cannot inject frames using a TID that is used for the first time. There's no queue in the driver allocated for it yet it seems, and this causes issues. To prevent this, and prevent frame reordering, we inject all frames on the same queue in the driver. TODO: Also in pure monitor?

  • It ignores IEEE80211_RADIOTAP_DATA_RETRIES and retransmites frames 15 times both in purely monitor more and mixed managed/monitor mode (before and after authenticating).

  • Unlike, ath9k_htc, in mixed managed/monitor, we can inject frames before the association request is sent. Strangely, the Intel device also sends some strange frames while connecting (even on Windows 10). But that only seems to slow down the injection of frames.

Ath9k_htc devices

Summary: when using this device, you must use a modified driver/firmware. Since this is a USB device, this can be done inside a virtual machine.

  • The ath9k_htc devices by default overwrite the injected sequence number, even when purely operating in monitor mode.

    Interestingly, the device will not increment the sequence number when the MoreFragments flag is set, meaning we can inject fragmented frames (albeit with a different sequence number than then one we use in the user-space script).

  • The above trick does not work when we want to inject other frames between two fragmented frames (the chip will assign them difference sequence numbers). Even when the fragments use different QoS TIDs, sending frames between them will make the chip assign difference sequence numbers to both fragments. TODO: This only is the case in mixed manager/monitor mode I think?

  • Overwriting the sequence can be avoided by patching ath_tgt_tx_seqno_normal and commenting out the two lines that modify i_seq. Note that these changes are in the firmware of the device.

  • See also the comment in Station.perform_actions to avoid other bugs with ath9k_htc when injecting frames with the MF flag and while being in AP mode.

  • The at9k_htc dongle, like other Wi-Fi devices, will reorder frames with different QoS priorities. This means injected frames with differen priorities may get reordered by the driver/chip. We avoided this by modifying the ath9k_htc driver to send all frames using the transmission queue of priority zero, independent of the actual QoS priority value used in the frame. This happens even when purely operating in monitor mode.

  • It doesn't retransmit frames in pure monitor mode. In mixed managed/monitor after (or right before authentication) it retransmits frames at most ones. But it injects a lot of RTS as times?!

  • In mixed/managed mode, we can inject frames when the managed interface is up but not being controlled by wpa_supplicant (but unknown which channel will be used). When connecting using wpa_supplicant, it seems we can only inject frames after the association request has been sent.

  • In mixed AP/monitor mode, when injecting the first fragment of a frame, it will be injected properly, but afterards the chip won't second beacons for one second. This can be prevented by injected a dummy packet after the injected fragment.

TODOs

  • When using the mac80211_hwsim trick with one monitor interface, there is still the risk of frames with different QoS TIDs being reordered.