Not so safe: Encrypted VPN-tunnels

A new vulnerability(CVE-2019-14899) was discovered in Linux and Unix-like systems which allows an attacker in the adjacent network to inject data into the TCP stream and hijack connections. This vulnerability is known to work against OpenVPN, WireGuard, and IKEv2/IPSec, but the vulnerability impacts all VPN implementations. The tor browser seems to be unaffected by this vulnerability as it operates in a SOCKS layer and includes authentication and encryption that happens in userspace. The vulnerability is independent of the VPN technology used and the kind of packet sent through the VPN tunnel can be determined using the size and number of the packets sent, even though the responses are encrypted.

This loophole could be exploited on Linux systems using a version of ‘systemd’ pulled after 28th of November, 2018. With the release of Ubuntu 19.10, researchers found that the rp_filter settings were set to “loose” mode. The default settings in sysctl.d/50-default.conf in the systemd repository changed from ‘strict’ to ‘loose’.

Typical Attack Scenario

The attack takes place in three stages:
1) Determining the virtual IP of the VPN client.

2) Checking for an active TCP connection using the obtained IP Address.

3) Inferring the sequence and acknowledgment numbers of the connection to inject arbitrary packets.

The device is first connected to the Access Point(AP) and then the VPN provider. To determine the IP, the AP sends SYN-ACK packets to the victim device across the entire virtual IP space. When the device responds with an RST, the attacker can confirm that the IP address was correct, otherwise it can be concluded the IP address was incorrect. When a correct four-tuple (source IP address, source port number, destination IP address, and destination port number) is sent, the device responds with two challenge ACKs per second, while an incorrect four-tuple receives an RST for each packet sent to it.

TCP Window, Credits:

Attack scenario

The attacker now tries to determine the exact next sequence number and in-window acknowledgment number to inject forged packets into the connection. An attacker spoofs RST packets into the connection until it can sniff challenge ACKs. The RSTs have to be spoofed for different blocks across the entire sequence number space, the correct sequence number triggers an encrypted challenge ACK. A careful analysis of the the size and timing of the encrypted responses in relation to the attacker’s spoofed packets reveals if the packets flowing from the client to the VPN server are challenge ACKs. Once an attacker knows that a challenge ACK was received, he can verify it by spoofing X packets with the same sequence number.

The exact sequence number and in-window ACK is determined by spoofing empty push-ACKs with the in-window sequence while guessing in-window ACK numbers. The exact in-window ACK number is found when these spoofed push-ACK packets have triggered another challenge ACK. The attacker further continues to spoof empty TCP data packets until the victim responds with another challenge ACK i.e when the spoofed packed has the exact sequence number minus one. Now the attacker has details about the next sequence number and ACK.

We can divide the acknowledgment number space into a block of eight and send in spoofed empty PSH-ACKs with the in-window sequence number for each. Generally, seven blocks would trigger a challenge ACK and one would not. This block helps us determine the acknowledgement number.

These details of acknowledgement number and in-window sequence number are good enough for an attacker to inject arbitrary payloads into the ongoing encrypted connection.

Affected Systems

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)


A network adjacent attacker can learn about an active VPN connection, the VPN IP addresses and make inferences about the underlying TCP connection to hijack it.


We are currently not aware of any solution from vendors to resolve these vulnerabilities. We will continue to monitor this vulnerability and update as and when a fix is available.

Possible Mitigations

  1. Turn on Reverse Path Filtering

Reverse Path filtering protects against spoofed source addresses by discarding packets with source addresses that have no route or a route that does not point towards the originating interface.

  1. Using Bogon filtering

Bogon filtering is used to filter bogons, which are bogus (fake) IP addresses of a computer network. This would help prevent illegitimate IP addresses from reaching your network. Firewalls and Internet service providers embed Bogon Filtering to eliminate harmful addresses.

  1. Padding of encrypted packets

The main aim of attackers is to analyze the size and timing of these packets to exactly spot the challenge ACKs. If the packets could be made of equivalent size with padding, the attackers would find it difficult to pick out the exact packets and hence prevent attacks.


0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments