The new variant attack could allow attackers to bypass NATs & Firewalls and reach any unmanaged device within the internal network from the Internet.
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:
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.
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.”
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.
We first became familiar with Samy’s interest in bypassing NATs, about a year ago, when Samy posted the following tweet:
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:
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
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.
The following video demonstrates the new variant:
The attack follows the following steps:
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).
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.
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:
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.
As described above, a responsible security disclosure of the new variant was initiated with leading browser vendors — Google’s Chrome, Mozilla’s Firefox & Apple’s Safari.
The browser vendors decided on a mitigation of this issue based on two changes:
This new attack variant, alongside the original attack from Samy Kamkar, isn’t the first time NAT ALGs are found to be a path to bypass NAT protections. In fact, more than a decade ago, Samy posted the groundbreaking NAT pinning research that showed how FTP and IRC ALGs were vulnerable to a simple attack that caused bypass of NAT through a simple browser page.
Although browsers have come a long way since 2010, adding restrictions to traffic they may generate via restricted-port lists, same-site origin policy, and other mitigation mechanisms — they have also been constantly evolving to allow more features and greater possibilities for web developers. Some of these advances, such as WebRTC, introduce new primitives that attackers may abuse to pry their way into internal networks, and the devices within them. DNS rebinding, for example, is another attack that abuses browsers to achieve a similar goal.
A long lasting solution, unfortunately, would require some rehaul of the Internet infrastructure we’re accustomed to. NATs were created at a time of need, back in the early 1990s, when the Internet was rapidly growing, and the shortage of the IPv4 address space required an intermediate fix — until IPv6 would be widely adopted (we’re getting closer every day, or so they say). However, NATs have also evolved to become the most effective and popular form of a firewall, implemented at the edge of almost every network (home or office) that connects to the Internet. While this evolution had mostly a positive impact on the security of networks, it is important to understand that security was not the principal agenda for the creation of NATs, rather it was mainly a by-product of the potential exhaustion of IPv4 addresses. Legacy requirements such as ALGs, are still a dominant theme in the design of NATs, today, and are the primary reason bypassing attacks are found again and again.
In the meantime, it seems the recurring feat of dissecting the interaction between modern browsers and legacy network appliances (such as NATs), will continue to be a challenge worth taking, and is something the research community cannot take their eyes off.
Vulnerabilities such as NAT Slipstreaming that allow an attacker to traverse a NAT and easily identify unmanaged devices on the internal network pose a tremendous threat to enterprises. The Armis agentless device security platform is able to not only identify browser versions that are vulnerable so that they may be patched, but can also identify active exploits to devices such as security cameras, printers, industrial control systems, and other unmanaged devices whose communication ports would be exposed to the Internet.
To see a demonstration of the Armis Agentless Device Security Platform, request a demo.