Linux Bug Opens Most VPNs to Hijacking

A vulnerability in most Linux distros has been uncovered that allows a network-adjacent attacker to hijack VPN connections and inject rogue data into the secure tunnels that victims are using to communicate with remote servers.

According to researchers at University of New Mexico and Breakpointing Bad, the bug (CVE-2019-14899), “allows…an attacker to determine if…a 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.”

In an advisory released this week, they noted that once a proof-of-concept exploit allowed them to determine a VPN client’s virtual IP address and make inferences about active connections, they were then able to use encrypted replies to unsolicited packets to determine the sequence and acknowledgment numbers of connections. These allowed them to hijack TCP sessions and inject data into the TCP stream.

Anatomy of an Attack

An attack would require convincing a user to connect to a rogue wireless access point (or other internet connection) under the adversary’s control (imagine a coffee shop scenario, for instance). The attacker can then start scanning devices connected to the access point for active VPN sessions.

To do this, the access point can send SYN-ACK packets to any connected devices, canvassing across the entire virtual IP space. When a SYN-ACK is sent to the correct virtual IP on the victim device, the device responds; when the SYN-ACK is sent to the incorrect virtual IP, nothing is received by the attacker. An automated script would presumably make this process painless for the adversary.

Once the attacker determines that the user has an active TCP connection to an external server, the next step is to sniff out the next sequence number and in-window acknowledgment number needed to inject forged packets into the connection.

To find the appropriate sequence and ACK numbers, the attacker can continually spoof reset packets into the active connection until it sniffs challenge ACKs.

“The victim’s device will trigger a TCP challenge ACK on each reset it receives that has an in-window sequence number for an existing connection,” according to the advisory. “For example, if the client is using OpenVPN to exchange encrypted packets with the VPN server, then the client will always respond with an SSL packet of length 79 when a challenge ACK is triggered.”

Continuing with packet-spoofing and challenge ACK analysis (detailed in the advisory), an attacker can infer the rest of the information needed to inject arbitrary payloads into the victim’s active VPN session.

Affected OS and VPNs

The bug affects macOS, iOS and Android, most Linux distributions including Ubuntu, Fedora and Debian, as well as Unix-like OS such as FreeBSD and OpenBSD. At particular risk are those Linux distros that use a version of systemd pulled after November 28 of last year, which turned reverse path filtering off, researchers warned. The IPv4 version of CentOS has been confirmed as unaffected.

As for VPN technology, researchers found that a proof-of-concept exploit works against OpenVPN, WireGuard and IKEv2/IPSec, and they’re in the process of testing Tor.

“The VPN technology used does not seem to matter and we are able to make all of our inferences even though the responses from the victim are encrypted, using the size of the packets and number of packets sent (in the case of challenge ACKs, for example) to determine what kind of packets are being sent through the encrypted VPN tunnel,” according to the advisory.

The bug has been reported to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard.

“Adding a prerouting rule to drop packets destined for the client’s virtual IP address is an effective [mitigation] on some systems,” according to the advisory. “There are other potential solutions being considered by the kernel maintainers, but I can’t speak to their current status.”

Free Threatpost Webinar:_Risk around third-party vendors is real and can lead to data disasters. We rely on third-party vendors, but that doesn’t mean forfeiting security. _Join us on Dec. 18th at 2 pm EST_ as Threatpost looks at managing third-party relationship risks with industry experts Dr. Larry Ponemon, of Ponemon Institute; Harlan Carvey, with Digital Guardian and Flashpoint’s Lance James. _Click here to register.