Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.

They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard.

The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android.

A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected:

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

All VPN implementations are affected

This security flaw "allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website," according to William J. Tolley, Beau Kujath, and Jedidiah R. Crandall, Breakpointing Bad researchers at University of New Mexico.

"Additionally, we are able to determine the exact seq and ack numbers by counting encrypted packets and/or examining their size. This allows us to inject data into the TCP stream and hijack connections," the researchers said.

Attacks exploiting CVE-2019-14899 work against OpenVPN, WireGuard, and IKEv2/IPSec, but the researchers are still testing their feasibility against Tor.

They also note that the VPN technology used does not seem to be of importance since the attacks worked during their tests even when the responses they got from targets were encrypted, given that the size of the packets and the number of packets sent was enough to find the type of data packets that were being delivered through the encrypted VPN tunnel.

This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel.

The researchers discovered that most of the Linux distros they tested were vulnerable to attacks exploiting this flaw. They also found that all distros that use systemd versions released after November 28, 2018, that come with Reverse Path filtering switched from Strict mode to Loose mode, are vulnerable.

Given this, all Linux distributions using a systemd version with default configurations after this date are vulnerable.

It's important to note though that, despite some distros with specific systemd versions being vulnerable, the flaw is known to impact a variety of init systems and it is not only related to systemd as shown by the list of affected OSs available above.

Furthermore, network security consultant Noel Kuntze said in a reply to the disclosure report that only route-based VPN implementations are impacted by this vulnerability.

An alleged Amazon Web Services employee also stated that the Amazon Linux distro and AWS VPN products are not affected by attacks exploiting this flaw.

Mitigation is possible

Mitigation is possible according to the researchers and it can be potentially achieved by turning reverse path filtering on, by using bogon filtering —filtering bogus (fake) IP addresses — or with the help of encrypted packet size and timing.

These are the steps needed to run an attack designed to exploit this vulnerability and hijack a target's VPN connection:

1. Determining the VPN client’s virtual IP address

2. Using the virtual IP address to make inferences about active connections

3. Using the encrypted replies to unsolicited packets to determine the sequence and acknowledgment numbers of the active connection to hijack the TCP session

The full procedure to reproduce the vulnerability on Linux distros is explained in detail within the disclosure report publicly available here.

The research team is planning to publish a paper with an in-depth analysis of this vulnerability and its implications but only after finding an adequate workaround.