Subject: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage"

From: Fernando Gont <[email-masked]>
Date: Tue, 04 Sep 2012 13:18:41 -0300

Folks,

I was thinking about discussing the following scenario, that I came up
with a few days ago:

A dual-stacked user (v6 enabled by default) "visits" an IPv4-only
network, and establish his VPN with his office (for "mitigating"
sniffing attacks, etc.).

A local attacker sends forged ICMPv6 RAs, thus triggering IPv6
configuration at the victim nodes.

If any of the remote nodes the victim is trying to "visit" is
IPv6-enabled, then it's possible/likely that the IPv6 destination
address will be used over the IPv4 one. in which case the victim will
send his traffic on the local network, as opposed to "through the VPN".

Assuming the VPN product does not disable local v6 support, and that the
VPN does not provide IPv6 connectivity (*), this attack vector could
prove to be an interesting one ("unexpected", to some extent).

(*) even then, this attack might still work.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Dave Dugal <[email-masked]>
Date: Tue, 4 Sep 2012 12:28:25 -0400

I agree: interesting (read: dangerously unexpected).  This is precisely
why one of the SSL VPN gateways I'm intimately familiar with disables
IPv6 for the life of the [v4] VPN session.  It's a bit inconvenient for
me at home, but is the least worst option for the generally unaware user
(present company explicitly excluded).

- Dave

On 9/4/2012 12:18 PM, Fernando Gont <[email-masked]> proclaimed ...

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 4 Sep 2012 18:39:11 +0200 (CEST)

> (*) even then, this attack might still work.

Quite unexpected. VPN service should be also IPv6 capable.

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Sep 2012 11:42:04 -0300

Hi, Mohacsi,

> Quite unexpected. VPN service should be also IPv6 capable.

Problem is, the remote network with which the nomadic node is
establishing a VPN may simply not support IPv6.

That aside, I wonder what's the mechanism that the VPN software employs
to cause all v6 traffic to be sent on the VPN -- if it's just removing
the existing IPv6 default route, or leveraging IPv6 route priorities,
that could easily be circumvented by means of forged RAs.

Thanks!

Best regards,

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 10 Sep 2012 17:34:33 +0200 (CEST)

> (*) even then, this attack might still work.

Would the working scenario of this attack not be the more specific 
case of the classic
"IPv4-only access network; dualstack target; IPv6 MITM" case ?

There are two differences that I see though:

1) The difference between the trust level for IPv4 "legit" leg and IPv6 
"rogue" leg is even further apart than in the simple case. This is kind of 
interesting, but not terribly.

2) The IPv4 leg over VPN noticeably increases the latency. Now, this could 
be a dealbreaker, since it becomes way easier to race - especially given that 
for this scenario we'd be talking primarily wireless attackers, with a 
very tight delay budget.

--a

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Sep 2012 18:09:15 -0300

On 09/10/2012 12:34 PM, Andrew Yourtchenko wrote:
> Would the working scenario of this attack not be the more specific case
> of the classic "IPv4-only access network; dualstack target; IPv6 MITM" case ?

Yes. Although the security assumptions in each of these two cases are
totally different -- in the VPN case, your "secured" traffic goes, all
out of the sudden, unsecured.

> 2) The IPv4 leg over VPN noticeably increases the latency. Now, this
> could be a dealbreaker, since it becomes way easier to race - especially
> given that for this scenario we'd be talking primarily wireless
> attackers, with a very tight delay budget.

Are you thinking abut happyeyeballs?

Cheers,

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 11 Sep 2012 00:17:58 +0200 (CEST)

> out of the sudden, unsecured.

Exactly. Though I viewed this as just the different level of 
trust. Both in the VPN and non-VPN case I usually can somewhat reasonably 
assume that there is noone listening to my traffic right now, and in the 
VPN case this assumption is somewhat stronger (Cracking a 4096 bit RSA is 
a bit more work than reading plaintext but possible: http://xkcd.com/538/; 
Can be conveniently applied to the CA of choice).

> Are you thinking abut happyeyeballs?

