Slipstreaming 2.0 NAT Bypass

I saw this over in the News Story Dump thread and thought people here might want to see it too and maybe have some ideas on how to avoid it:

It looks like it still needs somebody to visit a site that runs a malicious JavaScript, so I think using NoScript should help a lot? Plus having good firewall rules on each system on your network to limit what even a successful exploit can do?

3 Likes

Wow, it took me a while to find the original post there as it has been moved (archived) to a different thread…

Summary
NAT Slipstreaming exploits the user’s browser in conjunction with the Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls by chaining internal IP extraction via timing attack or WebRTC, automated remote MTU and IP fragmentation discovery, TCP packet size massaging, TURN authentication misuse, precise packet boundary control, and protocol confusion through browser abuse. As it’s the NAT or firewall that opens the destination port, this bypasses any browser-based port restrictions.
This attack takes advantage of arbitrary control of the data portion of some TCP and UDP packets without including HTTP or other headers; the attack performs this new packet injection technique across all major modern (and older) browsers, and is a modernized version to my original NAT Pinning technique from 2010 (presented at DEFCON 18 + Black Hat 2010). Additionally, new techniques for local IP address discovery are included.
This attack requires the NAT/firewall to support ALG (Application Level Gateways), which are mandatory for protocols that can use multiple ports (control channel + data channel) such as SIP and H323 (VoIP protocols), FTP, IRC DCC, etc.

Source: Samy’s Slipstream v1 writeup

NAT Slipstreaming v2 writeup: https://www.armis.com/natslipstreaming

Basically, yes: An adblocker/jsblocker a day keeps the malware away.

I didn’t read it in full (it seems a proper sophisticated one, it deserves full attention), but “just” firewall rules won’t help you without also disturbing other services you may use later on.

Despite whatever browser vendors say and do about “security”, overall JS is a bigger risk today than it was in early 00’s to install native programs. For both privacy & security.

2 Likes

Nat always was a bad idea IMHO, and anyone who thinks they’re protected from bad stuff with a default NAT setup is kidding themselves.

Especially if they’re running shit like UPnP

IPSec tunnels have been working around NAT for over a decade at this point.

At the end of the day imho the days of a perimeter firewall doing jack shit are over.

You can’t trust your lan, and every internal host needs to be treated as if it is on the internet.

Because any internal host can basically set up tunnels back inside fairly trivially these days.

Essentially in order to delay Ipv6 we basically ended up with something far worse. All the bullshit associated with NAT, and the “security” some people thought they had was a mirage.

3 Likes