How to hijack VPN tunnel session on Linux, FreeBSD, OpenBSD, MacOS, iOS and Android

A group of vulnerability testing specialists from the University of New Mexico, made up of William J. Tolley, Beau Kujath and Jedidiah R. Crandall, just reported a vulnerability present in most of Linux distributions and other operative systems that, if exploited, would allow threat actors to discover whether another user is connected to a VPN, the virtual address assigned to the server, and whether there are active connections to some specific websites. This attack would also allow data injection into TCP flow and connection hijacking.

Most distributions vulnerable to this flaw use the systemd version corrected after November 28, 2018, which disabled reverse path filtering; however, the attack also works against IPv6. For protection, adding a pre-routing rule to discard packets destined to the client’s virtual IP address is effective on some systems, but this was only tested on researchers’ machines.

The vulnerability works against OpenVPN, WireGuard, and IKEv2-IPSec and, although it has not been tested against tor, it is believed to be not vulnerable because it includes authentication and encryption in the userspace. Hackers can resort to the sent packets’ size and number to infer what kind of packets are sent through the VPN tunnel, regardless of the VPN technology used by the target user.

In their report, vulnerability testing experts divide the attack into three stages:

  • Determine the virtual IP address of the VPN client
  • Use the virtual IP address to make inferences about active connections
  • Use encrypted responses to unsolicited packets to determine the sequence and recognition numbers of the active connection to hijack the TCP session

Moreover, there are 4 components for attack playback:

  • Victim device (connected to AP, 192.168.12.x, 10.8.0.8)
  • Access point (controlled by the attacker, 192.168.12.1)
  • VPN server (not controlled by attacker, 10.8.0.1)
  • A web server (not controlled by the attacker, public IP in a real scenario)

The target device must be connected to the access point (during testing a laptop with create_ap) was used. The device must then connect to its VPN provider.

List of affected operating systems

The vulnerability was successfully analyzed on the following operating systems:

  • Ubuntu 19.10 (systemd)
  • Fedora (systemd)
  • Debian 10.2 (systemd)
  • Arc 2019.05 (systemd)
  • Manjaro 18.1.1 (systemd)
  • Return (sysV init)
  • MX Linux 19 (Mepis + antiX)
  • Empty Linux (runit)
  • Slackware 14.2 (rc.d)
  • Deepin (rc.d)
  • FreeBSD (rc.d)
  • OpenBSD (rc.d)

This list consists only of the operating systems analyzed during the investigation, so vulnerability testing experts mention that other distributions need to be tested.

Potential solutions

Enable reverse route filtering

Possible problem implementing this solution: Asynchronous routing is not reliable on mobile devices, etc. It is not clear that this is really a solution, as it seems to work on other operating systems with different networks. In addition, even with reverse route filtering in strict mode, the first two parts of the attack can be completed, allowing the attacker to make inferences about active connections, making it still possible to complete the attack.

Fake IP addresses leaking

Potential problem in implementing this solution: Local network addresses used for VPNs and local networks, and some nations, such as Iran, use reserved private IP space as part of public space.

Encrypted packet size and timing

Because the size and number of packets allow the attacker to bypass the encryption provided by the VPN service, perhaps some kind of padding could be added to the encrypted packets to be the same size. In addition, because the Process Limit Challenge ACK allows us to determine whether the encrypted packets are Challenge ACKs, allowing the host to respond with packets of equivalent size after exhausting this limit could prevent the attacker from making this inference, as mentioned by vulnerability testing experts from the International Institute of Cyber Security (IICS).

A full report on this vulnerability, its scope and the potential consequences of its exploitation is now ready for publication, however, it will be revealed until the compromised Linux distributions launch an appropriate solution. Other affected services that have already been notified include Systemd, Google, Apple, OpenVPN and WireGuard, as well as other distributions of the affected operating systems.