Blind in/on-path attacks against VPN-tunneled connections (CVE-2019-14899 follow-up)

[vpn-research () breakpointingbad com]

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 () vs openwall org and security () kernel 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 () breakpointingbad 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 () breakpointingbad com and we’ll be happy to answer what 
questions we can.