Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.
They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard.
The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android.
A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected:
• 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)
All VPN implementations are affected
This security flaw "allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website," according to William J. Tolley, Beau Kujath, and Jedidiah R. Crandall, Breakpointing Bad researchers at University of New Mexico.
"Additionally, we are able to determine the exact seq and ack numbers by counting encrypted packets and/or examining their size. This allows us to inject data into the TCP stream and hijack connections," the researchers said.
Attacks exploiting CVE-2019-14899 work against OpenVPN, WireGuard, and IKEv2/IPSec, but the researchers are still testing their feasibility against Tor.
They also note that the VPN technology used does not seem to be of importance since the attacks worked during their tests even when the responses they got from targets were encrypted, given that the size of the packets and the number of packets sent was enough to find the type of data packets that were being delivered through the encrypted VPN tunnel.
This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel.
The researchers discovered that most of the Linux distros they tested were vulnerable to attacks exploiting this flaw. They also found that all distros that use systemd versions released after November 28, 2018, that come with Reverse Path filtering switched from Strict mode to Loose mode, are vulnerable.
Given this, all Linux distributions using a systemd version with default configurations after this date are vulnerable.
It's important to note though that, despite some distros with specific systemd versions being vulnerable, the flaw is known to impact a variety of init systems and it is not only related to systemd as shown by the list of affected OSs available above.
Furthermore, network security consultant Noel Kuntze said in a reply to the disclosure report that only route-based VPN implementations are impacted by this vulnerability.
An alleged Amazon Web Services employee also stated that the Amazon Linux distro and AWS VPN products are not affected by attacks exploiting this flaw.
Mitigation is possible
Mitigation is possible according to the researchers and it can be potentially achieved by turning reverse path filtering on, by using bogon filtering —filtering bogus (fake) IP addresses — or with the help of encrypted packet size and timing.
These are the steps needed to run an attack designed to exploit this vulnerability and hijack a target's VPN connection:
1. Determining the VPN client’s virtual IP address
2. Using the virtual IP address to make inferences about active connections
3. Using the encrypted replies to unsolicited packets to determine the sequence and acknowledgment numbers of the active connection to hijack the TCP session
The full procedure to reproduce the vulnerability on Linux distros is explained in detail within the disclosure report publicly available here.
The research team is planning to publish a paper with an in-depth analysis of this vulnerability and its implications but only after finding an adequate workaround.
Comments
Warthog-Fan - 3 years ago
It looks like as many people are switching to Linux to avoid using Windows 10 we may be seeing more malware directed at Linux systems, whereas up until now, the Linux user base was so small that it wasn't worth the hackers' time to try to infiltrate.
Chris58369 - 3 years ago
I think a crap ton of the internet is Linux/*NIX servers are mostly on it because it’s more secure than windows... & a lot of people use their phones/tablets which is a form of it too... so...
MadScientist42 - 3 years ago
The problem isn't Linux. In fact the article mis-attributes the problem.
It's a systemd problem. Distros without systemd don't HAVE this issue.
"This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel."
Simply put, I wouldn't even tamper with this in runit. I'd leave it to someone else to knowingly compromise their box on an untrusted system/network. To be sure, the notion it's a vuln on Linux is ludicrous. The mode in question is vulnerable out of box.
bbcrenshaw - 3 years ago
That's not correct. Devuan, Slackware, Android, the BSDs, and iOS all have this in common: None use systemd (the last two aren't even Linux). This problem is clearly more profound than your assertion! The bug affects a plaethora of Unix-like operating systems, both with and without systemd (from the article). The facts are right there, the very same ones mentioned by other sources. Google, anyone?
tickerguy - 3 years ago
Unless I'm misunderstanding the reported CVE this is flat-out stupid; it's a configuration problem, not an actual code fault.
No gateway should EVER accept and process a packet from an "inside" network address that sources from the outside (e.g. externally-connected physical network interface.) If it does then its configuration is broken -- period. The amount of mischief that one can commit in such an instance is not limited to toying with VPN connections.