Knock, knock. Who’s there? NAT. Nat who? A NAT URL-borne killer

Video Ben Seri and Gregory Vishnepolsky, threat researchers at Armis, have found a way to expand upon the NAT Slipstream attack disclosed last year by Samy Kamkar, CSO of Openpath Security.

The original NAT Slipstream potentially allowed a miscreant to access any TCP/UDP service tied to a victim’s machine by bypassing the victim’s NAT (Network Address Translation) and firewall defenses. It can be triggered via JavaScript code on a malicious website.

NAT Slipstream v2 takes the technique further by allowing a hacker to penetrate a vulnerable NAT/firewall and reach any internal IP on the network, rather than just the IP address of the victim’s device.

Illustration of firewall breaking

We did NAT see that coming: How malicious JavaScript can open holes in your firewall for miscreants to slip through


In other words, it may expose every connected thing on a targeted network – printers, video cameras, industrial control systems, and other unmanaged hardware – to the internet. Such devices, which generally lack security controls, may then be compromised and commandeered or otherwise abused.

Version one of the attack involves using malicious JavaScript code that sends traffic to the victim’s machine using a protocol that traverses NAT and obtains the IP address of the victim’s computer. The script then builds an outbound HTTP POST request that tries to initiate a SIP video-conferencing session. The victim’s vulnerable NAT/firewall’s Application Level Gateway (ALG) then opens an external port to the victim’s device.

When Kamkar corresponded with The Register last year, he noted that browsers support protocols like WebRTC TURN (Traversal Using Relays around NAT) that evade port blocks and might be useful for further attacks.

You were warned

NAT Slipstream v2 validates that supposition. It relies on H.323, a VoIP protocol similar to SIP, and WebRTC TURN.

“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,” explain Seri and Vishnepolsky in a blog post.

The process is demonstrated in this video:

Youtube Video

But Seri and Vishnepolsky add that the risk presented by this attack depends upon how the traffic gets handled and the specific implementation of the targeted system because not all NATs provide ALGs nor enable them by default.

On Linux 4.14 and above, they observe, the exploited ALG behavior is disabled by default for security reasons. At the same time, they point out that consumer-grade routers rely on older Linux versions and some Linux-based products re-activate the vulnerable behavior. They said that OpenWRT, a Linux based router distribution using the 4.1 kernel, is not affected, but “most routers/NATs/firewalls are affected at least in some way.”

The researchers disclosed their findings to the major browser vendors back in November 2020, and patches, consisting of port restrictions, have been deployed since then.

Chrome’s fix arrived in v87.0.4280.141, on January 6, 2021. Microsoft Edge also deployed its fix, in v87.0.664.75, Apple released Safari v14.0.3 beta, with a stable channel release expected soon. And Mozilla’s fixed up Firefox 85 arrived on Tuesday, January 26.

Seri and Vishnepolsky expressed doubt that these defenses will be the end of this particular attack vector. NATs, they say, were designed at a time when security was not a priority.

“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,” they conclude. ®