Slashdot Mirror


UK Researchers Find IPv6-Related Data Leaks In 11 of 14 VPN Providers

jan_jes writes: According to researchers at Queen Mary University of London, services used by hundreds of thousands of people in the UK to protect their identity on the web are vulnerable to leaks. The study of 14 popular VPN providers found that 11 of them leaked information about the user because of a vulnerability known as 'IPv6 leakage'. The leakage occurs because network operators are increasingly deploying a new version of the protocol used to run the Internet called IPv6. The study also examined the security of various mobile platforms when using VPNs and found that they were much more secure when using Apple's iOS, but were still vulnerable to leakage when using Google's Android. Similarly Russian researchers have exposed the breakthrough U.S. spying program few months back. The VPNs they tested certainly aren't confined to the UK; thanks to an anonymous submitter, here's the list of services tested: Hide My Ass, IPVanish, Astrill, ExpressVPN, StrongVPN, PureVPN, TorGuard, AirVPN, PrivateInternetAccess, VyprVPN, Tunnelbear, proXPN, Mullvad, and Hotspot Shield Elite.

23 of 65 comments (clear)

  1. 14 tested, 11 leaked... by rotaryexpress · · Score: 4, Interesting

    The 14 tested are listed, but not the ones that are leaking data? Why list one and not the other?

    1. Re:14 tested, 11 leaked... by hcs_$reboot · · Score: 3, Funny

      Because TFS writer is too lazy to read TFA.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:14 tested, 11 leaked... by AmiMoJo · · Score: 2

      TFA doesn't actually say which ones were no vulnerable. However, Mulvad has features to protect against IPv6 and DNS leaks, so it looks like they are aware of this problem and fixed it a while back.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  2. "IPv6 Leakage"??? Give me a break. by mark-t · · Score: 4, Insightful

    The study of fourteen popular VPN providers found that eleven of them leaked information about the user because of a vulnerability known as âIPv6 leakageâ(TM).

    No.... That has nothing to do with IPv6, it has to do with what those VPN's support. What that statistic really means is that 11 out of fourteen VPN providers don't really support IPv6 in the first place.

    1. Re:"IPv6 Leakage"??? Give me a break. by Geordish · · Score: 5, Informative

      Exactly this.

      The problem occurs when you have an IPv4 VPN tunnel, and IPv6 native connectivity. The IPv6 connectivity will be preferred over the IPv4 tunnel, and you will connect natively.

      The fix? There are two

      1) Add IPv6 support to the VPN, and default route traffic over that.
      2) Drop the IPv6 connection while connected to the VPN.

      The first solution is obviously best.

    2. Re:"IPv6 Leakage"??? Give me a break. by dissy · · Score: 2

      No.... That has nothing to do with IPv6, it has to do with what those VPN's support. What that statistic really means is that 11 out of fourteen VPN providers don't really support IPv6 in the first place.

      Well if IPv6 packets can pass at all, clearly they support IPv6.

      The problem is that they likely are accidentally supporting it with no knowledge about doing so.

      Would you put your Windows box on the IPv4 Internet with no firewall what so ever?
      I don't mean having a firewall and accidentally misconfiguration it, I mean having a firewall and not adding a single rule.

      Well, that's exactly what these VPN providers did for the IPv6 protocol. They have zero IPv6 firewall rules.

      So while inbound IPv4 packets are filtered with a default deny rule and any allow rules the customer wants, also likely filtering some outbound as well, their IPv6 rules are default allow.

      Odds are if you fired up a PC with IPX or NetBEUI as the protocol, their firewall would gladly allow that traffic unfiltered as well.

      For example in the Linux iptables packet filter, you can disable the IPv6 protocol completely with a single command:
      iptables -I INPUT -p 41 -j DROP

      If course using IPv6 properly is a bit more work, as you have to allow the ipv6 protocol in the main iptables, and use ip6tables or something like that for filter rules on the other IP stack.

      Either way, allowing everything (no matter what protocol) has always been said to be unwise, and now these companies and their customers can see why.

    3. Re:"IPv6 Leakage"??? Give me a break. by KiloByte · · Score: 2

      For example in the Linux iptables packet filter, you can disable the IPv6 protocol completely with a single command:
      iptables -I INPUT -p 41 -j DROP

      No, that will drop just one of many ways of tunnelling IPv6 over IPv4. To drop or manipulate IPv6 packets, you need to use ip6tables instead.

      And you really shouldn't be using DROP here, as it will delay every connection until timeout expires. You want REJECT instead.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    4. Re:"IPv6 Leakage"??? Give me a break. by unixisc · · Score: 2

      If this is the model that any VPN service uses, it's really stupid, for 2 reasons:

      • - It combines the weakness of IPv4 tunnels i.e. overlapping private address ranges, and the weakness of IPv6 gateways - proactively assigning node addresses if DHCPv6 ain't supported
      • - It ignores one of the greatest strengths of IPv6 - better connectivity for VPNs

      In IPv6, there would be 3 ways to natively support a VPN:

      • - Use Unique Local Addresses (fd00::/8) which would ensure a good likelihood of non-overlapping address ranges
      • - Make a VLAN of Global Unicast Addresses from the 2 networks in question, adding only the nodes that need to be in it
      • - Assign addresses from one of the networks to nodes in the other, and set up a proxy connection b/w the two

      Simply extending IPv4 concepts to IPv6 is likely to break things, given the changes in how the networks are built: in IPv4, nodes have to request addresses, whereas in IPv6, nodes are automatically assigned addresses. So when constructing VPNs, network admins would have to account for those differences while defining their networks.

      Frankly, I don't see how a VPN could be constructed if the IPv6 networks in question don't have DHCPv6 support. That's the minimum that needs to be there, otherwise every node in the networks would be a part of a VPN, regardless of whether they need to be or not. A few days ago, we were discussing DHCPv6 support in Android: this is one of the cases where SLAAC + DAD/ND is inadequate, and where you need to have a well defined address assignment policy

    5. Re:"IPv6 Leakage"??? Give me a break. by unixisc · · Score: 2

      It looks like the issue here is that since IPv6 addresses are freely assigned to any node in a network devoid of DHCPv6, nodes that shouldn't belong in that network get IP addresses, and thereby access to all traffic within the network. In IPv4, if DHCPv4 weren't there, a node has to be manually configured, or else, it doesn't get an address. In IPv6, if DHCPv6 ain't there, a node still gets an address courtesy the combination of SLAAC, ND and DAD.

      The solution to this would be to mandate DHCPv6, but networks that choose to avoid it allow the free assignment of addresses to any node within the range of the network, such as tablets or phones that see the SSID. Routers see that thing within the network, and assume that it needs to be assigned one of the addresses from their range. If that node happens to be a hostile spying node, it gets the access and then automatic entry into the VPN, thereby defeating its purpose. With DHCP, one could define which nodes get IP addresses and which don't.

  3. ipv6 incompetence is nothing new. by nimbius · · Score: 4, Interesting

    we mandated ipv6 a while back and like alcoholics we refused to give up ipv4 for a myriad of nagging and petulent reasons. its coming back to haunt us now, with everything from legacy routers that cant grok ipv6 right to switches that cant tag or trunk v6. Many commercial firewalls even struggle to answer the questions "can you support ipv6?" and "can you route it?" with a definitive answer.

    for the average user theres no clear or quick answer; youll just have to agree that some third party got it right. For slashdotters theres easy-rsa tools to start your CA and OpenVPN which has had support for ipv6 since 2.3. "leakage" is an ephemeral and undefined problem in TFA, but for those of us that live and breathe on planet RTFM an openvpn tunnel that supports v4 and v6 is trivial.

    im speaking of the states, but here our cable and fibre providers have 90% coverage of a dual-stack configuration of ipv6 and ipv4 direct to the device. Sure, the modem only grants 1 ip for 1 customer (at least until the net neutrality suits are settled) but once you step into a fresh IPv6 address the measure of this ipv6 debacle becomes apparent. Big players arent playing: Amazons various services dont support ipv6 and most of your TLD's outside of the googleverse dont get AAAA. the open source community at freenode does support it however, and most shared/vps hosting providers do as well, so if you need a project this summer at least consider looking at your docsis3 options/ipv6 lease and get to work on that vpn!

    --
    Good people go to bed earlier.
    1. Re:ipv6 incompetence is nothing new. by petermgreen · · Score: 4, Insightful

      I can see a few ways informatoin could leak in a dual stack situation involving a VPN that would not happen if everything was IPv4 only

      1: The users local connectivity is dual stack (or v6 only) but the VPN is IPv4 only. The result is IPv4 goes via the VPN but IPv6 doesn't. The user thinks the VPN is hiding the origin of their traffic but it isn't hiding the origin of all of it. With a bit of extra work it may also be possible for a website or an attacker in the network to tie the direct v6 address(es) to the VPN v4 address.
      2: IPv6 traffic does go via the VPN but addresses are generated in such a way that the users MAC address is revealed (for example the user has a network behind the VPN and that network uses MAC based IP autoconfiguration). This MAC address can later be tied
      3: The machine has an IPv6 address from the local ISP. Even if routing tables or firewall configurations are such that this address won't be used for making connections an application could still mistakenly send it as part of a payload. The same could in principle happen with IPv4 but it's much less likely due to pervasive use of NAT.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. Re:ipv6 incompetence is nothing new. by gstoddart · · Score: 4, Insightful

      Well, then the real thing here is that despite everybody claiming IPv6 is awesome and super, there's crappy and inconsistent support for it.

      So why should any small company or individual be doing anything about IPv6 when the big players aren't, and most of the existing products are apparently doing a terrible job of it?

      IPv6 has been coming "Real Soon Now" for what feels like an eternity. People aren't going to spend money to change when they still need to figure out how to work with the legacy stuff.

      You describe both the epic failure of IPv6 to gain widespread adoption, and the reasons why people are staying the hell away from it.

      --
      Lost at C:>. Found at C.
    3. Re:ipv6 incompetence is nothing new. by Geordish · · Score: 2

      People don't want to use IPv6 because it's stupidly complex and hard to secure. There is too much broadcasting/announcing/autorouting/and other bullshit in IPv6. The address format sucks and is something only a Lisp design committee could love (wait, did I put 7 or 8 empty colons there?! Ah, dammit).

      This sounds like you don't know what you are talking about. To start with, in IPv6 there is no broadcasting at all. Anywhere broadcast was used (eg ARP) this has been replaced with multicast. Announcing and autorouting? Not sure what you mean by this, but if its the router advertisements when using SLAAC then how is this different from IPv4 and DHCP? FYI this doesn't have to be turned on. From a pure routing point of view (I work for ISPs) it works no different than to IPv4. Address length aside of course.

      As for empty colons... Are you writing addresses like 2001:db8::::::6? Sounds like you need to read an RFC. That can be written as 2001:db8::6. (Of course you can only truncate one set of colons, but there is only 7 maximum in total.

      What is hard to secure about it? I would like some genuine details on this. I don't see where it is harder than IPv4 (address length aside)

      The reason that it isn't widely deployed is simple. It is not backwards compatible. If the spec had been written so an IPv4 addressed machine could communicate with an IPv6 addressed machine without any of the hackery we are now looking at, we wouldn't be having this conversation. Unfortunately when the spec was written over 20 years ago routers were not that powerful, and they were trying to limit the amount of work they had to do.

    4. Re:ipv6 incompetence is nothing new. by Anonymous Coward · · Score: 2, Interesting

      If address space were an important factor, they would have taken away large blocks to organizations that don't need them.

      I know a university with a class B block and they have maybe 100 servers that need to have publicly routable IP addresses but they have an entire class B block. If you connect to the wifi on campus you get a public facing IP address! All the computers in every lab on campus has a public IP address. Your laptop or tablet will have an address like 166.127.34.139(first two octets changed to hide the incompetent) and their weak firewall only stops ICMP traffic to your device.

      That is 65,000+ wasted addresses at just one location and they aren't the only address wasters, not even close.

      Next you have loopback 127.0.0.1/24. That is a massive waste. What machine needs 16,777,216 local addresses?

      Now you have private address spaces: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 which is nearly 18 million addresses. Far more than any one needs in a private address.

      I wouldn't be surprised if 50% of the IPv4 address space is wasted.

      The motivation behind IPv6 is security, and only pushed along because of IPv4 address waste.

    5. Re:ipv6 incompetence is nothing new. by unixisc · · Score: 2

      Problem is if you tried to redefine everything within the 127. space that's not 127.0.0.1 as public unicast space, you'd have to fiddle w/ the IPv4 protocol of every router, and then you'd have 2 versions of IPv4 in supposedly IPv4 compatible equipment. That would pretty much end IPv4 communications as we know it. Even today, there is IPv4 equipment that's unaware of CIDR or subnet masks or even NAT.

      You are right about the wastage, but you're forgetting something: IPv4 was never designed for global use. It was designed by the DoD purely for use by the Pentagon and everybody they worked w/. They were never going to get anywhere even close to 4 billion users, and given the scope of what they were, it was the right fit. Now IPv4 went viral, became a part of TCP/IP and caught on, and once the scope became the whole world, it was woefully inadequate for the job. The IETF recognized that, and set on working on a successor. Since any new protocol would have broken compatibility, since the address header would no longer be 32 bits, they made the new protocol address header 128 bits, so that it was unlikely to be ever changed. Of course, that meant breaking compatibility w/ every piece of Layer 3 equipment, which is why they went for the clean room approach. Some of the concepts they tried to lock in - such as autoconfiguration - was IMO overkill, and ended up potentially restricting this protocol as well, but I think that we could in future get to a point where we could use /96 subnets instead of /64.

    6. Re:ipv6 incompetence is nothing new. by unixisc · · Score: 2

      It's still very much an issue, since even NAT is running this, and we need to get into 2 layers of NAT, such as NAT 444. That sort of networking won't be much different from SPX/IPX networking that we once had from Novell, where the communications were layer 2 rather than layer 3. IPv6 by contrast enables pure layer 3 communications

    7. Re:ipv6 incompetence is nothing new. by EmperorOfCanada · · Score: 2

      For some reason I have always had two problems with IPv6. One is that it offers me as an end user exactly nothing terribly tangible. Yes yes I know of the whole running out of addresses stuff but I have never contacted a server host who said, "Sorry we are out of addresses." My ISP has never said, "Sorry no more customers we are out of addresses." So why should the average user even give a crap.

      The other thing that I have found is that without exception those who I have met who are pushing IPv6 remind me nearly perfectly (and in many cases were) the same Y2K people who told us that the world was going to end. They are grade A assholes. Thus it instantly makes me suspect that IPv6 has hidden surprises buried in it that will piss me off. So paternalistic shit that is "good for me" but in reality somehow allows some asshole admin to fuck up my traffic because his traffic has a higher priority or some such bullshit.

      So my prediction is that when all is said and done there will never be IPv6 but someone is going to come up with IPG2 (Generation 2) that is chock a block full of things that we all want. Things where we will be happy to demand that our ISPs make the leap, things that get us out there to buy new networking gear.

      IPv6 will basically become XHTML. Some will argue that this is impossible but WEP was pretty much tossed into the trash and everyone was onboard with the new things like WPA in a heartbeat. Not because it satiated the black heart of some pedantic network admin but because it was actually better.

  4. Facepalm by jones_supa · · Score: 3, Informative

    The study of 14 popular VPN providers found that 11 of them leaked information about the user because of a vulnerability known as 'IPv6 leakage'. The leakage occurs because network operators are increasingly deploying a new version of the protocol used to run the Internet called IPv6.

    Aaarggghh!!! The summary does not explain the issue properly at all.

    All that happens here is that the user's IPv4 traffic is tunneled through the VPN, but his IPv6 traffic is broadcasted past the VPN.

    I'm sure this problem can be avoided with some reconfiguration. The easiest solution would be to simply chuck off the IPv6 subsystem in the operating system.

  5. TFA: by Kiyyik · · Score: 5, Informative

    http://www.eecs.qmul.ac.uk/~ha...

    (Since there doesn't seem to be a link).

    Basically, the table on page 3 is probably where you want to start looking. TorGuard, PrivateInternetAccess, VyperVPN & Mullvad are proof against IPv6 leakage, so it's actually 10 of 14 that aren't.

    Also, they found Astrill is proof against OpenVPN and PPTP/L2TP DNS hijacking. Interesting read.

  6. Referenced Article is a Teaser Webpage by Tokolosh · · Score: 3, Interesting

    The actual study is due to be presented at a future conference. In that sense the findings have not yet been made. So we are lured by clickbait into discussing something that has not happened. This is a waste of time.

    Tangentially, what is the purpose of headlines that say things like "President will announce tomorrow that he is starting World War 3"? Isn't that the same as announcing it now? Does he think we are stupid? Oh, wait...

    --
    Prove anything by multiplying Huge Number times Tiny Number
  7. According to the article... by Streetlight · · Score: 2

    Quote:

    "Interactions with websites running HTTPS encryption, which includes financial transactions, were not leaked."

    Whew... Although there are some privacy implications, HTTPS seems to work for your most important web use. And, with the transition to almost all sites running HTTPS encryption - hopefully with no bugs in that - the problem cited in the article may go away. There have been some concerns about HTTPS reliability, such as forged certificates, but hopefully the problems will be solved. I'm not completely up to date an the problems w/ HTTPS, though.

    --
    In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
  8. Re:Teredo leaks by greenwow · · Score: 4, Interesting

    But don't do that! Disabling IPv6 is an "unsupported configuration" to use the phrase our former Microsoft support rep used. I say former because they canceled our support contract without a refund after we admitted to disabling IPv6. There are many things broken in Windows if you disable IPv6, so many that Microsoft won't even try to support it and punishes people that do in order to publicize that fact.

  9. More Microsoft fanbois w/ mod points! by Anonymous Coward · · Score: 2, Interesting

    Amazing how they attack anyone here, like this guy, when someone posts the truth about Microsoft. Microsoft most certainly has a policy against disabling IPv6. They burned some of our license keys for disabling IPv6. Their official policy from:

    https://technet.microsoft.com/en-us/network/cc987595.aspx

    "IPv6 is a mandatory part of the Windows operating system"

    It is not optional. Microsoft will hurt you for disabling it, if they can. The guy that runs Microsoft now, John Thompson, has talked about taking legal action against businesses that disable IPv6, but hey you Microsoft fanboi moderators, don't let the facts get in the way of lying and calling people trolls that point out official written Microsoft policy.