A number of Linux distributions, including Ubuntu, Fedora, and Debian, contain a newly discovered vulnerability that an attacker could use to determine whether an individual is using a VPN and then potentially hijack that encrypted connection.
A research team from the University of New Mexico discovered the vulnerability and developed an attack to exploit it. The attack has some specific requirements and relies on some analysis of the traffic going to and from the target device running the VPN client. The attack is confirmed to work against WireGuard and OpenVPN, but the researchers said that the VPN a victim is using doesn’t really matter. The main prerequisite for the attack to work is for the attacker to be able to send unsolicited packets to the victim’s VPN client.
The vulnerability “allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel,” the advisory from the researchers says.
In the attack scenario the researcher team of William Tolley, Beau Kujath, and Jedidiah Crandall developed, an attacker who controls the access point to which a victim is connected will send packets to the entire virtual IP space of a given VPN. When a SYN-ACK packet hits the virtual IP address used by the victim, the client will respond with a RST packet, which allows the attacker to determine the victim’s virtual IP address. The next step is to figure out if the victim has an active TCP connection to a specific site, which the attacker can do by spoofing packets from the site’s IP address. The attacker then tries to infer the next sequence number and in-window acknowledgement number, which would enable him to inject malicious packets into the connection.
“To find the appropriate sequence and ACK numbers, we will trigger responses from the client in the encrypted connection found in part 2. The attacker will continually spoof reset packets into the inferred connection until it sniffs challenge ACKs. The attacker can reliably determine if the packets flowing from the client to the VPN server are challenge ACKs by looking at the size and timing of the encrypted responses in relation to the attacker's spoofed packets,” the researchers said in their advisory.
“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. 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. In practice, when the attacker thinks it sniffs an encrypted challenge-ACK, it can verify this is true by spoofing X packets with the same sequence number. If there were X encrypted responses with size 79 triggered, then the attacker knows for certain it is triggering challenge ACKs.”
Once the attacker is able to determine the exact in-window sequence and acknowledgement numbers, he can then inject his own malicious packets into the victim’s active TCP connection. The attack the researchers developed works against many current Linux distributions, and also against Android and iOS. Among the vulnerable Linux distributions are Ubuntu 19.10, Fedora, Debian 10.2, Arch 2019.05, and Manjaro 18.1.1.
The researchers suggested a few mitigations for their attack, such as enabling reverse path filtering, which could prevent the attacker’s spoofed packets from reaching the victim. It's important to note that that the attack exploits a weakness in the OS and not in the specific VPN software on the client machine.
“It doesn't appear to be a flaw in the OpenVPN software, but a flaw in the configuration of the operating system itself. The issue is more in how the operating system deals with this type of attack in general, rather than anything going wrong in the VPN connection itself,” said OpenVPN Access Server Product Manager Johan Draaisma.