NAT Slipstreaming v2.0

General Overview

The new variant attack could allow attackers to bypass NATs & Firewalls and reach any unmanaged device within the internal network from the Internet.

• The new variant to the NAT Slipstreaming attack was discovered by Armis’ researchers, resulting in a combined effort with the original discoverer of the attack, Samy Kamkar (Chief Security Officer & co-founder at Openpath Security Inc.).
• The new attack variant can allow attackers to reach any device within the internal network and simply requires a victim to click on a malicious link.
• Impact of attack on unmanaged devices can be severe, ranging from a nuisance to full-blown ransomware attack.
• Enterprise-grade NATs/firewalls from Fortinet, Cisco and HPE are confirmed to be affected, while others are likely affected as well
• The collaboration resulted in a security disclosure with browser vendors to mitigate the attack
• Google, Apple, Mozilla and Microsoft have released patches to Chrome, Safari, Firefox and Edge, that mitigate the new variant
• The Armis platform can help identify endpoint devices that are at risk (running unpatched browser versions) and detect exploit attempts of NAT Slipstreaming attacks

Read the original NAT Slipstreaming blog by Samy

Go to the New Technical Details

Armis researchers Ben Seri and Gregory Vishnipolsky have discovered a new variant to the NAT bypassing technique known as NAT Slipstreaming, and have worked with security researcher Samy Kamkar (who originally disclosed the technique on October 31, 2020) to better understand the attack, and mitigate it. The new discovery includes a method to bypass NATs and firewalls to reach any device on the internal network. While the original attack was partially mitigated by a browser patch, the new variant introduced additional primitives that bypass these mitigations. The new discovery, thus, resulted in a security disclosure with leading browser vendors – Google’s Chrome, Mozilla’s Firefox and Apple’s Safari. While the underlying issue of this attack is the way NATs are implemented (in various ways in routers and firewalls, throughout numerous vendors and applications), the easiest and fastest way to mitigate was through a patch to browsers. During the last month, all of the browsers noted above have released versions which contain a mitigation against this attack (Chrome v87.0.4280.141, Firefox v85.0, Safari v14.0.3). Microsoft’s Edge browser is also now patched, as it relies on the Chromium source code. Chromium is tracking the new variant via CVE-2020-16043, while Firefox is tracking it via CVE-2021-23961 and Safari is tracking it via CVE-2021-1799.

The original NAT Slipstreaming attack relies on a victim within an internal network that clicks on a link that leads to an attacker’s website, which in turn will cause the attacker to fool the victim network’s NAT into opening an incoming path (of either a TCP or UDP port) from the Internet, to the victim device. The new variant extends this attack, to allow the attacker to fool the NAT in such a way that it will create incoming paths to any device on the internal network, and not only to the victim device that clicked on the link. 

This puts embedded, unmanaged, devices at greater risk, by allowing attackers to expose devices located on internal networks, directly to the Internet. While such a feat can elevate the risk of an attack to any device within a network, that risk is especially great when it comes to unmanaged devices, as those don’t have inherent security capabilities, and often offer interfaces for controlling them and accessing their data with little-to-no authentication, within the internal network. Exposing these interfaces directly to the Internet is a serious security risk. Examples include: 

• An office printer that can be controlled through its default printing protocol, or through its internal web server.
• An industrial controller that uses an unauthenticated protocol for monitoring and controlling its function.
• An IP camera that has an internal web server displaying its feed, which can commonly be accessed with default credentials. 

Using the new variant of the NAT Slipstreaming attack to access these types of interfaces from the Internet, can result in attacks that range from a nuisance to a sophisticated ransomware threat.

In addition to interfaces that are unauthenticated by design, many unmanaged devices may also be vulnerable to 1-day vulnerabilities (vulnerabilities that are publicly known), that can be exploited if an attacker is able to bypass the NAT/firewall, and initiate network traffic that can trigger them. In a recent study, for example, Armis researchers found that 97% of industrial controllers vulnerable to URGENT/11 were left unpatched, more than a year after the critical vulnerabilities were first published. A similar statistic was highlighted for Cisco devices vulnerable to CDPwn, of which 80% were found to be unpatched, nearly a year since these critical vulnerabilities were published. Since regular patching of unmanaged devices is such a challenge, many organizations rely on perimeter security of their networks (firewalls/NATs) to keep their unpatched devices from being accessed by potential attackers on the Internet. Once the perimeter is breached, these unpatched, unmanaged devices can be easy targets for attackers to take over, preserve a presence in the network, and act as RATs (remote access tools) through which any further attack can take place.

Background on NAT Slipstreaming

