Security Study discovers security vulnerabilities in 14 popular VPN services

Dieter Holger

Posts: 39   +1

This week, researchers from Sapienza University of Rome and Queen Mary University of London published a study detailing security vulnerabilities among 14 popular VPN service providers. While normally these services are seen as a secure way to transfer data over a public network or get onto blocked websites, some of them can actually reveal your entire browsing history. This is due to what the researchers describe as "IPv6 traffic leakage" and "DNS hijacking."

Provider Countries Servers Technology DNS IPv6-leak DNS hijacking
Hide My Ass 62 641 OpenVPN, PPTP OpenDNS Y Y
IPVanish 51 135 OpenVPN Private Y Y
Astrill 49 163 OpenVPN, L2TP, PPTP Private Y N
ExpressVPN 45 71 OpenVPN, L2TP, PPTP Google DNS, Choopa Geo DNS Y Y
StrongVPN 19 354 OpenVPN, PPTP Private Y Y
PureVPN 18 131 OpenVPN, L2TP, PPTP OpenDNS, Google DNS, Others Y Y
TorGuard 17 19 OpenVPN Google DNS N Y
AirVPN 15 58 OpenVPN Private Y Y
Private Internet Access 10 18 OpenVPN, L2TP, PPTP Choopa Geo DNS N Y
VyprVPN 8 42 OpenVPN, L2TP, PPTP Private (VyprDNS) N Y
Tunnelbear 8 8 OpenVPN Google DNS Y Y
proXPN 4 20 OpenVPN, PPTP Google DNS Y Y
Mullvad 4 16 OpenVPN Private N Y
Hotspot Shield Elite 3 10 OpenVPN Google DNS Y Y

Out of the 14 VPN services covered by the study, 10 were vulnerable to IPv6 leaks and only one was safe from DNS hijacking. None of the VPN providers were secured against both IPv6 leaks and DNS hijacking.

The issues stem from the VPN providers manipulating the IPv4 routing table but ignoring the IPv6 table. Plus, the paper notes the VPN tunnel protocol PPTP, which is common among the VPN service providers, is particularly vulnerable.

To end the traffic leakage, the researchers suggest the providers ensure their IPv6 table captures all traffic. Additionally, a change should be made to the VPN tunnel protocol so it secures the DNS. Hopefully, the critiqued VPN providers will take notice of the research and swiftly address the security flaws.

Header Image: Shutterstock

Permalink to story.

 

Darth Shiv

Posts: 2,034   +622
Am I right in thinking if your ISP isn't serving you on ipv6, you wouldn't be affected as you'd be operating exclusively on ipv4 routing?

I know that doesn't mean they shouldn't fix this urgently but it won't be anywhere near as widespread short term impact at least...
 

Evernessince

Posts: 4,979   +5,094
Am I right in thinking if your ISP isn't serving you on ipv6, you wouldn't be affected as you'd be operating exclusively on ipv4 routing?

I know that doesn't mean they shouldn't fix this urgently but it won't be anywhere near as widespread short term impact at least...
It doesn't really matter if one end of the connection uses IPv4 as your data is going to be accessible at some point on a IPv6 node making it's way to it's destination. I'm guessing most of these VPNs knew about this issue, IPv6 is becoming an increasingly important standard.
 

Darth Shiv

Posts: 2,034   +622
It doesn't really matter if one end of the connection uses IPv4 as your data is going to be accessible at some point on a IPv6 node making it's way to it's destination. I'm guessing most of these VPNs knew about this issue, IPv6 is becoming an increasingly important standard.
I thought the biggest problem with ipv6 is that ipv4 routes entirely across ipv4? There was no bridging or translation. I.e. an ipv4 endpoint *cannot* contact a pure ipv6 endpoint AND an ipv4 endpoint cannot route across an ipv6 route?

See this diagram. The *server* is ipv4. The incoming connections are translated from ipv6 to ipv4. NOT the other way around. I.e. the network box presented an ipv6 endpoint to the world.
https://www.network-box.com/IPv4-IPv6Bridging

There is no translation for for ipv4 traffic out from a client to an ipv6 endpoint and I believe this is the same for routing. This is precisely the reason why ipv6 has had slow adoption. Only people with ipv6 internet connections can access them (massively vast majority on ipv4 exclusively of course).
 
Last edited:

Evernessince

Posts: 4,979   +5,094
I thought the biggest problem with ipv6 is that ipv4 routes entirely across ipv4? There was no bridging or translation. I.e. an ipv4 endpoint *cannot* contact a pure ipv6 endpoint AND an ipv4 endpoint cannot route across an ipv6 route?

See this diagram. The *server* is ipv4. The incoming connections are translated from ipv6 to ipv4. NOT the other way around. I.e. the network box presented an ipv6 endpoint to the world.
https://www.network-box.com/IPv4-IPv6Bridging

There is no translation for for ipv4 traffic out from a client to an ipv6 endpoint and I believe this is the same for routing. This is precisely the reason why ipv6 has had slow adoption. Only people with ipv6 internet connections can access them (massively vast majority on ipv4 exclusively of course).
I wasn't talking about translating IPv6 to IPv4. I was talking about network nodes (servers, backbone, ect) that support both IP versions (which should be quite allot until we fully finish the IPv6 conversion). If a client with IPv4 is connecting to a server that supports both IPv6 and 4 on a VPN, what would stop a hacker from accessing through the stated IPv6 leak?

You original question

"Am I right in thinking if your ISP isn't serving you on ipv6, you wouldn't be affected as you'd be operating exclusively on ipv4 routing?"

My point was that the IPv6 hack doesn't target you at all, it targets the servers that you are connecting to that support both IPv6 and IPv4. You may be connecting by IPv4 but the server has an two addresses, one v4 and one v6.