New Linux Vulnerability Lets Attackers Hijack VPN Connections (bleepingcomputer.com) 43
An anonymous reader writes: 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), and OpenBSD (rc.d).
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.
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.
Re: (Score:1)
Hasbara much?
Simple solution (Score:2)
Re:Simple solution (Score:5, Insightful)
Oh no! We found out that someone good at picking locks can get into you house. Lets just leave the doors unlocked.
Yes you can do SSH Port forwarding, or using application servers like Citrix, to get a good secure connection between you computer and the network. But a VPN is still a good solid solution for tying networks across an open internet.
Re: (Score:2)
The widespread nature of this vulnerability makes it seem like no accident
Re: (Score:3)
It would be nice if there was a boogeyman to blame, but instead, let's applaud good researchers instead.
Of note, I haven't heard that L2TP with IPSec is vulnerable, but it seems so. That will make several organizations very unhappy. Remember too that this requires proximity to the local network where the VPN user is, so sitting in a coffee shop with you, rather than sitting in Minsk --unless you're already got a curl session going on the same /24 with you.
Re: (Score:2)
I suppose the bogeyman is the extent to which libraries from the 1970's seem to live on forever in the various *nixes
fingerd is an perfect example of something that nobody should include in a distribution
afaiak, if you are not convinced somebody has put rootkits into every distribution, then you should become a landscaper
Re:Simple solution (Score:4, Insightful)
The widespread nature of this vulnerability makes it seem like no accident
Of course it isn't an accident. The description points out the exact configuration change that was made to cause the problem.
If you change the reverse path filtering option back to the setting it has been set to for years until systemd poked its fuckup-fingers into it, then you won't be vulnerable anymore.
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.
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.
Re: (Score:2)
mkay... then can you explain why it is also an issue with non-systemd OS's like FreeBSD, OpenBSD, macOS, iOS, and Android?
Re:Simple solution (Score:4, Informative)
It has nothing to do with systemd. It doesn't even have much to do with Linux. This weakness will exist on any TCP/IP stack that uses the Weak Host Model.
It's trivial to block, too. If your vpn interface is vpn0 and your vpn IP address is 10.0.8.1:
iptables -I INPUT --destination 10.0.8.1 \! -i vpn0 -j DROP
Re: (Score:3)
mkay... then can you explain why it is also an issue with non-systemd OS's like FreeBSD, OpenBSD, macOS, iOS, and Android?
Because it has been an issue there the entire time.
In Linux systems it was mitigated in the past, until systemd turned off the setting that mitigated it, so the problem is back.
Re: (Score:2)
You seem to be confused. I am not the author of the article Slashdot linked to where that was copy/pasted directly from.
Re: (Score:2)
Re: (Score:2)
The widespread nature of this vulnerability makes it seem like no accident
Yeah, just like the decades-old vulnerability in ssh.
Face it: Open Source is no panacea. The "Many Eyes" advantage has been proven ineffective time and again for quickly finding vulnerabilities. Like the 36-year old vulnerability in SCP:
https://www.zdnet.com/article/... [zdnet.com]
Re:Simple solution (Score:5, Informative)
The "Many Eyes" advantage has been proven ineffective time and again for quickly finding vulnerabilities.
Ineffective compared to what? Quickly compared to what? Zero eyes? Profit-motivated-Eyes-wide-shut?
You think it would have been detected faster if it were closed source? By what reasoning?
Face it: Open Source is no panacea.
Correct. It's not perfect. Its just the best solution available.
Re: (Score:2)
Face it: Open Source is no panacea.
Correct. It's not perfect. Its just the best solution available.
The problem is, some FOSSians seem to be deluded into thinking that it is the cure for all what ails-ya!
Jus' sayin'...
Re: (Score:2)
"The problem is, some FOSSians seem to be deluded into thinking that it is the cure for all what ails-ya!"
How is that at all different for proponents of close source products?
Wireless Access Points (Score:5, Informative)
According to the CVE, the attack was done by having the victim connect to a WiFi access point controlled by the attacker.
https://seclists.org/oss-sec/2... [seclists.org]
The victim device connects to the access point, which for most of our
testing was a laptop running create_ap. The victim device then
establishes a connection with their VPN provider.
So don't connect to a VPN when using an unknown access point, and you'll be fine! ;-)
Re: (Score:2)
Easier said than done.
You are at a coffee shop and you get the emergency call to fix something at work. Sometimes you need to use that guest wireless VPN to get what is needed.
Being that it is a Linux problem. Shouldn't we have a patch before this goes wild?
Re: (Score:3)
That last sentence was sarcasm :-)
Re: (Score:2)
And everyone knows best sarcasm is explained sarcasm. Thanks a lot!
Bullshit (Score:3)
Arguments for Secure Shell (Score:5, Interesting)
Re: (Score:2)
Secure Shell has had its security problems in the past as well.
Re: (Score:3)
This vulnerability has nothing to do with SSL or IPSEC. It has everything to do with the fact that Linux uses the Weak Host Model [wikipedia.org] by default.
Re: (Score:2)
Shell access does come with execution privileges, so basically you are allowing to run untrusted code locally. The first thing about system security is to control code execution. While you can restrict ssh user from code execution, it would be more comfortable for admins to have separate service that only allows tunnel without any code execution.
Wifi connection only? (Score:2)
Re: (Score:1)
Sounds like BS (Score:2)
But even then, I don't see how it can be used for the level of attacks described in the article. Guessing the connection triple and the sequence ID without some additional help is unfeasible.
Description of the flaw (Score:5, Informative)
The CVE is reserved and contains no description, butthis email details the flaw. [seclists.org]
Apparently, a device connected to a VPN will accept packets to the VPN tunnel IP address even when they are not received from the tunnel interface. This is why a malicious device in the same subnet (for example, the AP) may interfere with traffic, impersonating a fake source address. Also, this is impossible from outside the local subnet, since the router does not forward traffic to the tunnel IP.
Re: lol... systemd (Score:2)
Devuan (sysV init) and many BSD systems are also affected. See my previous comment above.
Re: (Score:2)
RTFA makes it clear that it's due to a conf change for systemd in 2018.
So, macOS and iOS (and presumably, iPadOS, watchOS and tvOS) shouldn't be affected.
They run Apple's launchd (which Apple created and released as Open Source). Not systemd. That's Pottering's abomination.
Confusing writeup & title (Score:5, Informative)
The real story is buried under a pile of confusing crap.
Basically what's going on, for linux, is this:
You have a NIC, say eth0, with IP 1.1.1.1 . You connect to a VPN and get a tun0 with IP 2.2.2.2 .
Here is the problem: Somebody who can send packets to your NIC (wifi, unswitched ethernet, arp-poisoned switched Ethernet) can send a packet destined for 2.2.2.2 to your eth0 and it will RESPOND back out eth0 as if it had come in tun0.
net.ipv4.conf.default.rp_filter = 1
should turn that off for ipv4. They claim this setting works for now but may not under further attacks, though I don't see what they're planning to do. They also recommend iptables rules to drop appropriately. I've configured my bsd routers this way forever and performance is fine there.
At this point, they know your IP and can do what sounds like a massively luck-required attack to figure out what the remote host is that you are talking to over the network and from there your current sequence number and from there do packet injection. Remember, they're injecting on your eth0 for the address on tun0. They are penetrating some of the security the VPN should be providing but they are *not* hijacking your VPN - they are guessing about the traffic tunneled inside of it.
A VPN's variable packet size helps narrow the scope of the latter attack, so if you're concerned then you should see if your VPN software allows packet padding so all packets are at your MTU size. That's slower and more secure; ideally they would also all be constant-time as well.
Another way to mitigate (Score:2)
Can you not also mitigate this by using a source routing rule saying that anything originating on your machine from the VPN address has to be routed via the VPN interface? That way, the RST when the attacker guesses the VPN IP address won't actually be received. Or, make the VPN interface the default route.
Re: (Score:3)
Replying to myself... we want Linux to use the Strong Host Model [stackexchange.com]
Adjacent network neighbor (Score:3)
Adjacent network neighbor? Really? You have to be on the same layer 2 network segment which in today's vintage of switching means you are the router or the transmission medium is 100% visible to you (as in a wireless connection OR you are an ISP of some kind). The script kiddy in the next room on his hardwired connection cannot see your packets anyway, so he's not a threat.
If you can sniff ALL the target's packets, you can surmise some of the meta details about the conversation taking place over a VPN connection. Wow, how's this a huge problem? It's not like you can decrypt the payload or inject your own properly encrypted payload. About all you can do with this is some DOS attack or maybe track who's talking to who and how much information they are passing.
I got to say, it's unlikely the attacker will get much in the way of useful information and I have a feeling that fixing this (because it seems to be configuration related) will be exceptionally quick. My recommendation is to watch for the soon to be released patches and update, in the mean time, don't worry too much about it.
Re: (Score:2)
Asking for a friend ^H^H^H^H an enemy.
Simple fix (Score:2)
Suppose your VPN interface is vpn0 and your VPN IP address is 10.0.8.1. Then this should fix it:
iptables -I INPUT --destination 10.0.8.1 -i \! vpn0 -j DROP
Re:Simple fix (Score:5, Interesting)
Ugh, I should have read the man page.
iptables -I INPUT --destination 10.0.8.1 \! -i vpn0 -j DROP
SystemD (once again) (Score:3)
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.
Who thought it would be a good idea to disable source route verification? Oh right, Poettering simply changed the default because NetworkManager doesn't know how to deal with multiple connections.
The vulnerability is also largely overblown. Yes, with rp_filter set to loose, you can infer some things and insert packets (although if you have that power, you would be able to see all traffic a host is generating, and infer a VPN anyway), but you can't read the data that's going out. At best you can insert some packets, but you can't get any data out. I can see some systems react to a packet where no established negotiation has been done (eg. web servers), but nothing 'special' should happen just because you send an anonymous request.
Who would have thought.. (Score:2)
that basing every operating system on the same base would lead to shared global vulnerabilities? Didn't people learn from the 90's? We need more OS diversity. And by that I do not mean linux, osx and bsd, but completely separate OSes that share no concepts (POSIX and libc anyone?) whatsoever.