[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0b9b495647cd4793e2ac882ce82b520c@breakpointingbad.com>
Date: Sun, 04 Jul 2021 20:33:30 -0700
From: vpn-research@...akpointingbad.com
To: oss-security@...ts.openwall.com
Subject: Re: Blind in/on-path attacks against VPN-tunneled connections
(CVE-2019-14899 follow-up)
Hi all,
I'm just circling back now that we have a virtual environment for you to
test.
This was produced as an artifact for our Usenix paper on this
vulnerability and the one covered by CVE-2019-14899. The included
virtual environment is for OpenVPN, but we have one for WireGuard and
StrongSwan as well that we can share upon request. I'll also provide a
link for the paper.
A CVE has still not been assigned for this issue, but it has been
submitted to MITRE.
https://git.breakpointingbad.com/Breakpointing-Bad-Public/vpn-attacks
https://www.usenix.org/system/files/sec21fall-tolley.pdf
Thanks,
Breakpointing Bad
-----------------
William J. Tolley
Beau Kujath
Jedidiah Crandall
On 2020-08-13 08:06, vpn-research@...akpointingbad.com wrote:
> Hi all,
>
> This is reporting a vulnerability that allows an in/on-path attacker
> between a VPN client and VPN server to infer and inject arbitrary data
> into VPN-tunneled connections. This vulnerability is related to
> CVE-2019-14899, but has a few key differences.
>
> - The attacker does not need to be the gateway or network adjacent, as
> described in CVE-2019-14899.
>
> - The packets are not being spoofed "outside" of the tunnel. In the
> previous attack, the packets were sent to the wireless/ethernet
> interface and were still being processed by the kernel despite coming
> from a non-VPN interface, in this attack we are not subverting the
> tunnel by sending packets to the incorrect interface, but sending
> packets to the VPN server with the source address of the endhost (such
> as a web server). Thus, for the VPN server, the spoofed packets that
> make it into the tunnel are identical to real packets from the
> endhost, and enter the VPN server from the same interface. For the
> VPN client, the spoofed packets are coming through the VPN tunnel from
> the VPN server.
>
> - Enabling rp_filtering on the client machine does not prevent this
> attack, and source address validation on the scale of the Internet
> doesn't really exist. Note that rp_filter on the server is
> irrelevant, since spoofed packets enter on the same interface as
> legitimate packets.
>
> - The VPN providers and operating systems affected by this attack is
> expanded to include policy-based VPNs and Windows etc.
>
> We reported this to disros@...openwall.org and security@...nel.org on
> July 29th, but have not yet received any responses from any vendors
> with a CVE pool. While related to CVE-2019-14899 in that we examine
> the timing and size of encrypted packets to infer information about
> packet headers, we believe this attack is significantly different and
> should be assigned a CVE and addressed since the previous mitigation
> does not prevent this attack.
>
> We have included our correspondence with distros and kernel security
> in the form of a FAQ on our blog here:
> https://breakpointingbad.com/2020/08/12/VPN-FAQ.html#faq.
>
> To prevent the cluster foxtrot of misinformation from the last
> disclosure, we request that anyone wanting to report on this contact
> us at vpn-research@...akpointingbad.com.
>
> William J. Tolley
> Beau Kujath
> Jedidiah R. Crandall
>
> Breakpointing Bad &
> Arizona State University
>
> ***********************************************
>
> This is a follow-up to our report on November 20th of last year
> detailing how connections inside a VPN tunnel could be inferred,
> reset, and in some cases, hijacked by injecting data into the TCP
> stream. We have expanded the attack by moving one or more hops away
> from the client to an in-path middle router between the client and VPN
> server. In our previous disclosure, a client-side mitigation using
> iptables or nftables was suggested, but we are unsure of how to
> prevent this new attack and do not believe there is a client-side
> solution.
>
> Our setup is as follows:
>
>
> vpn client ----- AP ----- router 1 ------ router 2 ----- vpn server
>
> \ /
>
> \ /
>
> \/
>
> router 3
>
> |
>
> website
>
> (If formatting is a problem:
> https://breakpointingbad.com/assets/virtlab.jpg)
>
>
> The VPN client and access point both have reverse path filtering
> enabled, and the client has an active connection to the website
> through the VPN server. The attack is performed from router 1,
> spoofing a packet that appears to be from the website to the VPN
> server. To infer a connection that the VPN client has made on the
> other end of the VPN tunnel, we spoof the packet coming from router 1
> with the source address and port of the website and the destination
> address of the VPN server. By searching the ephemeral port space for
> the last part of the 4-tuple, one of the spoofed packets will be NATed
> by the VPN server (if the connection exists) and seen in the VPN
> tunnel by router 1 (by looking at the size of encrypted packets going
> from VPN server to VPN client).
>
> Unlike the previous attack from the perspective of the gateway, or an
> adjacent user, we do not need to know the virtual IP assigned to the
> client. However, as with the previous attack, the attacker must
> already know the IP address that they anticipate the victim will
> connect to using the VPN. But testing a site is trivial, especially
> if we limit the scope to a targeted attack from nation state testing
> against a banned list, for example.
>
> We have tested this in a limited, virtual environment, but we are
> starting our effort to test this on the “real internet”, where we will
> need to account for packet loss, packet reordering, and packet delay,
> but in many ways this attack is an easier attack than the original
> that led to CVE-2019-14899 since it removes some of the most
> time-consuming elements of the previous attack.
>
> We have tested this against OpenVPN, WireGuard, and StrongSwan. We
> selected these since they are the most commonly used commercial VPN
> platforms. It was suggested by Noel Kuntze in the previous thread that
> the old attack wouldn’t work against policy-based VPNs, such as IPSec
> using StrongSwan, so we included it in this effort to demonstrate how
> the new attack does not depend on anything particular to the network
> stack or VPN implementation of the client. We have only tested
> inferring that a TCP connection exists up to this point, but it should
> be possible to reset or hijack that TCP connection in a manner similar
> to the original attack since we can spoof packets into the tunnel at
> the VPN server end. Again, this works regardless of the VPN client’s
> configuration, OS, etc.
>
> We are still developing other attacks using this method, including
> attacks on DNS similar to those suggested by Colm MacCárthaigh. By
> using a DoS attack to have the DNS server ignore DNS requests from the
> VPN server, we can guess the source port as above and then search as
> much of the TXID space as possible within the timeout period of the
> DNS request. We have successfully hijacked VPN-tunneled DNS requests,
> and are working on speeding up our attacks to make it more likely to
> work for any given request.
>
> Just to summarize and put both forms of attack (spoofing to the VPN
> client from a network adjacent position vs. spoofing to the VPN server
> from any router on the path from VPN client to VPN server) into
> perspective:
>
> -We’re still able to infer the existence of VPN-tunneled TCP
> connections, and potentially RST and hijack them, regardless of VPN
> client OS or anything the VPN client has done to patch against
> CVE-2019-14899.
>
> -We note that TLS does not protect against inferring and resetting
> connections in general, and our ability to hijack DNS requests also
> means that TLS encryption alone will not protect a TCP connection.
> VPNs are supposed to protect the integrity of tunneled traffic
> independently of application-layer protections (such as TLS). Our work
> shows that they do not.
>
> -Attacking by spoofing packets to the VPN server instead of the VPN
> client changes the threat model to be not only attackers that are
> network adjacent to the VPN client, but also attackers that are
> in/on-path between the VPN client and VPN server (e.g., the routers
> that route packets between them).
>
> We also want to point out that the target audience for this disclosure
> is kernel developers and others familiar with network stack
> implementations and the details of how VPN routing works. As with the
> first disclosure we plan to follow list policy and make the disclosure
> public after 14 days. Our last disclosure was misinterpreted by many
> media outlets and podcasters, so we’d like to point out that anybody
> with questions about the disclosure can email
> vpn-research@...akpointingbad.com and we’ll be happy to answer what
> questions we can.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