yeah. while the "classic" rfc3484 behavior is a disaster outright, the HE, 
with its much shortened fallback to IPv4, should be helping. But in some 
implementations this advantage might be less than in the others.
Maybe interesting testing this stuff.

--a

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Sep 2012 12:27:43 -0300

Hi, Andrew,

On 09/10/2012 07:17 PM, Andrew Yourtchenko wrote:
> Exactly. Though I viewed this as just the different level of trust. Both
> in the VPN and non-VPN case I usually can somewhat reasonably assume
> that there is noone listening to my traffic right now, and in the VPN
> case this assumption is somewhat stronger (Cracking a 4096 bit RSA is a
> bit more work than reading plaintext but possible: http://xkcd.com/538/;

Agreed.

> yeah. while the "classic" rfc3484 behavior is a disaster outright, the
> HE, with its much shortened fallback to IPv4, should be helping. But in
> some implementations this advantage might be less than in the others.

Well, one would expect that in this case, the attacker would always win
if HE is in place, right?

P.S.: I'm all for the testing -- will do it for openvpn. Many other have
already reported vulnerable implementations on the corresponding thread
at the ipv6hackers mailing-list
(<http://lists.si6networks.com/listinfo/ipv6hackers/>).

Thanks!

Best regards,

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 13 Sep 2012 18:23:55 +0200 (CEST)

Hi Fernando,

> if HE is in place, right?

Actually, HE makes attacker's life harder than the "classic" TCP 
timeout-based - because in the latter case the IPv6 will take precedence, 
and the attacker has all the time. In the HE case, the window is way 
shorter.

--a

> (<http://lists.si6networks.com/listinfo/ipv6hackers/>).

;-) cool, thanks!

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2012 20:15:31 +0200

Hi,

On Thu, Sep 13, 2012 at 12:27:43PM -0300, Fernando Gont wrote:
> P.S.: I'm all for the testing -- will do it for openvpn. 

OpenVPN before 2.3 has no idea what IPv6 is (in client-server mode).

In 2.3 (of which beta1 has been released today), IPv4 and IPv6 default
redirection have to be done explicitely in the server config, and 
there is no "give me both!" command yet - so the server admin decides
what he wants, and might overlook one or the other.

Plus, while IPv6 communication can be redirected to the tunnel (by just 
pushing a 2000::/3 route), more specific IPv6 routes pointing elsewhere 
will still be honoured, including "connected /64" networks.

To make "--redirect-gateway block-local" (which does "all IPv4 communication
MUST go through the server!") work for IPv6 on all supported platforms is 
quite a bit of work, so it has not yet been done - it's likely to happen 
for OpenVPN 2.4, but for now the priorities have been "get out 2.3 with
at least some basic IPv6 support, well-tested and working across all
client platforms".

(In the end it's the usual problem of available time in open source 
projects...)

Gert Doering
        -- OpenVPN IPv6 wrangler
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Sep 2012 20:17:09 -0300

Hi, Gert,

> OpenVPN before 2.3 has no idea what IPv6 is (in client-server mode).

That's the impression that I got... but since I didn't play much with
openvpn (other than getting my vpn "up and running"), I didn't want to
make any sort of claim...

That said, I get the following banner:
OpenVPN 2.2.1 i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia]
[MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 2012

-- not sure what the PF_INET6 and "IPv6 payload 20110424-2 (2.2RC2)" mean.

> will still be honoured, including "connected /64" networks.

Yes. And there could be default routers with different priorities, too.

That's why I had claimed that "even if the vpn software supports v6, the
attack might still work".

> MUST go through the server!")

Without looking too close into the software, it looks that for the v4
case, openvpn simply installs an additional default route, which for
some reason takes precedence over the existing one?

> work for IPv6 on all supported platforms is 

So far, I'm simply disabling v6 if I need to rely on the VPN to work as
expected/intended.

Agreed.

>From my pov, what's important is to be aware about this issue, and to
figure out possible mitigations (even if that's is "turn off v6 if your
doing a vpn").

Thanks for the input!

Best regards,

---

From: Gert Doering <[email-masked]>
Date: Fri, 14 Sep 2012 20:14:22 +0200

Hi,

> -- not sure what the PF_INET6 and "IPv6 payload 20110424-2 (2.2RC2)" mean.

That's "you got a debian package that has most of the IPv6 goodies in
it already" :-) - both openvpn-over-IPv6 (PF_INET6) and IPv6-over-openvpn
have been available as patch sets for about two years now.  Debian included
them in their package, and I think you could enable it on Gentoo.

> attack might still work".

Yes.  Blocking "VPN evasion" traffic for IPv6 is more tricky than for IPv4, 
if the hosts supports RAs with more specific routes - even if you block
access to the local /64, someone might sneak in a /128 via RA from fe80.

I'm really wondering (thinking out loud now) how to block local IPv6
communication in a reasonably portable way... using routing is tricky,
using firewalling is even more tricky (as it's optional on all supported
operating systems, and the BSDs even have more than one option each...).

> some reason takes precedence over the existing one?

For IPv4, what OpenVPN does depends a bit on the flags given to 
--redirect-gateway, but there are two possible scenarios:

A.
 - 1. find out what the current default gateway is
 - 2. install /32 route for OpenVPN server to gateway
 - 3. delete default route
 - 4. install default route to tunnel
 - 5. on disconnect, re-install original default route

or B.
 - 3. override default route with two /1 routes (0.0.0.0/1 and 128/1)

in addition, "block-local" does
 - 3a. find out what the local LAN's netmask is, split into two more-specific
       subnets, route those into the tunnel (so local connectivity is blocked
       by the OpenVPN server dropping those packets)

this is not resilient against more-specific IPv4 routes either, but in
IPv4, these usually do not happen "magically" by unsolicited packets.

> So far, I'm simply disabling v6 if I need to rely on the VPN to work as

That can certainly be done, but I'm one of those that *want* to use IPv6,
if only to find places of brokenness that need to be fixed :-)

Gert Doering
        -- NetMaster

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Sep 2012 22:09:24 -0300

Hi, Gert,

On 09/14/2012 03:14 PM, Gert Doering wrote:
>> That said, I get the following banner: OpenVPN 2.2.1
>> i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH]
>> [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30
>> 2012
>> 
> That's "you got a debian package that has most of the IPv6 goodies
> in it already" :-) - both openvpn-over-IPv6 (PF_INET6)

This means IPv4 packets within IPv6 packets, right?

> and IPv6-over-openvpn have been available as patch sets for about
> two years now.  Debian included them in their package, and I think
> you could enable it on Gentoo.

Okay. There were no config hints in the sample config file, and hence
I assumed no v6 support.

>> That's why I had claimed that "even if the vpn software supports
>> v6, the attack might still work".
> 
> Yes.  Blocking "VPN evasion" traffic for IPv6 is more tricky than
> for IPv4, if the hosts supports RAs with more specific routes -
> even if you block access to the local /64, someone might sneak in a
> /128 via RA from fe80.

... and there's also ICMPv6 Redirect.

> I'm really wondering (thinking out loud now) how to block local
> IPv6 communication in a reasonably portable way... using routing is
> tricky, using firewalling is even more tricky (as it's optional on
> all supported operating systems, and the BSDs even have more than
> one option each...).

Thinking out loud, maybe using sysctl for disabling RA acceptance
would do the trick.

However:

1) This wouldn't prevent the scenario in which the victim receives the
malicious RAs before the vpn software is run.

2) I'd hope nodes ignore ICMPv6 redirects when there's no default
router -- but I haven't double-checked this.

3) When working on our IPv6 toolkit (http://www.si6ntworks.com/tools),
I was trying to find a portable way f obtaining the list of IPv6
addresses. While considering possible options, I recall reading that
use of sysctl was deprecated for Linux  -- and hence this might make
this option less desirable.

4) This might not apply to other UNIX'es (e.g., Solaris), and of
course wouldn't apply to Windows.

