@devrandom
Image; Twitter post by @samykamkar@twitter.com

Image text; "I've released NAT Slipstreaming, a spooky new technique that allows an attacker to remotely access any TCP/UDP service bound to a victim machin, bypassing the victim's NAT/firewall, just by the victim visiting a website. samy.pl/slipstream/ Happy Halloween!"

Embedded image providing visual overview of the NAT Slipstreaming technique, showing the purported access to various IoT devices on the victim computer's network.

@Ephaemera
Holy crap. The way this plays with SIP packets and tricks the firewalls into exposing the internal IP addresses is incredibly devious, using the firewall's own defense mechanisms against it.

This shit is cosmic-horror levels of evil.

A first glance tells me that the only way we can prevent this type of attack is to add an explicit allow list for websites, at least until a patch for application level firewalls comes in.

@TheGibson what do you think about this?

@devrandom

@yuki @Ephaemera @devrandom

I think your assessment is pretty spot on.

Gonna be hard to patch... it's a problem in pretty embedded. gonna have to sign Natted traffic somehow.

@djsundog @yuki @Ephaemera @devrandom

The idea of hosting services with a direct IPv6 connection gives me the willies... security in layers... and shit...

@thegibson @djsundog @yuki @Ephaemera @devrandom I mean, we could stop using the convenience that is NAT. We could hardwire every port to a fixed internal IP, and tell our OSs to use a fixed set of source ports... 🎃

@djsundog @thegibson @yuki @Ephaemera @devrandom Does getting rid of NAT eliminate one of the attack surfaces that Slipstreaming depends upon?

@vertigo @djsundog @yuki @Ephaemera @devrandom

hmm... is it simply bypassing NAT, or exploiting a weakness?

personally I would disregard all of this and focus on detection of the Evil .js that has to run first.

@TheGibson @vertigo @yuki @Ephaemera @devrandom indeed - our propensity for running untrusted remote code is the vulnerability, the rest is just a specific example

@djsundog @vertigo @yuki @Ephaemera @devrandom

My entire focus is on the detection and response cycle at this point in my career... this is a simple attack to disrupt from the POV...

The problem is the number of people who don't have access(or ignorantly don't run endpoint security products of some sort) getting hit.

We need to make a ubiquitous EDR that is available and good.

@TheGibson One of the attack components seems to be exploiting a weakness in the Linux SIP connection tracking module to permit the reverse connection. In the current form, it's looks pretty specific to that module being used on the NAT gateway.
Not impossible that something similar can be done to SIP connection tracking (or a different protocol that's being parsed by the gateway) on commercial firewall products.

@vertigo @djsundog @yuki @Ephaemera @devrandom

@thegibson @vertigo @djsundog @yuki @Ephaemera @devrandom

It appears to be exploiting a design feature in NAT, and using SIP as one means of completing the slipstream. This is because of the design features of NAT, SIP, & webrtc. As far as I can recall, this has been done before, but with other protocols, and with more limited results.

So, eliminating NAT and going IPv6 could fix this. Or disabling webrtc. Endpoint security -> odd padding happening in the network stack, esp with sip.

@bill @vertigo @djsundog @yuki @Ephaemera @devrandom

Should be able to detect the exploit in the .js execution chain as well... stop it before it has a chance to start.

@yuki @Ephaemera @devrandom

The real way to mitigate it is strong endpoint security though... If the malicious java script never fires, nothing to worry about.

@TheGibson This looks pretty bad for your standard residential NAT gateway, but depends on a lot of specifics going just right to assemble all of the required attack components.

On the client side, something like uBO could also help - either by virtue of the "Prevent WebRTC from leaking local IP addresses" option, or with a filter that disallows arbitrary websocket connections to RFC1918 addresses for the scanning approach, like this here: news.ycombinator.com/item?id=2

@yuki @Ephaemera @devrandom

@devrandom
He's been posting about it a while back. Will have to read up on it. But it's interesting, yeah!

@devrandom

> 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.

Oh good, so it won't affect any infra I maintain

@devrandom how does this [in function, not form] differ from STUN/TURN?

@jeff @devrandom
AFAIU, this bypasses stateful firewall (eg. conntrack) in the same way, as long as the firewall does application-level connection tracking (which is necessary for multi-port applications like FTP active mode, SIP, and a few others)

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.