As noted above, this attack was first discovered by Samy Kamkar, and a detailed version can be found on his blog (which has been updated to include details on the new variant as well). Samy summarizes the attack in a single sentence: “NAT Slipstreaming allows an attacker to remotely access any TCP/UDP service bound to a victim machine, bypassing the victim’s NAT/firewall (arbitrary firewall pinhole control), just by the victim visiting a website.”

In more detail, the attack can be described as follows: It starts with a victim device (a computer, or a mobile phone, running a web browser), visiting an attacker-controlled website, which results in javascript code running in the victim’s browser that sends out additional traffic to the attacker’s server, that traverses through the network’s NAT/firewall. This second-phase traffic is crafted in such a way, that the NAT is fooled to believe this traffic actually originated from an application that requires a second connection to take place, from the Internet to the victim device, and to an internal port that the attacker can choose. This second connection can thus lead the attacker to access any service (TCP/UDP) on the victim’s device, directly from the Internet. If, for example, the victim’s device is a Windows device vulnerable to EternalBlue (the underlying remote-code-execution vulnerability that was used by WannaCry), the attacker can access the SMB port on the victim device using this technique, from the Internet, exploit the vulnerability, and take over the device — and the only thing required for this attack to take place, is that the victim clicks on link, or visits a web page of which the attacker has implanted some javascript code.

The second-phase traffic that is being picked up by the NAT actually mimics certain protocols (such as FTP, SIP, and others), that NATs are designed to parse in order to allow certain incoming connections back through the NAT, without any manual configuration. These types of protocols require two connections to co-exist. The first originates from within the internal network, and goes out to the Internet (and is thus allowed by the NAT, by default), and a second connection originates in the opposite direction, from the Internet to the internal network. Since the second connection would normally be blocked by the NAT, the NAT parses the traffic in the first connection, and attempts to identify when a second connection might be needed. When such a detection occurs, the NAT adds rules, on-the-fly, to allow the second connection through. This mechanism is called ALG (application level gateway), and is the primary component within the NAT that facilitates the NAT Slipstreaming attack.

Samy demonstrated this attack by leveraging the SIP ALG implementations of various NATs, which looks for SIP traffic on TCP port 5060. This port was not blocked by the restricted-ports list of any browser (at the time), allowing the NAT’s ALG logic to be reached from a crafted HTTP POST request. Since many NAT ALG implementations in NATs/firewalls merely parse each TCP segment individually, they can be fooled into parsing crafted HTTP requests as, for example, valid SIP traffic. This is achieved by carefully setting the MSS value of an attacker controlled TCP connection from the victim browser to an attacker’s server, so that a TCP segment in the “middle” of the HTTP request will be entirely controlled by the attacker.

A New Variant Is Discovered

We first became familiar with Samy’s interest in bypassing NATs, about a year ago, when Samy posted the following tweet:

I've developed a new technique for bypassing firewalls/NATs and producing full TCP/UDP session to targeted user. Anyone have RCE for a service that's typically only run behind NATs (eg desktop software like Sonos, Spotify, Dropbox, etc which bind to *) and want to merge projects?

— samy kamkar (@samykamkar) January 5, 2020

Being long-time fans of Samy’s work, we were intrigued by his latest findings and began brainstorming ideas about new ways to bypass NATs, theorized some ideas, and scribbled some notes. A detour of this initial quest led us to the discovery of the EtherOops attack. While it was clear this attack was most certainly not what Samy had in mind, we soldiered on, and published that research last August.

Last October, Samy published his work, and we instantly went back to our notes, and compared them with Samy’s findings. Building upon Samy’s ideas, and combining them with some of our own, led us to the discovery of the new variant.

This new variant is comprised of the following newly disclosed primitives:

1. Unlike most other ALGs, the H.323 ALG, where supported, enables an attacker to create a pinhole in the NAT/firewall to any internal IP, rather than just the IP of the victim that clicks on the malicious link.
2. WebRTC TURN connections can be established by browsers over TCP to any destination port. The browsers restricted-ports list was not consulted by this logic, and was therefore bypassed.
   1. This allows the attacker to reach additional ALGs, such as the FTP and IRC ALGs (ports 21, 6667) that were previously unreachable due to the restricted-ports list. The FTP ALG is widely used in NATs/firewalls.
   2. This also defeated the browser mitigations introduced shortly after Samy first published the NAT Slipstreaming attack, which added the SIP port (5060) to the restricted-ports list, but didn’t block the port from being reachable via a TURN connection.

Creating NAT pinholes to any internal IP using the H.323 ALG

H.323 is a VoIP protocol similar to SIP, which is also quite complex. For a network of VoIP phones to function properly, while having a NAT somewhere inside the topology, an H.323 ALG is required. The H.323 ALG needs to translate IP addresses that are contained within the application layer H.323 protocol packets, and open holes in the NAT in certain scenarios.

