A new vulnerability(CVE-2019-14899) was discovered in Linux and Unix-like systems, allowing 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 unaffected by this vulnerability as it operates in a SOCKS layer, including authentication and encryption in userspace. The vulnerability is independent of the VPN technology. 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. A vulnerability management tool fixes this vulnerability.
CVE-2019-14899 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 to “loose” mode. The default settings in sysctl.d/50-default.conf in the systemd repository changed from ‘strict’ to ‘loose’. Patching is also important by using a patch management software.
Typical Attack Scenario in CVE-2019-14899
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 confirms that the IP address was correct, otherwise, it can be concluded the IP address was incorrect. When it sends a correct four-tuple (source IP address, source port number, destination IP address, and destination port number), the device responds with two challenge ACKs per second. In contrast, an incorrect four-tuple receives an RST for each packet sent.
TCP Window, Credits: thegeekstuff.com
Attack scenario
The attacker now tries to determine the exact next sequence number. In 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. Spoof the 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 receives a challenge for ACK, he can verify it by spoofing X packets with the same sequence number.
Attack scenarios:
Determines the exact sequence number and in-window ACK by spoofing empty push-ACKs. With the in-window sequence while guessing in-window ACK numbers. The exact in-window ACK number is 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 by CVE-2019-14899
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)
Impact of CVE-2019-14899
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.
Solution to CVE-2019-14899
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
- 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.
- Using Bogon filtering
Uses Bogon filtering 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.
- 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 made of equivalent size with padding, the attackers would find it difficult to pick out the exact packets and hence prevent attacks.