Date: Thu, 13 Aug 2020 08:06:50 -0700 From: vpn-research@...akpointingbad.com To: oss-security@...ts.openwall.com Subject: Blind in/on-path attacks against VPN-tunneled connections (CVE-2019-14899 follow-up) 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.