BTW, I'm interested on the subject, so please keep me posted if you
come up with something to fix this issue.

>>> To make "--redirect-gateway block-local" (which does "all IPv4
>>> communication MUST go through the server!")
>> 
>> Without looking too close into the software, it looks that for
>> the v4 case, openvpn simply installs an additional default route,
>> which for some reason takes precedence over the existing one?
> 
> A. - 1. find out what the current default gateway is - 2. install
> /32 route for OpenVPN server to gateway - 3. delete default route -
> 4. install default route to tunnel - 5. on disconnect, re-install
> original default route
> 
> or B. - 3. override default route with two /1 routes (0.0.0.0/1 and
> 128/1)

What about ICMP redirects?

> in addition, "block-local" does - 3a. find out what the local LAN's
> netmask is, split into two more-specific subnets, route those into
> the tunnel (so local connectivity is blocked by the OpenVPN server
> dropping those packets)
> 
> this is not resilient against more-specific IPv4 routes either, but
> in IPv4, these usually do not happen "magically" by unsolicited
> packets.

Same here: What about ICMP redirects? (which could trigger these)

>>> work for IPv6 on all supported platforms is quite a bit of
>>> work, so it has not yet been done - it's likely to happen for
>>> OpenVPN 2.4, but for now the priorities have been "get out 2.3
>>> with at least some basic IPv6 support, well-tested and working
>>> across all client platforms".
>> 
>> So far, I'm simply disabling v6 if I need to rely on the VPN to
>> work as expected/intended.
> 
> That can certainly be done, but I'm one of those that *want* to use
> IPv6, if only to find places of brokenness that need to be fixed
> :-)

