Hello development folks,
a few days ago, I came across an attack called "NAT Slipstreaming", which seems to have been first publicly documented at October 31st, 2020. As far as I am aware, some US-speaking IT news portals have coverage on that, while it did not appear in German/European IT security news so far (please drop me a line in case this is wrong).
Although it does not affect IPFire as such, I thought it might be an interesting read for those who are more into packet filtering and connection tracking here. Further, it offers some food for thoughts, of which some I would like to share here as well.
NAT Slipstreaming itself is documented at https://samy.pl/slipstream/, and it summary reads quite bad indeed:
NAT Slipstreaming allows an attacker to remotely access any TCP/UDP service bound to any system behind a victim's NAT, bypassing the victim's NAT/firewall (remote arbitrary firewall pinhole control), just by the victim visiting a website. [...]
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. [...]
While the attack's anatomy is another case of "whoops, we forgot feature X in combination with feature Y is causing a security problem" (quote shamelessly stolen from Marin Thomson and his "HTTPS sucks" talk worth seeing; https://www.youtube.com/watch?v=Xwp-4XS--K0), I am - based on security advisories and IT news such as the ones below - getting the feeling the web browser vendor's reaction is rather limited to blocking connections to destination ports commonly useful for this attack.
https://www.bleepingcomputer.com/news/security/new-slipstream-nat-bypass-att... https://www.bleepingcomputer.com/news/security/google-chrome-blocks-7-more-p...
In case I got this right, there are two scenarios of a NAT Slipstreaming attack:
(a) Bypassing ("punching") NAT in order to establish a direct TCP/UDP connection from the outside that would not have been permitted by the gateway/firewall/${whatever} as such.
(b) Performing reconnaissance of active devices and services within the local network, similar to Metasploit's pivot module launching a port scan via a dual-homed hacked machine located in a network the researcher does not have access to in the first place.
The first scenario is especially relevant to IPFire users, as it is basically precedence-setting on why people should use web proxies rather than letting their clients establish IP connections to the internet directly. Since Squid refuses to establish connections where something different than HTTP(S) is talked through, simply trying to tunnel a connection through the proxy in case of (a) would fail.
That is, of course, unless it comes to the CONNECT method, but this should be permitted to destination port 443 only. It is possible to establish a tunnel this way, but it neither is an arbitrary one nor a new attack vector.
If IPFire users have ever looked for a reason on why they should use the web proxy and (!) enforce a strict zero-exceptions firewall policy for outgoing connections from their clients, here they go.
However, to me, (b) is the interesting part here as it can only rarely be mitigated by IPFire, since we usually do not observe traffic occurring within the same network on our interfaces. While an IPS might detect such indirect scans, I did not had time to dig deeper into this, yet.
In terms of a holistic approach, IPFire users should ensure their clients cannot talk to each other, except for cases where they must (admin workstation SSH'ing into a colleague's one, or similar), and should pay special attention to IPS hits involving internal IP addresses.
Being a rather old-fashioned web browser user, "feature overloading" (WebRTC, WebAssembly, permitting direct periphery access to websites, and dozens of other techniques supported by common browsers today) always appeared to me as being a very, very bad idea. In contrast to SMTP, for example, we do not even have sufficient time to undergo security checks that take longer than a few milliseconds.
It goes beyond the scope of this mailing list to discuss why browsers should be able to establish non-HTTP(S) TCP/UDP connections by themselves. If they would not support that, NAT Slipstreaming - as far as I understood it - would not be an issue.
Thanks, and best regards, Peter Müller