Subject: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Oct 2012 15:51:49 -0300

Hi, folks,

We have published a new IETF I-D that discusses the VPN traffic-leakage
issues that was briefly discussed on this mailing-list a few weeks ago.

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-opsec-vpn-leakages-00.txt>

Any feedback will be really welcome.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt
Date: Mon, 15 Oct 2012 11:36:34 -0700
From: [email-masked]
To: [email-masked]

A new version of I-D, draft-gont-opsec-vpn-leakages-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Filename:	 draft-gont-opsec-vpn-leakages
Revision:	 00
Title:		 Virtual Private Network (VPN) traffic leakages in dual-stack
hosts/ networks
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-vpn-leakages-00.txt
Status:
http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages
Htmlized:        http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages-00

Abstract:
   The subtle way in which the IPv6 and IPv4 protocols co-exist in
   typical networks, together with the lack of proper IPv6 support in
   popular Virtual Private Network (VPN) products, may inadvertently
   result in VPN traffic leaks.  That is, traffic meant to be
   transferred over a VPN connection may leak out of such connection and
   be transferred in the clear on the local network.  This document
   discusses some scenarios in which such VPN leakages may occur, either
   as a side effect of enabling IPv6 on a local network, or as a result
   of a deliberate attack from a local attacker.  Additionally, it
   discusses possible mitigations for the aforementioned issue.

The IETF Secretariat

---

From: KK <[email-masked]>
Date: Sun, 21 Oct 2012 12:30:14 -0700

Hey Fernando,

Some minor editorial nits and a question...

Section 1.

"Section 2 provides some background about IPv6 and IPv4
co-existence, summarizing how IPv4 and IPv4 interact on a typical
dual-stacked network"

I think you meant IPv4 and IPv6 here

Section 3.

"Therefore, for dual-stacked systems, it is not possible to secure secure
the communication with another system without securing both protocols (IPv6
and IPv4)."

You repeat secure twice

Now for the question:

While I understand the premise of the problem here and agree that there is
potential for VPN traffic leakages, I am trying to understand the scope of
this threat in typical VPN setups.

Let's say user Bob wants to access his files from a file server on his
enterprise network while enjoying a latte from a cafe. He pulls up his vpn
client, establishes a secure connection and tries to connect to
filer1.example.com. To me, the use of a VPN client implies that the server
is not publicly accessible over the Internet.

Now, he gets back an A and AAAA record for filer1.example.com. Typically,
that name would resolve to IPvX addresses that are only accessible from
within the network. Common security best practices regardless of IPv4 or
IPv6 would suggest that you achieve this by either applying appropriate
filtering policies to prevent access from the outside world and/or
only advertising prefixes that you want global reachability to/from.

Let's say that Bob's host prefers the AAAA record and uses IPv6, his
request for accessing the files would probably go out in the clear over
IPv6 but will most likely end up being dropped either at the local IPv6
router because it has no routes to this protected network, or at the edge
of his corporate network by some ACL that blocks access from the outside
world. Granted, there is still the potential of one-way communication
attempts going out in clear text on Bob's LAN at the cafe and subject to
interception.

So my question is, is the premise here that the network behind the VPN head
end globally routable without any filtering mechanisms in place? If that's
the case then yes, VPN leakage here can be severe and detrimental.

Thanks,
KK

---

From: Fernando Gont <[email-masked]>
Date: Sun, 21 Oct 2012 20:07:04 -0300

Hi, KK,

Thanks so much for your feedback! -- Please find my comments inline...

> I think you meant IPv4 and IPv6 here
[....]

Yep -- I will fix this and the other reported nits.

> enterprise network while enjoying a latte from a cafe. He pulls up his
> vpn client, establishes a secure connection and tries to connect to
> filer1.example.com <http://filer1.example.com>. To me, the use of a VPN
> client implies that the server is not publicly accessible over the
> Internet. 

Agreed. But the vulnerability being discussed does not really imply that
the attacker is able to get access to some resources he'd otherwise not
have access to, but rather that there's a traffic leakage.

e.g., if the client employs some insecure protocol (e.g., that sends
user and password in the clear), he may think it's okay to use it over a
VPN. But with this attack, that user/pass could end up appearing in the
clear on the local network.

Another example: the user might be employing some protocol that does not
include confidentiality services (e.g., MSN) -- but the user thinks
that's still okay, since he's using that protocol over a VPN. But then
the corresponding traffic might be sent on the local network, in the clear.

