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 makes it possible for an attacker to remotely access any TCP/UDP expert services sure to a target machine, bypassing the victim’s NAT/firewall (arbitrary firewall pinhole regulate), just by the sufferer checking out a web page.

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

Unveiled: October 31, 2020

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

  animated variation here generated with my fork of draw.io, making it possible for exportable edge context circulation & manage in animations

Summary

NAT Slipstreaming exploits the user’s browser in conjunction with the Application Amount Gateway (ALG) link tracking mechanism built into NATs, routers, and firewalls by chaining internal IP extraction by way of timing assault or WebRTC, automatic distant MTU and IP fragmentation discovery, TCP packet measurement massaging, Flip authentication misuse, specific packet boundary regulate, and protocol confusion through browser abuse. As it truly is the NAT or firewall that opens the destination port, this bypasses any browser-primarily based port limits.

This attack takes advantage of arbitrary handle of the data part of some TCP and UDP packets without the need of which includes HTTP or other headers the assault performs this new packet injection procedure throughout all main contemporary (and older) browsers, and is a modernized version to my primary NAT Pinning procedure from 2010 (offered at DEFCON 18 + Black Hat 2010). On top of that, new procedures for nearby IP deal with discovery are included.

This attack involves the NAT/firewall to guidance ALG (Application Stage Gateways), which are obligatory for protocols that can use multiple ports (management channel + data channel) such as SIP and H323 (VoIP protocols), FTP, IRC DCC, etc.

At a substantial amount, NAT Slipstreaming operates like so:

• sufferer visits malicious internet site (or web site with destructive ad)
• internal IP of victim first must be extracted by browser and sent to server
  • inside IP tried to be extracted via WebRTC knowledge channel in excess of https
    • some browsers (Chrome) only divulge the neighborhood IP through WebRTC around HTTPS but some of our attacks involve HTTP so we initially redirect to the HTTPS model of the assault software to extract the regional IP
    • we then redirect to the HTTP edition with the regional IP included in the URL if we had been able to get hold of it to bypass other cross-origin protection mechanisms (the .regional mDNS/Bonjour address offered will not be valuable for the assault)
  • if interior 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?

Download

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

Contact

Point of Contact: @SamyKamkar

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

Image and Article Source link

Read More on Pentesting Tools