From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: NAT Slipstreaming Date: Thu, 04 Feb 2021 21:37:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4789139820968820667==" List-Id: --===============4789139820968820667== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello development folks, a few days ago, I came across an attack called "NAT Slipstreaming", which see= ms to have been first publicly documented at October 31st, 2020. As far as I am aware, some U= S-speaking IT news portals have coverage on that, while it did not appear in German/Europea= n 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 interest= ing 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 arbitrar= y firewall pinhole > control), just by the victim visiting a website. [...] > > NAT Slipstreaming exploits the user's browser in conjunction with the Appli= cation 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 frag= mentation discovery, > TCP packet size massaging, TURN authentication misuse, precise packet bound= ary 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 som= e TCP and UDP packets > without including HTTP or other headers; the attack performs this new packe= t injection technique > across all major modern (and older) browsers, and is a modernized version t= o my original NAT > Pinning technique from 2010 (presented at DEFCON 18 + Black Hat 2010). Addi= tionally, new techniques > for local IP address discovery are included. > > This attack requires the NAT/firewall to support ALG (Application Level Gat= eways), 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=3DXwp-4XS--K0), I am - bas= ed on security advisories and IT news such as the ones below - getting the feeling the web browser vend= or'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-atta= cks-to-be-blocked-by-browsers/ https://www.bleepingcomputer.com/news/security/google-chrome-blocks-7-more-po= rts-to-stop-nat-slipstreaming-attacks/ In case I got this right, there are two scenarios of a NAT Slipstreaming atta= ck: (a) Bypassing ("punching") NAT in order to establish a direct TCP/UDP connect= ion 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 m= achine 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 somethi= ng 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 cl= ients, here they go. However, to me, (b) is the interesting part here as it can only rarely be mit= igated by IPFire, since we usually do not observe traffic occurring within the same network on our in= terfaces. 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 can= not 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, fo= r example, we do not even have sufficient time to undergo security checks that take longer than a few m= illiseconds. 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=C3=BCller --===============4789139820968820667==--