> Now, he gets back an A and AAAA record for filer1.example.com
> <http://filer1.example.com>. Typically, that name would resolve to IPvX
> addresses that are only accessible from within the network. Common
> security best practices regardless of IPv4 or IPv6 would suggest that
> you achieve this by either applying appropriate filtering policies to
> prevent access from the outside world and/or only advertising prefixes
> that you want global reachability to/from.

Agreed. But the I-D is not implying this attack scenario. -- Please do
let me know if you think this is not clear, and, in such case, where/how
I could improve the I-D.

> outside world. Granted, there is still the potential of one-way
> communication attempts going out in clear text on Bob's LAN at the cafe
> and subject to interception.

Exactly. This attack scenario, along with the case in which the client
is employing the VPN for having some sort of confidentiality at least on
the way out of the insecure network he's connecting to, are the
scenarios that this I-D is discussing.

> So my question is, is the premise here that the network behind the VPN
> head end globally routable without any filtering mechanisms in place? If
> that's the case then yes, VPN leakage here can be severe and detrimental. 

Nope. For instance, the I-D is not supposed to discuss such kind of
scenario, but rather the other two attack scenarios I've mentioned above.

Thanks!

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

---

From: KK <[email-masked]>
Date: Fri, 26 Oct 2012 14:43:22 -0700

Hi Fernando,

Sorry for the delayed response.

> let me know if you think this is not clear, and, in such case, where/how

What might help is to make the scope a bit more explicit by providing the
example you just gave me -

"""the vulnerability being discussed does not really imply that
the attacker is able to get access to some resources he'd otherwise not
have access to, but rather that there's a traffic leakage.

e.g., if the client employs some insecure protocol (e.g., that sends
user and password in the clear), he may think it's okay to use it over a
VPN. But with this attack, that user/pass could end up appearing in the
clear on the local network."""

Something as simple as the above text in either Section 1. or Section 4.
might really help.

Thanks,
KK

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 27 Oct 2012 14:10:46 -0700

Hi,

> Any feedback will be really welcome.

The attack that i am most concerned about is that many folks assume
the VPN will "lock the stack".  And, the VPN software may in fact lock
the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints
is allowed).  But, in the case of dual stack, the VPN locks the IPv4
stack and the IPv6 stack is left wide open to a public WLAN.  So, the
attacker at a coffee shop can own the VPN users system via IPv6 and
therefore access the secure corporate network over IPv4.   This is not
a case of protocol translation or traffic leaking, but a case of using
a "jump host" to illicitly move from a public WLAN to a secure
corporate network.

I think there is also some additional ipv6 nuance that can be explored
in this case of a dual-stack VPN.  For example, how is LLA treated on
the coffee shop WLAN?   Also, the name server issue can be explored,
if RA or DHCPv6 provides a DNS server, the VPN client should be sure
to not use those since a rogue DNS server can create a situation where
VPN traffic is leaked.... http://intranet is spoofed by the local
attacker DNS server and skims login creds

CB

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Oct 2012 18:24:45 -0300

Hi, KK,

On 10/26/2012 06:43 PM, KK wrote:
> What might help is to make the scope a bit more explicit by providing
> the example you just gave me - 
> 

Okay. I will incorporate this into the next rev.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Oct 2012 20:28:14 -0300

Hi, Cameron,

Thanks so much for your feedback! Please find my comments in-line....

> a "jump host" to illicitly move from a public WLAN to a secure

Agreed.

It looks like I should probably change the title of the I-D to something
along the lines of

"Security Implications of dual-stack hosts/networks on Virtual Private
Networks (VPN)"

or

"Security Issues of Virtual Private Networks (VPN) in dual-stack hosts/
networks"
?

(please do let me know if you have any preference of title over the
other, or feel free to suggest an alternative title)

Then the I-D could mention possible/common security implications such:

* Lost of confidentiality in the resulting traffic (i.e., you thought
your traffic was protected from eavesdroppers, when in fact it wasn't)

* The possibility of an attacker stealing credentials (e.g. if an
insecure protocol was sending user/pass in the clear)

* And the attack scenario you describing (an attacker using the VPN as a
pivot to attack some system in the VPN).

> the coffee shop WLAN?   

In what sense?

> Also, the name server issue can be explored,

Agreed. I will try to test common implementations (Windows, *BSD,
Solaris, and Linux) with respect to this issue, and provide a summary.

Thanks so much for your feedback!

Best regards,