Most ALGs only need to worry about at most two addresses to translate within a session — the IP addresses (and ports) of both sides of the TCP connection. However, H.323 is a telephony protocol, and supports call forwarding. Therefore, in this case, one party within the session can refer to a 3rd party IP address, belonging to the VoIP phone that the call should be forwarded to.

Most H.323 ALGs support this feature. For the Linux conntrack module, a graphical explanation of this behavior can be seen below:

Call forwarding scenario explained by the author of the H.323 conntrack module
https://people.netfilter.org/zhaojingmin/h323_conntrack_nat_helper/

The relevant source code in the conntrack module can be found here.

Analyzing the code linked above, reveals that a single H.323 packet sent over TCP port 1720 that initiates call forwarding can open a pinhole (named an expectation in the conntrack subsystem) to any TCP port of any internal IP on the network.

Demo of the New Variant in an Office Network

The following video demonstrates the new variant:

The attack follows the following steps:

1. A victim device within an internal network (a Smartphone in the above scenario, connected to the network via WiFI), clicks on a malicious link, hosted on the attacker’s server, in the Internet.
2. The link opens a web page on the Smartphone’s browser, that runs Javascript code in the background, sending multiple fetch requests back to the attacker’s server on the H.323 port (1720). This port was not blocked by browsers before the recent patch.
3. Each fetch request on the H.323 port is built of HTTP headers (controlled mainly by the browser), and a payload, of which the attacker has full control, and can be set to include some padding bytes, a delimiter (a unique sequence of bytes), and a sequence of bytes that may later be parsed by the NAT as an H.323 call forwarding message.  The request is deliberately large (it’s size can be controlled by the amount of padding bytes), causing the TCP/IP stack of the victim device to split it over multiple TCP segments.
4. The attacker’s server receives each of the fetch requests, and detects the delimiter within them. Using the offset of the delimiter, the attacker can either alter the MSS (minimum segment size) of the connection, or send a partial ACK on the TCP stream. Both approaches can be effective in causing the victim’s operating system to align the H.323 call forwarding message, within the request, to the beginning of a TCP segment.
5. Once the above re-alignment of segments occurs, the NAT will now parse the TCP segment containing the H.323 call forwarding message, and add the necessary NAT rules to facilitate the potential “call forwarding”. As stated above, the attacker is able to control the internal IP and port to which the “call” is forwarded too. This means that for each fetch request sent from the Victim’s browser, the attacker is able to open a hole in the NAT to a certain IP/port in the internal network.
6. Combining the above steps, the attacker can iterate through a range of IP addresses and ports, each time opening an IP/port to the Internet. As demonstrated in the video above, this stage can be a very effective tool for the attacker to do reconnaissance steps before deciding which device on the network he’d like to target. In the above demo the attacker exposes the HTTP port (80) of all the IP addresses in the internal network, and then grabs the HTTP banner of any device that responds. This allows him to identify the embedded devices that host a web server, and tailor his second-stage attack accordingly.
7. In the demo above, the second-stage of the attack contains the attacker opening the default printer’s port (9100) of the Xerox printer, and sending a print job to it, and also accessing the Axis IP camera’s video feed using it’s default credentials, through its web server.

Demo of the New Variant In a Manufacturing Facility

We developed an additional demonstration to show the risks this attack has on industrial controllers that have an unauthenticated management port accessible through the network. Opening that port (in the demo below, the target is a Rockwell Automation PLC, that is managed through the ENIP/CIP port – 44818), over a range of internal IP addresses, to the Internet, results in an attacker being able to detect details on the PLCs within the network, change program code, or alter configuration, without any needed authentication.

In the demo above, a manufacturing facility is simulated, with multiple PLCs (programmable logic controllers) connected to the internal network. Via a similar attack as shown in the first demo, the attacker is able to identify, and then also control any PLC within the network, from the Internet — without authentication!

While both demos require the attacker to guess the IP range of the internal network, it is quite easy to achieve this with various known techniques (for example, see Samy’s recent project WebScan).

WebRTC TURN restricted-ports list bypass

TURN is a protocol used by WebRTC in order to allow two peers behind two separate NATs to communicate via a mediating TURN server. WebRTC communication usually takes place over UDP, however, it’s possible to configure it to work over a TCP transport instead.

As noted above, we discovered that by establishing a TURN connection, it was possible to bypass browsers’ restricted-port list, and create traffic to any port, of either TCP or UDP. This can be established when the following TURN server, for example, is used in a WebRTC connection: “turn:attacker.com:21?transport=tcp”. Using this configuration, WebRTC will create a TURN connection over TCP port 21.

