VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts

[Fernando Gont]

Folks,

FYI. This is might affect NetBSD users employing e.g. OpenVPN:
<http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.

For a project such as OpenVPN, a (portable) fix might be non-trivial.
However, I guess NetBSD might hook some PF rules when establishing the
VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is
certainly not the most desirable fix, but still probably better than
having your supposedly-secured traffic being sent in the clear).

P.S.: Please check the corresponding thread (same "Subject") on the
***@openbsd.org mailing-list, since they have some patches for some of
these issues...

Thanks,
--
Fernando Gont
e-mail: ***@gont.com.ar || ***@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

I see this as being not only about security, but also about usability.

Lets assume that a host where I work is dual homed and that I can connect to it at work using IPv4 or IPv6.
Since the network where I work is a private network (10, etc), I can only connect to it using a VPN however for IPv6, the address is globally visible. This may make it seem like I can connect to that internal host from anywhere on the Internet but that's not exactly right. For me to be able to do that, the place that I work needs to allow IPv6 connections from the Internet to an internal host.
And that last point is the key.

Let's stay in that example. Your "inside" host has IPv4 and IPv6, your
VPN only does IPv4, and you click on http://intranet.corp/ in your web
browser.

Now, in many cases your browser will try IPv6 first, wait for the result
of that, then go to IPv4. *If* your corp firewall returns a RST right
away, this failover will be quick. If it just drops the SYN, IPv4 failover
will only occur after a lengthy timeout - so users turn off IPv6 to
remediate this. Wrong message.


The security aspect comes if someone manages to MITM the IPv6 connection,
and puts up some sort of phishing portal looking halfway official
("due to more and more attacks to our VPN users, the management has
decided that all connections via VPN to http://intranet.corp must do
an extra login via web browser first, before permitted access"). From
experience with audits, half your users will happily fill in the web
form... of course to make this official, you need to target individual
companies, with proper web page logos and so on, but it is a viable
attack that the VPN is supposed to prevent.

gert

[Gert Doering]

Hi,

But on the other hand I agree with Darren's points. This is a policy
matter, and NetBSD as an OS should be neutral, allowing users to set
policy. So I'd say that VPN packages (as opposed to what's in the
NetBSD base system) should handle this, offering a configuration option.
I disagree with Fernando's characterization that IPv6 traffic not going
in a VPN (or being blocked0 when a v4 VPN is configuration is
necessarily a bug. For the totally-controlling corporate policy types,
yes, but for many no. So I'd say that it's a bug for a VPN package not
to make this configurable; perhaps that's what he meant.

I think the reason to bring this to an OS-specific list is that this
is surprisingly *hard* for a VPN package to actually achieve.

So, assume you are in the world of strict corporate policies, and want
to ensure that "all IPv6 traffic only goes to the VPN". With "policy based"
IPSEC implementations, this is fairly easy, but you need kernel support
for that. OpenVPN, OTOH, does "this goes to VPN!" by putting up a route
to the tun/tap interface. This starts being problematic as soon as you
have more specific routes in your tables (locally connected networks,
RAs with more-speicfic route options, RAs with *new* locally connected
networks while OpenVPN is done with its initialization, assuming that
all networks have been covered, ...).

So the interesting question is "how can the OS help the VPN package
to not have this 'bug'?".


(In Android or iOS, you just tell the VPN API "all networks go *there*",
and the kernel will ensure that. In normal Linux, you could do this with
"ip rule" and extra routing tables that will not be affected by RAs. In
the BSDs, we don't know...)

gert

[Darren Reed]

Post by Gert Doering
Hi,
I see this as being not only about security, but also about usability.

Lets assume that a host where I work is dual homed and that
I can connect to it at work using IPv4 or IPv6.
Since the network where I work is a private network (10, etc),
I can only connect to it using a VPN however for IPv6, the address
is globally visible. This may make it seem like I can connect to
that internal host from anywhere on the Internet but that's not exactly right.
For me to be able to do that, the place that I work needs to allow
IPv6 connections from the Internet to an internal host.
And that last point is the key.

Let's stay in that example. Your "inside" host has IPv4 and IPv6, your
VPN only does IPv4, and you click on http://intranet.corp/ in your web
browser.
Now, in many cases your browser will try IPv6 first, wait for the result
of that, then go to IPv4. *If* your corp firewall returns a RST right
away, this failover will be quick. If it just drops the SYN, IPv4 failover
will only occur after a lengthy timeout - so users turn off IPv6 to
remediate this. Wrong message.

Right, so that is a firewall configuration issue for the firewall
that connects the corporate network to the Internet. But most
likely the people that see the timeouts won't understand that
it is IPv6 or how to disable IPv6 and thus they'll complain to
their corporate IT staff who should fix the external firewall.

Post by Gert Doering
The security aspect comes if someone manages to MITM the IPv6 connection,
and puts up some sort of phishing portal looking halfway official
("due to more and more attacks to our VPN users, the management has
decided that all connections via VPN to http://intranet.corp must do
an extra login via web browser first, before permitted access"). From
experience with audits, half your users will happily fill in the web
form... of course to make this official, you need to target individual
companies, with proper web page logos and so on, but it is a viable
attack that the VPN is supposed to prevent.

Again, the only way an IPv6 connection can be attacked with a
MITM attack is if the external firewall permits an insecure protocol
across its boundary. If I can access http://intranet.corp through
the firewall when then VPN is not working then that is a much
bigger issue than just IPv6 packets getting through.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de