Study discovers security vulnerabilities in 14 popular VPN services

[Dieter Holger]

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.

https://www.techspot.com/news/61224-study-discovers-security-vulnerabilities-14-popular-vpn-services.html

 

[Darth Shiv]

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]

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]

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).

 

[Evernessince]

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.

 

[Darth Shiv]

The ipv4 traffic wouldn't be leaked tho...