Network Securtiy

The NAT Slipstreaming attack relies on tricking the victim into accessing a specially crafted website and exploits the browser on the device, along with the Application Level Gateway (ALG), a connection tracking mechanism in Network Address Translation (NAT), firewalls, and routers.

The attack was meant to bypass existing browser-based port restrictions and allow the attacker to remotely access TCP/UDP services on the victim’s device, even if it was protected by a firewall or NAT.

Researches comes with a variant of the attack, dubbed NAT Slipstreaming 2.0, that can bypass mitigations for NAT Slipstreaming, and which also expands the attacker’s reach, allowing them to create paths to any device on the internal network.

This puts embedded, unmanaged, devices at greater risk, by allowing attackers to expose devices located on internal networks, directly to the Internet.

Devices may include printers exposed through the default printing protocol, industrial controllers using unauthenticated protocols, and IP cameras that have an internal web server secured with default credentials. These devices when abused will trigger Ransomware attacks

The new attack is based on new primitives and allows for connections to any destination ports, fully bypassing the mitigations that browser makers have introduced for NAT Slipstreaming.

The attacker needs to craft a website containing malicious code and then trick the victim into accessing that website. The code sends multiple fetch requests from the victim browser on H.323 port (1720), thus allowing the attacker to “iterate through a range of IP addresses and ports, each time opening an IP/port to the Internet,” for reconnaissance.

Fixes for the issue were included in all major web browsers, namely Chrome v87.0.4280.142, Firefox v85.0, and Safari v14.0.3. Microsoft’s Edge, which relies on the Chromium source code, is also patched. The bug is tracked as CVE-2020-16043 in Chromium and CVE-2021-23961 in Firefox.

The mitigations all browser makers added to their software involved making two changes, namely adding the TCP/UDP ports of all known ALGs to the list of restricted ports, and enforcing the list on WebRTC connections as well.