Tricky VPN-busting bug lurks in iOS, Android, Linux distros, macOS, FreeBSD, OpenBSD, say university eggheads

A bug in the way Unix-flavored systems handle TCP connections could put VPN users at risk of having their encrypted traffic hijacked, it is claimed. The University of New Mexico team of William Tolley, Beau Kujath, and Jedidiah Crandall this week said they've discovered CVE-2019-14899, a security weakness they report to be …

[Anonymous Coward]

All hail systemd

"Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year which turned reverse path filtering off"

Let me be the first to say that I gladly submit to our new systemd overlords, who know better than us what the network settings on our systems should be.

All hateil systemd!

[Halfmad]

Re: All hail systemd

Just move over to Windows 10. I mean the 'nix fanboys invade every Windows based article bashing it - might as well return the favour here.

Come on Billy Gates fans, get the cardigan buttoned up and get in here to bash 'nix for some bug that wil affect a tiny percentage of the user base.

[CAPS LOCK]

You are, the now flounced, JJ Carter, unfunny and unlamented Microsoft shill...

...I claim my five pounds...

[Danny Boyd]

Re: All hail systemd

Please receive an upvote. It is not every day we can see such pure and unabated trolling. Pure marvel. Good job!

[Blockchain commentard]

If they've already access to your network, you're compromised anyway, regardless of how you access it.

[katrinab]

But VPN is sold as a magic bullet for making you secure on untrusted networks.

[ibmalone]

What I'm missing, not being a networking expert, is how this allows them to inject arbitrary data, it surely still needs to be correctly encrypted? I'd thought VPN would use symmetric encryption, so unless there's a flaw in the encryption scheme too you'd have to be able to fake the server's signature for that exchange?

[Phil O'Sophical]

If you can inject it into the local network of the system, and that system is configured to forward packets (which may be the default if it has multiple interfaces), the routing software will kindly forward it to the VPN device for you. It'll be encrypted on the way just like a local packet. This is presumably what the reverse path filtering would have mitigated.

[ibmalone]

Thanks. I suppose that means you could trick the VPN device into encrypting something routed back to itself as if it was supposed to be outgoing? Does seem like rather a design flaw.

[Anonymous Coward]

"Does seem like rather a design flaw."

It's a design flaw if you wish to use the VPN to protect your host and the remote systems you are accessing although you should also have a firewall running to protect you if that is the case. The firewall would also provide a workaround if you were concerned.

It's a design feature if you wish to route traffic through your "VPN server" for other hosts on your network.

[ibmalone]

Although surely being happy to immediately unencrypt something it just encrypted and directed back to itself is still a problem? In either scenario you'd hope traffic originating from the interface had actually crossed the connection.

[NATTtrash]

No VPN expert remark here too: The focus seems to go to the traffic itself. But I can come up with multiple "interested parties" though that would be extremely interested with just the (real) IP of some VPN users. And it looks like this could provide it (without that local network access)? Will go back to dunces corner if I'm rambling...

[Anonymous Coward]

Re: If they've already access to your network, you're compromised anyway

The key term here is "network adjacent" - i.e. sitting on the same subnet as the client device such as in an airport, cafe or other public space.

In addition, it only affects route-based VPN's - policy-based VPN's are unaffected which should significantly reduce the likelihood of corporate vendors being affected.

More details here: https://seclists.org/oss-sec/2019/q4/123

This looks like a poorly validated setting change (i.e. net.ipv4.conf.all.rp_filter=0) combined with an operational feature rather than a genuine security bug - I suspect the real fix is to ensure future VPN software correctly validates that the source device is allowed to send traffic to the remote end when configured in routed-based modes and defaults to local host addresses only.

[Drew Scriver]

Hotels, conference centers, coffee shops, libraries, airports, trains, and buses.

All places where people routinely use a VPN to connect their corporate laptop to the office - because it's considered very secure.

This flaw could turn out to be a very, very serious problem.

[Wellyboot]

Security layers

So to mitigate this particular problem the local network (at both ends of VPN) has to be secured which poses a problem for coffee shop & airport dwellers.

Nesting VPNs would probably be a workaround unless the method used here can be used to drill down through the layers.

[Ben Tasker]

Re: Security layers

> Nesting VPNs would probably be a workaround unless the method used here can be used to drill down through the layers.

Because of the way it works, that wouldn't help you much either.

If you have the following interfaces on your system

tun0 10.10.10.10

eth0 192.168.1.10

Where tun0 is the VPN virtual interface and eth0 is your physical NIC.

The way this works is that the attacker sends SYN-ACKs towards your eth0 with the dest IP in the packet header being for 10.10.10.1 then .2, then .3 to see what responses it gets. Eventually when it reaches 10.10.10.10 it'll get a response - a RST packet.

They now know what the IP of your tun0 is, and can start the rest of their process.

If you nest your VPNs the way most people do, you'll just end up having tun0 and tun1. You may buy some time if they stumble on the IP of tun0 first and try and inject using that, but the process isn't too different if they find tun1 (though the extra padding of having another tunnelled connection might throw them off).

The article didn't mention it, but Amazon Linux followed up with an interesting use of this attack where (with some effort) an attacker could use this to spoof DNS responses from a "trusted" DNS server at the other end of the tunnel

[W.S.Gosset]

Or to put it another way

You can tuna fish but you can't tun0 anon.

[TrumpSlurp the Troll]

Puzzled as usual

As already asked more or less, is this an attack against a VPN endpoint such a router or firewall which provides a service to devices working in clear on the local LAN?

Such as might be used to securely link two LAN segments together?

Then again in that scenario you would see the traffic in the clear on the local LAN.

So still confused as to how you inject clear text traffic into a conversation you can only view as encrypted.

[DontFeedTheTrolls]

Re: Puzzled as usual

"As already asked more or less, is this an attack against a VPN endpoint such a router or firewall which provides a service to devices working in clear on the local LAN?"

Since the article states it is "Linux distros, along with Android, iOS, macOS, FreeBSD, and OpenBSD" I'd say it very much is the end user device that is the critical and vulnerable item. That may also included routers and firewalls built on one of said *nix OSs, but that is not the primary target.

[Anonymous Coward]

Re: Puzzled as usual

"As already asked more or less, is this an attack against a VPN endpoint such a router or firewall which provides a service to devices working in clear on the local LAN?"

To carry out the attack:

- the target must be on a BSD/Linux device with reverse path filtering disabled

- the target must be using route-based VPN's rather than policy-based VPN's

- the attacker must share a layer-2 network with a target network interface that is not intended to route traffic over the VPN (i.e. not the "inside" of a site-to-site VPN)

- no other network level filters must be present (i.e. peer-to-peer blocking on Wifi or private VLAN's on Ethernet)

[Anonymous Coward]

Scan the entire RFC1918 address space

Part of the attack involves scanning the entirety of RFC 1918 address space to find out the virtual IP address in use by the victim. That is quite a lot of addresses - 10/8, 172.16/12 and 192.168/16. According to https://seclists.org/oss-sec/2019/q4/122 the default in OpenVPN is 10.8.0/24. All the implementations I've used of OpenVPN have no default, perhaps their appliance uses that range, idk.

So the mitigation for now are switch on reverse path again if it is off unless you use asymmetric routing and look out for a bombardment of IP scanning and block the source. Snort/Suricata and OSSEC may warrant investigation.

Reading on they next determine where you are headed by guessing which could involve yet more bombarding of your machine. Then ports are determined by probing all 65000 ports.

I'm filing this under "a bit worrying but very unlikely". It certainly does not lend itself to automated attacks.

[Anonymous Coward]

Meh

Much ado about nothing, really. Here's the proof from the

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.

Running Linux Mint 19.2, and the rp_filter setting is still at the default of 1, not 0. The take away isn't that we're all vulnerable. It's that we need to check and put a workaround in place.

[Mike 16]

BSD Stacks?

IIRC, the original official MSFT stack (not the various third-party add-ons and TSRs) was based on the BSD networking code.

Is this still true? More importantly, have they tracked bugs introduced in later BSD stacks and "ported" them to the MSFT stack? Or have they introduced their own, different, bugs?

[david 12]

Re: BSD Stacks?

But it's not a 'network stack' problem. It's a routing problem.

[YetAnotherJoeBlow]

config changes

I am so sick and tired of software that changes my configurations without telling me - I do things in there for a reason. I can not begin to count how many times vendors make those changes - and by people who should know better. It is just part of the new era apparently, I call it arrogance. Technically, that action is quasi illegal - modifying a computer system without authorization ...

[whitepines]

Re: config changes

While I 100% agree with the sentiment here, the simple fact is that on most *nix systems *you* decide to upgrade -- if you don't check your configs after the upgrade, shame on you, not the vendor.

Now as for Windows 10, the line is getting really blurry with the forced updates that Microsoft is in fact modifying existing computer systems without authorization. Yes, the EULA probably grants permission, but it's a fine line.

[jtaylor]

Re: config changes

I am so sick and tired of software that changes my configurations without telling me - I do things in there for a reason.

There's no simple solution. Configurations are "correct" only in the context where that decision was made. When that context changes, often the "correct" configuration must change too. There are already ways to insert yourself into that decision loop. If you aren't doing that, then you're also not ready to make the decisions.

On a practical node, If I install software or enable (or disable) a feature, it's not reasonable for me to manually find and troubleshoot every fiddly OS setting to make it work. And then maybe discover that my configuration has weird problems because it was never expected or tested by the software developers.

"Okay," you might say, "software can play with the default settings, but leave the ones I explicitly changed!" What about the settings that you explicitly left at the default? What about interactions between settings?