📜 ⬆️ ⬇️

Remote injection of Wi-Fi frames

image

The standard WiFi 802.11n uses a frame aggregation mechanism to reduce the overhead of data transfer.
To do this, several frames are combined into one. In this case, the frame separator marker is transmitted along with the data.
This allows you to generate data that, when passing through a WiFi device, will be interpreted by it as separate frames.

That is, having control over the flow of data transmitted from the server to the client (for example, when downloading a file from the attacker's server) or from client to server, you can generate arbitrary packets at all OSI levels:
')


Only open 802.11n networks are vulnerable.


Scheme PHY frame with injection
image

As you can see, the frame delimiter (A-MPDY delimiter) is placed directly into the payload with user data, so when the receiving party receives such a frame, it will be de-aggregated and our sequence will be perceived by the operating system as a separate packet.

More details about the vulnerability can be found in the report Injection Attacks on 802.11n MAC Frame Aggregation

Code to exploit the github.com/rpp0/aggr-inject vulnerability

The payload-generating script is aggr-inject.py.
For the injection of frames from the access point to the client, it is proposed to generate a jpg file that will download the victim (as in the picture in the post header). In the opposite direction, from the client to the point, it is proposed to send a special generated POST request to the attacker's web server.
The type of data being transferred does not matter, it is enough to be able to create an attack-driven data stream. In this case, HTTP is taken as the simplest example. At the same time, it is important that the data be transmitted unchanged to the wifi chip itself, therefore the data must be transmitted over an open channel (HTTPS is not suitable), not subjected to processing, compression.

The simplest example of demonstrating a vulnerability is the sending of broadcast beacon frames. The beacons that the access point sends, indicating its network name (SSID).

File that injects beacons with the network name “injected SSID” aggr_beacon.jpg 250MB

Most likely, you will not see the new network in the list of available Wi-Fi networks, since most operating systems use active scanning, and show only the networks that answered them at the probe request. Therefore, passive scanning is necessary to see the packet injection.

By the way, for those who use Mac OS, you can dump WiFi traffic with your own airport. I recommend my airport-sniffer tool for this. The dump will be found in /tmp/airportXXXX.cap

My test bench is identical to the image in the post title. The malicious file is downloaded by the tablet, the dumper is launched on a laptop connected to the same TL-MR3020 access point with openwrt 12.09 firmware. Also, the injection is successfully reproduced using the tl-wn821n USB adapter.

Here are the packages caught by the laptop:

tcpdump -e -r /tmp/airport.pcap type mgt subtype beacon
13:33:11.317916 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317916 4269971522us tsft bad-fcs -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [1.0* 35.0 23.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317917 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317918 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317919 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317921 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317922 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:11.317923 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 13:33:12.876472 4271529509us tsft bad-fcs -85dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:18:00:00:00:00:00 (oui Unknown) DA:Broadcast SA:1c:e9:87:8a:54:36 (oui Unknown) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1 


By timing, it can be seen that the injections occur very cheerfully.

In order to conduct a real attack, you need to climb the L2 and L3 levels, that is, you need to know the MAC address of the access point, in some cases the MAC address of the client, the IP address of clients for NAT. Therefore, to exploit the vulnerability in real conditions is extremely difficult. The maximum is to send a deauth packet and disconnect all clients from the network.

I managed to successfully inject TCP packets and I tried to crawl onto the TCP port of the client behind the NAT, trying to create a broadcast in nf_conntrack that passed my packets to the client. But I did not succeed. If you send a SYN client on behalf of a remote host, its SYN-ACK response does not create a broadcast and cannot be answered from the world. If you send a SYN client to the world and respond to it, even if you create a broadcast on a router in the ESTABLISHED state, the new SYN from the world sent to the client will be discarded. Even fantasies on this topic have broken about the problem of guessing the seqence number. Although, maybe I’m just loshara and you will succeed.

This can be successfully rotated with UDP. Also in the examples there is a way to scan hosts for NAT by sending icmp.

Source: https://habr.com/ru/post/261787/


All Articles