A vulnerability that can be exploited to determine if a user is connected to a VPN and hijack active TCP connections in a VPN tunnel has been found to affect various Linux and Unix operating systems.
The vulnerability, tracked as CVE-2019-14899, was discovered recently by a team of researchers from the University of New Mexico. They privately reported their findings to the developers of the affected operating systems some time ago, and they have now made their findings public on the SecLists.Org and Openwall security mailing lists.
According to the experts, the flaw impacts Linux distributions — including Ubuntu, Fedora and Debian — FreeBSD, OpenBSD, macOS, iOS and Android. They have tested the attack against OpenVPN, WireGuard, and IKEv2/IPSec VPNs, but pointed out that the type of VPN technology used does not seem to make a difference.
The attack works against both IPv4 and IPv6 connections. However, the researchers say it does not work against the Tor anonymity network.
The vulnerability allows an attacker who is on the same network as the targeted user to determine if they are using a VPN, obtain the virtual IP address assigned by the VPN server, determine if the target is currently accessing a specified website, and even inject data into the TCP stream. This can allow the attacker to hijack active connections within the VPN tunnel.
The attack can also be launched using a malicious access point, the researchers said.
While the same attack method might work against the affected Linux distributions, there are variations for each of the other impacted operating systems.
Colm MacCárthaigh, who works for AWS and helps develop Amazon Linux and the company’s VPN products, says they are not impacted by the vulnerability. However, he has described the attack method as “very impressive” and has warned that it can pose an even more serious threat if combined with DNS spoofing.
“Encrypted DNS queries and replies can be profiled by traffic analysis, and the reply ‘paused’, making it easier to ensure that a DNS spoofing attempt will succeed,” MacCárthaigh explained. “This is a good reminder that cryptographic protections are best done end to end; DNSSEC does not help with this attack, because it does not protect traffic between the stub resolver and the resolver. It’s also a good reminder that traffic analysis is still the most effective threat against network encryption.”