Agreed. I'm just saying that, given the current state of affairs,
being vulnerable to this kind of attack is unacceptable to me (that's
why I'm doing the VPN in the first place), and hence this solves the
problem for me (albeit not in the most desirable way).

Cheers,

---

From: Gert Doering <[email-masked]>
Date: Sat, 15 Sep 2012 09:21:37 +0200

Hi,

> This means IPv4 packets within IPv6 packets, right?

No, that one is OpenVPN within IPv6 packets (using IPv6 transport).  Which
is something that "stock" OpenVPN 2.2 also did not do yet.

IPv4 packets within IPv6 is "IPv6 payload".

(In the end it just says "both patch sets that are needed to provide 
basic IPv6 support on the outside and inside are in" - it's two different
patch sets because they were developed by different persons.  2.3 will 
only say [IPv6] here)

> ... and there's also ICMPv6 Redirect.

And that, yes.

> Thinking out loud, maybe using sysctl for disabling RA acceptance

Certainly easier than fiddling with the firewall settings, yes.

> malicious RAs before the vpn software is run.

That one could be handled as we do today for IPv4 - "get a list of 
pre-existing routes, store away, delete all routes, install /128 route
for OpenVPN server's address, route default through tunnel".  After
the end of OpenVPN, restore routing state.

This might still be messy, as routes that started as "RA installed"
could then end up being "static".  Mmmh.

> router -- but I haven't double-checked this.

I'd hope that an implementation would ignore ICMPv6 redirects coming
from something that is not the gateway for the prefix in question.  But
that's wishful thinking, haven't tested.

> this option less desirable.

On Linux, OpenVPN 2.4 is very likely to use the netlink socket interface
for routing table manipulation and IP address querying.  On the BSDs, 
something similar will have to be found.

This part of OpenVPN is already very system specific, exec'ing "ifconfig"
and "route" to do its job - as no two operating systems use the same
syntax for either...

> course wouldn't apply to Windows.

Windows "Vista and up" *does* have fairly nice APIs for controlling 
IPv6 routing :-) - OpenVPN currently does not use them (uses netsh.exe
instead) because XP doesn't have these APIs yet...

> come up with something to fix this issue.

Will send a heads up.

[..]
> > --redirect-gateway, but there are two possible scenarios:
[..]
> Same here: What about ICMP redirects? (which could trigger these)

Good question.  I think they are currently not handled as all, as they
would be considered "pre-existing route".

Wether operating systems honour IPv4 ICMP redirects from routers that
are not the current target of the route anyway stands to be tested, as
for IPv6.  Hopefully not...

> problem for me (albeit not in the most desirable way).

