Slipstream - NAT Slipstreaming Allows An Attacker To Remotely Access Any TCP/UDP Services Bound To A Victim Machine, Bypassing The Victim's NAT/firewall, Just By The Victim Visiting A Website

NAT Slipstreaming allows an attacker to remotely access any TCP/UDP services bound to a victim machine, bypassing the victim's NAT/firewall (arbitrary firewall pinhole control), just by the victim visiting a website.

Developed by: @SamyKamkar // https://samy.pl

Released: October 31, 2020

Source code: https://github.com/samyk/slipstream

  animated version here generated with my fork of draw.io, allowing exportable edge context flow & control in animations

NAT Slipstreaming exploits the user's browser in conjunction with the Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls by chaining internal IP extraction via timing attack or WebRTC, automated remote MTU and IP fragmentation discovery, TCP packet size massaging, TURN authentication misuse, precise packet boundary control, and protocol confusion through browser abuse. As it's the NAT or firewall that opens the destination port, this bypasses any browser-based port restrictions.

This attack takes advantage of arbitrary control of the data portion of some TCP and UDP packets without including HTTP or other headers; the attack performs this new packet injection technique across all major modern (and older) browsers, and is a modernized version to my original NAT Pinning technique from 2010 (presented at DEFCON 18 + Black Hat 2010). Additionally, new techniques for local IP address discovery are included.

This attack requires the NAT/firewall to support ALG (Application Level Gateways), which are mandatory for protocols that can use multiple ports (control channel + data channel) such as SIP and H323 (VoIP protocols), FTP, IRC DCC, etc.

At a high level, NAT Slipstreaming works like so:

• victim visits malicious site (or site with malicious advertisement)
• internal IP of victim first must be extracted by browser and sent to server
  • internal IP attempted to be extracted via WebRTC data channel over https
    • some browsers (Chrome) only divulge the local IP via WebRTC over HTTPS but some of our attacks require HTTP so we first redirect to the HTTPS version of the attack software to extract the local IP
    • we then redirect to the HTTP version with the local IP included in the URL if we were able to obtain it to bypass other cross-origin protection mechanisms (the .local mDNS/Bonjour address presented will not be useful for the attack)
  • if internal IP not divulged by WebRTC (Safari) or no WebRTC (<= IE11), web-based TCP timing attack performed
    • hidden img tags to all common gateways (eg 192.168.0.1) are loaded in background
    • onerror/onsuccess events attached to img tags
    • if any TCP RST returned by gateway (or SYN + HTTP response), we've detected valid subnet
    • re-perform timing attack across all IPs on detected subnets (/24), measuring time to onerror/onsuccess firing
    • fastest response is likely internal IP, though all responses are considered victim internal IP candidates and attacked
• large TCP beacon sent via hidden form and automatic HTTP POST to attacker "HTTP server" bound to a non-standard port to force TCP segmentation and maximum MTU size discovery of the victim's IP stack
  • attacker TCP server sends Maximum Segment Size TCP Option to massage victim outbound packet sizes (RFC 793 x3.1), allowing control of how large browser TCP packets will be
• large UDP beacon sent from browser via WebRTC TURN authentication mechanism to non-standard port to attacker's server to force IP fragmentation with TURN username field stuffed
  • we perform a similar attack as our TCP segmentation, but over UDP as IP fragmentation will occur and provide different values than TCP segmentation
  • victim MTU size, IP header size, IP packet size, TCP header size, TCP segment sizes detected by server and sent back to victim's browser, used later for packet stuffing
• "SIP packet" in new hidden form generated, containing internal IP to trigger Application Level Gateway connection tracking
  • "HTTP POST" to server on TCP port 5060 (SIP port) initiated, avoiding restricted browser ports
  • POST data is "stuffed" to exact TCP segment size / packet boundary, then "SIP packet" appended and posted via web form
  • victim IP stack breaks the POST into multiple TCP packets, leaving the "SIP packet" (as part of POST data) in its own TCP packet without any accompanying HTTP headers
  • if browser alters size of multipart/form boundary (Firefox) or packet size changes for any other reason, size change is communicated back to client and client auto-resends with new size
  • when opening UDP port, SIP packet is sent over TURN protocol inside specially crafted username field forcing IP fragmentation and precise boundary control
• victim NAT sees proper SIP REGISTER packet on SIP port (with no HTTP data), triggering ALG to open any TCP/UDP port defined in packet back to victim
  • victim NAT rewrites SIP packet, replacing internal IP with public IP, hinting to attacker exploit was successful
  • even if victim NAT normally rewrites source ports, the ALG will still be forced to port forward to the attacker's port of choice as it believes victim machine opened that port and attacker sees new source port in arriving SIP packet
  • attacker can now bypass victim NAT and connect directly back to any port on victim's machine, exposing previously protected/hidden services
• to investigate...perhaps by you?
  • non-malicious usage: this technique essentially gives browsers full TCP and UDP socket capability to communicate to any protocol locally on the system; the connection can be abstracted through a cloud server that connects back but the browser just talks to the cloud server as if it's the socket and makes browsers much more powerful to communicate on non-web-friendly protocols
  • if testing in a virtual machine (VM) using shared networking (used to protect a host from attacks by routing it through the host, not letting it directly onto the network), if the packets make it out, the parent host machine is where the ports end up getting opened, not the VM ;)
  • IP fragmentation allows full control of all data in the IP data section, meaning full control of the UDP header, including source/dest ports in the overflowed packet...what else could this abuse?

Thanks for reading! You can download the proof of concept code from my NAT Slipstream github.

Point of Contact:@SamyKamkar

Find more of my projects at https://samy.pl or potentially reach me at code@samy.pl.