Jump to content

Linux users beware - VPn connections vulnerable to hijack


sman

Recommended Posts

CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections.

"https://seclists.org/oss-sec/2019/q4/122"


From: "William J. Tolley" <william () breakpointingbad com>
Date: Wed, 04 Dec 2019 19:37:07 -0700
Hi all,

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

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. However, we
recently discovered that the attack also works against IPv6, so turning
reverse path filtering on isn't a reasonable solution, but this was how
we discovered that the attack worked on Linux.

Adding a prerouting rule to drop packets destined for the client's
virtual IP address is effective on some systems, but I have only tested
this on my machines (Manjaro 5.3.12-1, Ubuntu 19.10 5.3.0-23). This
rule was proposed by Jason Donenfeld, and an analagous rule on the
output chain was proposed by Ruoyu "Fish" Wang of ASU. We have some
concerns that inferences can still be made using slightly different
methods, but this suggestion does prevent this particular attack.

There are other potential solutions being considered by the kernel
maintainers, but I can't speak to their current status. I will provide
updates as I receive them.

I have attached the original disclosure I provided to 
distros () vs openwall org and security () kernel org below, with at least
one critical correction: I orignally listed CentOS as being vulnerable
to the attack, but this was incorrect, at least regarding IPv4. We
didn't know the attack worked against IPv6 at the time we tested
CentOS, and I haven't been able to test it yet.


William J. Tolley
Beau Kujath
Jedidiah R. Crandall

Breakpointing Bad &
University of New Mexico


*************************************************


**General Disclosure:

We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS,
iOS, and Android which allows a malicious access point, or an adjacent
user,  to determine if a connected user is using a VPN, make positive
inferences about the websites they are visiting, and determine the
correct sequence and acknowledgement numbers in use, allowing the bad
actor to inject data into the TCP stream. This provides everything that
is needed for an attacker to hijack active connections inside the VPN
tunnel.

This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec,
but has not been thoroughly tested against tor, but we believe it is
not vulnerable since it operates in a SOCKS layer and includes
authentication and encryption that happens in userspace. It should be
noted, however, that the VPN technology used does not seem to matter
and we are able to make all of our inferences even though the responses
from the victim are encrypted, using the size of the packets and number
of packets sent (in the case of challenge ACKs, for example) to
determine what kind of packets are being sent through the encrypted VPN
tunnel.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.