Understood.

Gert Doering
        -- NetMaster

---

From: Fernando Gont <[email-masked]>
Date: Sat, 15 Sep 2012 10:51:49 -0300

On 09/15/2012 04:21 AM, Gert Doering wrote:
>> 1) This wouldn't prevent the scenario in which the victim
>> receives the malicious RAs before the vpn software is run.
> 
>  pre-existing routes, store away, delete all routes, install /128
> route for OpenVPN server's address, route default through tunnel".
> After the end of OpenVPN, restore routing state.
> 
> This might still be messy, as routes that started as "RA
> installed" could then end up being "static".  Mmmh.

You mean that those routes that started as dynamic would be
reinstalled as "static" because of the API you're using to reinstall them?

Wouldn't it be possible to reinstall them as dynamic, using the same
interface that, say, radvd uses?

>> 2) I'd hope nodes ignore ICMPv6 redirects when there's no
>> default router -- but I haven't double-checked this.
> 
> I'd hope that an implementation would ignore ICMPv6 redirects
> coming from something that is not the gateway for the prefix in
> question.  But that's wishful thinking, haven't tested.

Same here.

>> 3) When working on our IPv6 toolkit
>> (http://www.si6ntworks.com/tools), I was trying to find a
>> portable way f obtaining the list of IPv6 addresses. While
>> considering possible options, I recall reading that use of sysctl
>> was deprecated for Linux  -- and hence this might make this
>> option less desirable.
> 
> On Linux, OpenVPN 2.4 is very likely to use the netlink socket
> interface for routing table manipulation and IP address querying.

Why not "routng sockets"?

> On the BSDs, something similar will have to be found.

BTW, while looking at these, I wasn't able to find any documentation
for IPv6 routing sockets -- were you?

>  IPv6 routing :-)

I wasn't aware of this -- but nevertheless I was simply noting that
most likely Windows does not support syscctl as we know it from the
UNIX world?

> Good question.  I think they are currently not handled as all, as
> they would be considered "pre-existing route".

Not sure what you mean...

> Wether operating systems honour IPv4 ICMP redirects from routers
> that are not the current target of the route anyway stands to be
> tested, as for IPv6.  Hopefully not...

Will try this and report back.

Thanks,

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Sep 2012 13:46:24 +0200

Hi,

> reinstalled as "static" because of the API you're using to reinstall them?

Yep...

> interface that, say, radvd uses?

... if that interface exists, yet.  RA and ICMP redirects are handled by 
the kernel internally, so userland might not be able to re-install such
a route at all.

I'm currently pondering "ip rule" for this - just set up a separate 
routing table that only has two routes "VPN-Gateway to old default GW,
default to OpenVPN tunnel" and force all packets there via "ip rule" -
so no matter what was in the routing table before OpenVPN starts, or
is added while it runs, it won't be used unless it's in that particular
table (not safe against a malicious + clueful root user on the same box, 
though).

The terminology used shows that I have only toyed with the Linux approach
to things, but OpenBSD and FreeBSD have multiple routing tables as well,
so something along that line might be possible there, too.

No idea about Windows.

> Why not "routng sockets"?

I think I was thinking "routing sockets".  Haven't fully understood which
bits are called "routing socket" and which bits are "netlink socket",
but the intention is "the API that is used by programs like 'route' or
'ifconfig' under the hood".

> for IPv6 routing sockets -- were you?

Didn't go hunting yet.  I plan to start by reading the source code for
ifconfig and route... :-)

> most likely Windows does not support syscctl as we know it from the

No, windows would do "something else".  I'm not a windows programmer, 
so I'd ask one of the other OpenVPN team members who is planning to
overhaul the whole privilege architecture of OpenVPN-on-Windows for
2.4... :)

> Not sure what you mean...

I think OpenVPN doesn't currently handle any routes that are in the
routing table before OpenVPN starts and are not "the default route" or 
"the local LAN route" - they will just stay around.  ICMP redirects
would fall into the same bin.

> Will try this and report back.

I'm very curious to hear about your findings :)

Gert Doering
        -- NetMaster