Apple, Google and Linux distribution makers are investigating a serious threat to their operating systems after security researchers said last week a vulnerability could allow an attacker to intercept traffic in a virtual private network.
Discovered by a team from the University of New Mexico, the researchers said an attacker able to get into an access point, or an adjacent user, could determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgment 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,” the researchers said in a blog.
“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.”
The vulnerability has been reported to Systemd, Google, Apple, OpenVPN, and WireGuard, in addition to Linux distros. Researchers haven’t yet published a detailed paper on their findings because neither a workaround nor patches have yet been issued.
In the meantime they do suggest three mitigations to IT administrators:
1. Turn Linux reverse path filtering on. Many Linux distributions turned it off 12 months ago with the inclusion of a new version of systemd. Most of the distributions tested were vulnerable, particularly those with the new version. However, researchers also admitted the attack works against IPv6, so turning reverse path filtering on isn’t reasonable.
Also, even with reverse path filtering on strict mode the first two parts of the attack can be completed, allowing an attacker to make inferences about active connections.
2. Filter traffic for bogus IP addresses called bogons. According to Wikipedia, bogons include IP packets on the public internet that contain addresses that are not in any range allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated regional Internet registry (RIR) and allowed for public Internet use.
However, the researchers say, local network addresses used for VPNs and local networks, and some nations, including Iran, use the reserved private IP space as part of the public space.
3. VPN makers could encrypt packet size and timing. Since the size and number of packets allow the attacker to bypass the encryption provided by the VPN service, the researchers think some sort of padding could be added to the encrypted packets to make them the same size. Also, since the challenge ACK per-process limit allows us to determine if the encrypted packets are challenge ACKs, allowing the host to respond with equivalent-sized packets after exhausting this limit could prevent the attacker from making this inference.
In a blog Colm MacCárthaigh, who works for AWS and helps develop Amazon Linux and the company’s VPN products, noted that his company’s products are not impacted by the vulnerability.
However, he described the attack method as “very impressive” and has warned that it can pose an even more serious threat if combined with DNS spoofing.
“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,” MacCárthaigh wrote. “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.”
So far the following are vulnerable to this type of attack:
- Ubuntu 19.10 (systemd)
- Fedora (systemd)
- Debian 10.2 (systemd)
- Arch 2019.05 (systemd)
- Manjaro 18.1.1 (systemd)
- Devuan (sysV init)
- MX Linux 19 (Mepis+antiX)
- Void Linux (runit)
- Slackware 14.2 (rc.d)
- Deepin (rc.d)
- FreeBSD (rc.d)
- OpenBSD (rc.d)
