Security testers from the University of New Mexico discovered a vulnerability, tracked as CVE-2019-14899, that can be exploited by an attacker to determine if a user is connected to a VPN and hijack active TCP connections in a VPN tunnel.
This bug exists in the networking stack of various operating systems and can be exploited against both IPv4 and IPv6 TCP streams.
While the vulnerability not necessarily relies on the VPN service used, the attack works against broadly implemented virtual private network protocols like OpenVPN, WireGuard, IKEv2/IPSec, and others.
The vulnerability is known to impact most Linux distributions and Unix-like operating systems, including FreeBSD, OpenBSD, macOS, iOS, and Android.
An attack first would need to trick a user into connecting to a rogue wireless access point, or a sniffed wired connection under the adversaries' control. The adversaries then would start scanning for the devices connected to their access point for active VPN sessions.
To accomplish it, their access point would send SYN-ACK packets to any connected devices. When an 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. Presumably, an automated script would make this process effortless for the adversaries.
Once the attacker determines that the user has an active TCP connection to an external server, the next step is to sniff out the exact 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, an attacker can infer the rest of the information needed to inject arbitrary payloads into the victim's active VPN session.
Adversaries can hijack "secure" VPN connections of those working remotely, for instance, injecting data into their TCP streams. For this reason, we generally advise not to rely 100% on VPNs, and not to trust in third-party VPNs.
It seems not to work against The Onion Router (TOR) because the destination address would be 127.0.0.1 and Linux drops packets to that destination unless the input the interface is loopback or route_localnet.
Linux is becoming more popular, and actually, most servers use Unix-like operating systems. It makes these systems more appetizing for adversaries to try to hack and steal valuable information. The prediction is that attacks against Linux and any other Unix OS are going to rise.
This vulnerability is tracked under:
There are possible mitigations published by the team at the University of New Mexico.
However, there is no final solution yet. Adding a pre-routing rule to drop packets destined for the client's virtual IP address is potential mitigation on some systems, according to the team.
Untrusting any open wireless or even wired connection is the best way to stay safe, use your own connections whenever possible, if working from a coffee shop, for instance, you can use your mobile to provide internet to your laptop.
TTPs: Tactics, techniques and procedures
CVEs: Common Vulnerabilities and Exposures