As can be seen above, the attacker has control over the username field that will be sent over the TCP connection as part of the authentication with the TURN server. An attacker controlled TURN server can then adjust the connection’s MSS (or manually manage the TCP sequence numbers as shown below), such that the victim browser will send the attacker controlled username field in the beginning of a separate TCP segment.

In the Wireshark trace above, the first three packets are exchanged between a victim’s browser and an attacker’s server normally. In the 3rd packet the username field contains the string “\r\nPORT 192,168,1,29,4,0\r\n”. Newlines and even NULL bytes are acceptable, as long as the string is valid UTF-8 (under Chromium). The 4th packet is a partial ACK from the attacker’s server, causing the 5th packet to be a partial retransmission from the victim machine, that starts right where the attacker wants it to — at the start of an FTP PORT command. The TCP window field (not shown) may also be crafted in the attacker’s ACK packets in order to fully control how the TCP stream is to be segmented.

This primitive allows the attacker to reach ALGs on ports that are usually restricted, such as FTP and IRC. Both of these ALGs are usable for creating pinholes back to the victim’s internal IP.

Affected and tested NAT/firewall products

As described above, the new variant to the NAT Slipstreaming attack is comprised of two primitives, the first explores the H.323 ALG, and the second expands the attack surface of the various NAT ALGs reachable from a browser, by abusing the WebRTC TURN server API via Javascript. However, the actual risk imposed by this attack depends on the interaction between the second-stage traffic generated via different browser primites, and the specific implementation of targeted NAT. Not all NATs support all ALGs, or enable them by default, and actual implementations of NAT ALGs differ greatly, and can limit potential attack in different ways.

We performed several tests, to establish the effects of abusing the above techniques against the implementation of various ALGs from various router/firewall vendors. Many of the commercial or open source router/firewall offerings allow an evaluation of their product in the shape of a VM, that runs the exact same software as the real product. We conducted most of our testing on such VMs.

It should be noted that on Linux, from kernel version 4.14 upwards, “default automatic helper assignment has been turned off for security reasons” (helper meaning ALG in this context). This disables the exact behaviour that we are exploiting. This is very good, however, many consumer grade routers run older kernels, and some of the more updated Linux based products re-enable this disabled feature using the “/proc/sys/net/netfilter/nf_conntrack_helper” flag, as it is still useful for many users.

Below is a list of products we’ve tested:

1. OpenWRT, a Linux based router distribution, with kernel 4.14+
   1. Current versions are not affected. The netfilter conntrack ALG modules are not shipped.
   2. Even if the package is installed, the “automatic assignment” is still disabled.
2. VyOS, a Linux based router/firewall distribution, with kernel 4.14+
   1. The nf_conntrack_helper flag is turned on explicitly.
   2. FTP ALG is present and allows connections back only to the victim’s internal IP, but to all ports.
   3. H.323 ALG is present and allows connections to all internal IPs on all ports.
3. Various consumer grade Linux routers, with likely older kernel versions
   1. FTP ALG is always present, and allows connections back only to the victim’s internal IP, but to all ports.
   2. H.323 ALG is enabled in the majority of the routers we’ve tested, and allows connections to all internal IPs on all ports.
4. Fortigate FG64 VM, Fortigate 60E firewall appliance, Fortigate CGNAT of two local ISPs
   1. FTP ALG allows connections back only to the victim’s internal IP, on ports greater than 1024.
   2. H.323 ALG is enabled and allows connections to all internal IPs on all ports.
5. Cisco ASAv VM
   1. FTP ALG allows connections back only to the victim’s internal IP, on ports greater than 1024.
   2. H.323 is enabled but not affected due to better parsing on their part, preventing the partial TCP segments trick from being useful (further research might bypass this limitation).
6. Cisco csr1000v VM (same software as IOS XE routers)
   1. H.323 ALG is enabled and allows connections to all internal IPs on all ports.
7. HPE vsr1000 VM
   1. FTP is enabled by default, and allows connections for all internal IPs on all ports.
   2. H.323 ALG is not enabled by default, but if enabled, works for internal IPs on all ports.
8. Sonicwall TZ300 appliance
   1. FTP ALG allows connections back only to the victim’s internal IP, on ports greater than 1024.

This list is by no means exhaustive, describing our fairly minimal testing of the issue. Mostly, it shows that most routers/NATs/firewalls are affected at least in some way. Moreover, in the majority of cases, the effect is pretty much a full bypass of the firewall/NATs protection.

More importantly, it illustrates that the ALG mechanism within NATs is widely used, and resolving the issue will require a fundamental change of their implementations by various router/firewall vendors. This will likely be a great challenge. However, mitigating the attack from the browser side is likely to be a more straight-forward feat.