Oh. This could be “fun”.
Image; Twitter post by @firstname.lastname@example.org
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.
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?
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.
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.
@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: https://news.ycombinator.com/item?id=23263857
He's been posting about it a while back. Will have to read up on it. But it's interesting, yeah!
@devrandom how does this [in function, not form] differ from STUN/TURN?
Workaround for Linux:
modprobe -r nf_nat_sip
Firewall all the things!
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.