NAT Slipstremaing? bad security hole?

Hardware Hub Networking
1

thoughts opinions?

EDIT: https://samy.pl/slipstream/

1 Like
2

Do you have a more technical explanation of this? When you visit a website, the return traffic is always on a random high port. I don’t see how the attacker gets in unless they highjack the session. That diagram looks like layer 5 is being compromised, not layer 4, but I’m probably missing something.

That said, NAT has always been a security issue. With IPv6 you don’t need it, but then IPv6 has its own history of security problems (or at least implementations of IPv6).

1 Like
3

The actual source https://samy.pl/slipstream/ that is linked to on that page.

You can reply back on any port not blocked by the web browser, didn’t really read through all of it though so maybe some other interesting things in there as well.

2 Likes
4

and IPV6 is whole other ball game all-together, unless i’m mistaken

1 Like
5

Ok, so if I’m understanding correctly, the attacker can leverage an FTP or SIP connection to inject packets through NAT to any port (assuming port does need to be open on the host). But then the victim will need a reason to trust that data. So you you could push (or “slip”) packets into FTP, HTTP or other insecure protocols, but I’m not sure you could break into a session and definitely not into SSL/TLS traffic.

The network discovery part is interesting.

  • hidden img tags to all common gateways (eg 192.168.0.1 ) are loaded in background
  • onerror/onsuccess events attached to img tags
  • if any TCP RST (oneror) returned by gateway, or SYN + HTTP response (onsuccess), within a few seconds (before TCP timeout triggers onerror), we’ve detected valid subnet
  • re-perform timing attack across all IPs on detected subnets (/24), measuring time to onerror/onsuccess firing
  • fastest response is likely internal IP, though all responses are considered victim internal IP candidates and attacked
1 Like