Remote injection Wi-Fi frames

    image

    The WiFi 802.11n standard uses a frame aggregation mechanism to reduce data transfer overhead.
    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 the client to the server, you can generate arbitrary packets at all OSI levels:

    • Package with any RadioTap headers: Beacon, Probe Request / Respone, Deauthentication
    • L2 level: specify any MAC address in the packet headers, ARP spoofing can be performed
    • L3 / L4 level: craft any TCP / UDP / ICMP packet with any IP headers
    • etc


    Only open 802.11n networks are affected .


    Scheme of a PHY frame with injection
    image

    As you can see, the frame divider (A-MPDY delimiter) is placed directly in payload with user data, so when the receiving side receives such a frame, it will be deaggregated and our sequence will be perceived by the operating system as a separate package.

    Read more about the vulnerability in the report Injection Attacks on 802.11n MAC Frame Aggregation

    Code for exploiting the vulnerability github.com/rpp0/aggr-inject

    The script generating payload is aggr-inject.py.
    To inject frames from the access point to the client, it is proposed to generate a jpg file that the victim will download (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 transferred does not matter; it’s enough to be able to create an attacker-driven data stream. In this case, HTTP is taken as the simplest example. It is important that the data be transferred unchanged to the wifi chip itself, so the data must be transmitted over an open channel (HTTPS is not suitable), not be processed, compressed.

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

    A 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 networks available for connecting WiFi, since most operating systems use active scanning and only show networks that answered them on probe request . Therefore, to see the injection of packets you need to use passive scanning.

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

    My test bench is identical to the picture in the post title. The malicious file is downloaded by the tablet, the dumper is running 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's what the packets caught by the laptop look like:

    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
    


    The timings show that the injections are very cheerful.

    In order to conduct a real attack, it is necessary to rise to 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 addresses of clients behind NAT. Therefore, exploiting 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 the client located behind NAT onto the TCP port, trying to create a translation in nf_conntrack that would allow my packets to pass to the client. But I didn’t succeed. If you send SYN to a client on behalf of a remote host, its SYN-ACK response does not create a broadcast and you cannot reply to it from the world. If you send SYN from the client to the world and reply to him, even if you create a broadcast on the router in the ESTABLISHED state, the new SYN sent from the world will be discarded. Even fantasies on this topic have broken about the problem of guessing the seqence number. Although, maybe I'm just a loshara and you will succeed.

    You can successfully do this with UDP. Also in the examples there is a way to scan hosts for NAT by sending icmp.

    Also popular now: