LWN: Comments on "VPN hijacking on Linux (and beyond) systems"

VPN hijacking on Linux (and beyond) systems

Cyberax — Tue, 10 Dec 2019 20:16:47 +0000

It's #2. The attacker won't be able to decrypt the packets, but they can (blindly)inject their code into a TCP stream.

VPN hijacking on Linux (and beyond) systems

jmclnx — Tue, 10 Dec 2019 14:36:43 +0000

I am trying to understand the term "adjacent user".

Does that mean:
1. Another user on your local system ?
OR
2. Someone on a different device connected to the same router as you are ?

For # 2, I was under the impression the VPN encrypted on your local device, so I am not sure what would be seen except for your own IP (as others said). Which can be an issue for some folks.

Thanks
John

VPN hijacking on Linux (and beyond) systems

nim-nim — Tue, 10 Dec 2019 11:10:01 +0000

But, wouldn’t that break horribly in presence of virtual things (vm or containers) on the same host?

All of those run firewalls.

NFV means dedicated firewall hardware will eventually too

VPN hijacking on Linux (and beyond) systems

hmh — Mon, 09 Dec 2019 18:19:56 +0000

Well, unicast reverse path filtering (uRPF) is geared towards no-config filtering of *source address spoofing* based on routing information. It was designed for hardware routers with extremely fast routing engines and far less capable packet filters, and where you care far more about packets that are just passing through.

uRPF drops packets trying to come from an interface when the reverse path (the reply path, as defined by a destination route lookup on the *source* of the packet) would NOT go through that interface -- in strict mode. It costs one extra route lookup per packet.

It is *NOT* the correct tool to address the weak host model. It will leave chinks in the armor, related to tricks with the destination addresses, and the way L2 and L3 addressing are independent in IP over ethernet. It might even twart this particular attack, but it will not in any way address the whole thing. You are strongly advised to fix the real problem, instead.

On Linux, right now, this requires iptables/nftables, since one cannot tell the kernel to configure itself for the strong host model with a single knob. BTW, uRPF for IPv6 is only available through iptables/nftables...

Oh, and one likely need to configure the damn ARP response and filtering behavior too, to keep L2 and L3 consistent.

