From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: NAT Slipstreaming
Date: Thu, 04 Feb 2021 21:37:13 +0100
Message-ID: <ac989013-5b81-780d-3d5a-61fc263427ea@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4789139820968820667=="
List-Id: <development.lists.ipfire.org>

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