Inferring and hijacking VPN-tunneled TCP connections

jedisct1 | 320 points

Disclaimer: I work at AWS, on Amazon Linux and our VPN products; those aren't impacted by this issue.

The attack that the researchers describe is very impressive, and using traffic analysis and error messages to find the details of an open TCP connection is extremely clever.

Unfortunately a similar approach can be used even more practically to target DNS on the VPN: https://www.openwall.com/lists/oss-security/2019/12/05/3

Encrypted DNS queries and replies can be profiled by traffic analysis, and the reply "paused", making it easier to ensure that a DNS spoofing attempt will succeed. This is a good reminder that cryptographic protections are best done end to end; DNSSEC does not help with this attack, because it does not protect traffic between the stub resolver and the resolver. It's also a good reminder that traffic analysis is still the most effective threat against network encryption.

colmmacc | 4 years ago

"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."

Anybody happen to know why systemd decided this was something they should be messing with?

mondoshawan | 4 years ago

Sorry if I seem stupid but what are the security implications ?

As far as I understood the attacker can :

- Detect an active VPN connection (and maybe close it/monitor it)

- Attempt to inject packets : for this part I am skeptical of the usefulness. The connection between the server and the client are normally encrypted, meaning that the injected packets will be dropped or can be used to forcefully close the connection making it a DoS attack.

mirages | 4 years ago

> This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec

> It should be noted, however, that the VPN technology used does not seem to matter

I was wondering which VPNs, but after reading it seems that it doesn’t matter the VPN but is instead a kernel bug? I wonder if this also affects a host that has two network interfaces, with no VPN involved whatsoever?

Also, it’s good to see Jason Donenfeld involved, which many will likely recognize as the author of Wireguard.

hamandcheese | 4 years ago

> The access point can then determine the virtual IP of the victim by sending SYN-ACK packets to the victim device across the entire virtual IP space (the default for OpenVPN is 10.8.0.0/24).

So, would a bit of address space randomization mitigate step one for ipv6? fd00::/8 is pretty big, right? Even just picking a random IP in a random /64 from that /8 should help? Or am I missing something?

Also interesting comments in the reply on the list regarding "policy based" vpns. I wonder if some subset of that infrastructure could be used by Wireguard without completing it all the way out of its current nice and secure-by-simplicity design?

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

> Only route based VPNs are impacted. In comparison, policy based VPNs are not impacted (On Linux only implementable using XFRM, which is IPsec on Linux specific) unless the XFRM policy's level is set to "use" instead of "required" (default)) because any traffic received that matches a policy (IPsec security policy) and that is not protected is dropped.

e12e | 4 years ago

> I am reporting a vulnerability that exists on most Linux distros, and other *nix operating systems which 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.

I'm not sure that I understand exactly what "network adjacent attacker" means. But I'm guessing that it means an attacker on the same subnet. And that it doesn't involve actually hacking VPN encryption.

But isn't it well understood that sharing LANs with untrusted neighbors is hugely risky? At least, I always segregate critical machines in protected subnets.

Or am I missing something?

Edit: OK, I was missing that this focuses on using VPNs via WiFi APs. And depends on the AP being malicious. So yeah, this is a huge issue, for that use case.

mirimir | 4 years ago

Huh, I wonder how the OpenBSD team will regard this one.

I'm unfamiliar with exactly how to tell what's in the base system and what's in ports, but I can see openvpn* entries over at http://ftp.openbsd.org/pub/OpenBSD/6.6/packages/amd64/ - does that mean there's arguably a hole in the base distro?

In any case, nice work.

Question. Besides randomizing packet lengths (preferably with minimum and maximum tunables (per each packet type) that each site can change, to further add entropy), what else can be done to mitigate against this family of attack?

Asking as someone interested in developing "ubiquitous secure container" type protocols that are application- and use-case-specific but (theoretically) high-stakes.

exikyut | 4 years ago

I just can't understand how this attack can be implemented in real world, it not only needs having an adjacent network access to the VPN client but most importantly knowing the destination of a currently open TCP connection encrypted by the VPN and then guessing the right sequence numbers. Since most TCP connections are also carrying TLS these days, this attack is pretty useless in the vast majority of real world situations I can think of.

nif2ee | 4 years ago

> nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.8 -- rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12

Why is Linux accepting packets coming from one interface into an IP address belonging to a different interface? It feels like it is "forwarding" the packets internally, but `ip_forward` is turned off.

Is there any case where this behavior is legitimately useful?

arielb1 | 4 years ago

It seems for the attacker to find out about active connections to any given website they have to already know the IP of the website and then brute force the virtual ports. Being able to determine what website the target has an active connection to without prior knowledge would probably take even more brute forcing. A small solice.

knolax | 4 years ago

Correct me if I am wrong, but...

If I just make sure that incomming packets that are destined for the VPN LAN are dropped, this attack does not work?

Of course there are such rules in our firewalls??

Is everyone walking around without any firewall filtering nowadays? How is this a bug? Maybe I am just stupid. Did I miss something?

derpherpsson | 4 years ago

Disseminating vulnerabilities like these to less savvy people should be a critical imparitive for the next century. I imagine a team of animators at a non-profit or foundation that illustrate how these attacks work at different levels of technical backgrounds.

Gabrielfair | 4 years ago

I'm having trouble understanding why the randomly sprayed bits from the attacker to the client are even accepted at all at the crypto boundary. Shouldn't it hard-fail (not decrypt) due to an invalid key?

GhettoMaestro | 4 years ago

Is this mitigated by iptables filter firewall? For example, FORWARD policy DROP and no other rules?

ufov2 | 4 years ago

Someone know if there is some kind of pronouncement by distros implicated?

joseluisq | 4 years ago

Can we merge these? I posted this 10 hours earlier here: https://news.ycombinator.com/item?id=21709693

tinix | 4 years ago

"We discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android..."

What about NetBSD.

This also appears to be wireless only, i.e., the need for attacker to have control over the AP. Am I reading this wrong.

3xblah | 4 years ago

@

GMLOOKO | 4 years ago

This doesn't seem nearly as bad as 'hijacking' implies.

> The attacker can now inject arbitrary payloads into the ongoing encrypted connection using the inferred ACK and next sequence number.

First, it's hard to get to this point. Then, you're injecting garbage because you don't know the payload encryption keys. So it's just disruptive, even though yes technically it is 'hijacking'.

Unless I missed something, of course! I found the writeup to be vague on the payload encryption point. It should have explicitly stated the impact one way or the other.

jiveturkey | 4 years ago