For a strong host model, you want the firewall to drop anything incoming from an interface (*other than lo*) that is destined to the local address of a different interface. Also, anything outgoing with a *local* source address that does not belong to that interface should be rejected (again, lo should be exempt if you don't want to go insane).

Forwarding is easier to get right, and most stuff already does so... provided no local addresses are involved (see above).

VPN hijacking on Linux (and beyond) systems

Cyberax — Mon, 09 Dec 2019 17:51:29 +0000

> So you hijeck the TCP session, but what do you do with it?
Inject malicious JavaScript, for example. You do need plain HTTP for that, though.

VPN hijacking on Linux (and beyond) systems

Matlib — Mon, 09 Dec 2019 17:26:52 +0000

Yes, I should have carefully read the whole report, which indeed only mentions injection (whether or not this is realistic over a real VPN connection with modern TCP/IP stack). I was misled by some news telling about some cathastrophic "connection hijacking in Linux", "all VPN vulnerable" etc.

VPN hijacking on Linux (and beyond) systems

ncultra — Mon, 09 Dec 2019 17:12:33 +0000

Leaking IP addresses when (initializing or) using a VPN can be a serious issue for some VPN users; that is an important issue to discuss but not new. Hence Tor initializing the VPN connection in a different manner.

VPN hijacking on Linux (and beyond) systems

bahner — Mon, 09 Dec 2019 16:18:07 +0000

I am so not getting this. I get that it's possible to infer ack and seq numbers and inject packages into the TCP stream, but is that more than a dos-attack? So you hijeck the TCP session, but what do you do with it?
You will still need the secrets to decrypt the VPN-traffic, right?

So as I understand a potential nuisance, and leak off information in the form of IP-addresses. But you need access to the gateway/ access point in the local network of the client.

So I see a problem that needs to fixed, but I can't see any real impact for this problem.

VPN hijacking on Linux (and beyond) systems

dskoll — Mon, 09 Dec 2019 16:10:40 +0000

It wasn't my intention to be dismissive or sarcastic. Really! It just seemed to me the announcement was a little bit breathless.

They have pointed out something useful, which is that Linux is a pain in the neck to configure to use the Strong Host Model. I would love to see a simple knob that lets you choose between Weak and Strong model, with Strong being the default.

VPN hijacking on Linux (and beyond) systems

ncultra — Mon, 09 Dec 2019 13:12:24 +0000

If you pad the sequence packets its impossible for their method of guessing sequence numbers to work.

VPN hijacking on Linux (and beyond) systems

if.gnu.linux — Mon, 09 Dec 2019 09:23:51 +0000

Hi all,

I am a little confused about what to do to mitigate this vulnerability for a system which does not use VPN, because I am just an "average Joe" user. Is using "net.ipv*.conf.all.rp_filter=1" enough to mitigate it? Or, beside this kernel parameter, do I need to wait a kernel patch?

P.S.: My native language is not English.

VPN hijacking on Linux (and beyond) systems

Cyberax — Sun, 08 Dec 2019 18:40:09 +0000

> It is not possible to take over a TCP connection from some other network using a different IP address.
It most certainly is possible, if you are able to somehow guess the sequence numbers (and a couple of other parameters). You will not _get_ the traffic that is intended for the true remote host, but you will be able to inject your own data.

This is called the "Mitnick attack".

VPN hijacking on Linux (and beyond) systems

flussence — Sun, 08 Dec 2019 18:39:34 +0000

Looks like OpenBSD fixed it already: https://marc.info/?l=openbsd-tech&m=157580561114203&...

VPN hijacking on Linux (and beyond) systems

Matlib — Sun, 08 Dec 2019 12:55:38 +0000

It is not possible to take over a TCP connection from some other network using a different IP address. A VPN connection is just another network interface from the TCP/IP point of view.

It can be done using some sort of man-in-the-middle attack (including ARP cache poisoning), but this is not what he's trying to do here.

VPN hijacking on Linux (and beyond) systems

Cyberax — Sun, 08 Dec 2019 09:59:33 +0000

You are way too dismissive. If you read the actual post, you'll find that they discovered a way to find out the sequence number and ports. This allows them to actually take over the connection, without bothering about the true remote host.

This can be used, for example, to inject malicious JavaScript into unencrypted connections.

Old-timers might remember this as "the Mitnick attack": http://wiki.cas.mcmaster.ca/index.php/The_Mitnick_attack

VPN hijacking on Linux (and beyond) systems

tpo — Sun, 08 Dec 2019 09:19:31 +0000

I think it's counterproductive to dismiss the OPs' finding or to be sarcastic.

The "Weak Host Model" might be a known weakness. However apparently its security consequences are not well and widely known, as the OPs demonstrate by successfully attacking real world VPN setups. Therefore I think it's a laudable service by the OPs to go through the whole effort and to present their findings to the community.

The effect of dismissing the OPs' findings and of being sarcastic is that readers with their scarce attention might infer that this is old and known and thus not attention worthy which I think is not correct: this might very well be a wide spread problem that affects many users.

VPN hijacking on Linux (and beyond) systems

Matlib — Sun, 08 Dec 2019 00:03:36 +0000

That's part of the story. He's just discovered how IP works.

The other part – about hijacking – makes no sense as TCP connections are identified by port numbers and IP addresses for both ends of the connection (10.8.0.1 and 10.8.0.8 in that example).

VPN hijacking on Linux (and beyond) systems

rudis — Sat, 07 Dec 2019 14:11:27 +0000

AFAICS yes. My experiments with dropping them in INPUT prevented any response from the host. But that doesn't help with other protocols like UDP.

VPN hijacking on Linux (and beyond) systems

fest3er — Sat, 07 Dec 2019 05:19:34 +0000

WRT Linux (and netfilter), isn't a SYN-ACK without an outstanding SYN (as tracked by conntrack) an INVALID packet? If so, will dropping INVALID packets in PREROUTING significantly mitigate this problem?

VPN hijacking on Linux (and beyond) systems

zx2c4 — Fri, 06 Dec 2019 22:47:50 +0000

The related WireGuard mailing list thread can be found here: https://lore.kernel.org/wireguard/20191205191318.GA44156@zx2c4.com/

I'm interested in nice workarounds that don't require netfilter and can be applied and removed ad-hoc, but so far no luck. For example, network namespaces are excellent, but involve moving the netns of the physical interfaces, which isn't super feasible unless you're in a place of controlling the entire network stack (such as NetworkManager or something), which our little bash script, wg-quick(8), is not.

Alternatively, it might be nice to add a per-interface sysctl to enforce a strong host model for the owned IPs and routes of a particular interface. Discussion is ongoing.

VPN hijacking on Linux (and beyond) systems

dskoll — Fri, 06 Dec 2019 17:02:44 +0000

Congratulations. They have re-discovered the weakness in the Weak Host Model

And here's how to fix:

iptables -I INPUT --destination $VPN_ADDR \! -i $VPN_INTERFACE -j DROP

VPN hijacking on Linux (and beyond) systems

ncultra — Fri, 06 Dec 2019 16:44:16 +0000

pretty clear from just the first two responses on the oss-security list that they should have sought more peer review before publishing the letter and their statement "We have prepared a paper for publication concerning this vulnerability and the related implications, but intend to keep it embargoed until we have found a satisfactory workaround." does not engender confidence. What, exactly, are they embargoing, when the details of the "vulnerability" are in the letter? One response points out several workarounds that exist and are established practices, that this really has nothing to do with systemd, and explains why TOR is not effected (the authors seem puzzled as to why TOR is not effected). Another response shows that dns spoofing is a more effective and reliable way of hijacking connections, so there is nothing new here.