A virtual private network (VPN) is supposed to keep the user’s traffic over a network safe from outside onlookers. They act as a protected path for communication over a public network to gain access to the resources and capabilities of the private network without a physical connection. Researchers at University of New Mexico have discovered a vulnerability in most Linux distros that allow an attacker to discover if the victim is using a VPN and to even hijack active connections within the VPN. The vulnerability is tracked as CVE-2019-14899.
The Attacker needs to be network adjacent to the victim to set up a rogue access point for which the victim will connect. This allows the attacker to determine the victim’s virtual IP address, make inferences about the victim’s active connections, and then to determine the sequence and acknowledgement numbers of the active connection by examining the encrypted replies to unsolicited packets. This gives the attacker the ability to hijack the TCP session. This acts much like echolocation or backscattering effects to determine the shape of something by observing the reactions of something thrown at it, be it sound waves, charged particles, or unsolicited packets.
This method was tested against several VPN services including OpenVPN, WireGaurd, and IKEv2/IPSec. The vulnerability was found to be exploitable in both IPv4 and IPv6 connections. It was not effective against any Linux distribution before the Ubuntu 19.10. In Ubuntu 19.10, the rp_filter settings were set to “loose” as opposed to “strict”, but can be changed manually. The researchers believe that ToR users are protected as the encryption for these connections occur in user space.
The systems this vulnerability effects are as follows:
• Ubuntu 19.10 (systemd)
• Fedora (systemd)
• Debian 10.2 (systemd)
• Arch 2019.05 (systemd)
• Manjaro 18.1.1 (systemd)
• Devuan (sysV init) • MX Linux 19 (Mepis+antiX)
• Void Linux (runit)
• Slackware 14.2 (rc.d)
• Deepin (rc.d)
• FreeBSD (rc.d)
• OpenBSD (rc.d)
Turning on Reverse path filtering (setting the rp_filter to “strict”), filtering fake addresses with bogon filtering, and encrypting both packet size and timing would help mitigate the issue.