How to Make a VPN Give Up Its Secrets
UPDATED 4:00 p.m. EDT Monday with clarification from the researcher.
LAS VEGAS — The security of many well-known virtual private network (VPN) services can be broken by a relatively simple attack that reveals temporary VPN session keys in less than a minute, the attack's developer revealed at the DEF CON 26 hacker conference here Saturday (Aug. 11).
Ahamed Nafeez said his VORACLE attack works against VPN services that use the highly regarded OpenVPN protocol (or similar protocols) by default and also compress user data before encryption. One service, TunnelBear, stopped compressing data after it was informed of Nafeez's attack earlier this summer. (Another VPN service, Private Internet Access, contacted Tom's Guide after this story was first posted to say it had stopped compressing data in 2014.)
You can avoid falling victim to the VORACLE attack by switching to other VPN protocols, such as IKEv2/IPsec or WireGuard, if your VPN service lets you. For technical reasons, Google Chrome is immune to the VORACLE attack, as are HTTPS websites, but everyone's computer still has many other internet-facing applications that communicate with plaintext HTTP servers. However, this problem wouldn’t exist if all websites used HTTPS encryption.
"It's time everything moves to HTTPS," Nafeez said. "There's really no excuse for any website not to use it anymore."
How the Attack Works
Nafeez's VORACLE attack is an extension of earlier proof-of-concept attacks against the Transport Layer Security (TLS) protocol used by HTTPS-enabled websites. These attacks — CRIME in 2012 and TIME and BREACH in 2013 — leverage the fact that adding known bits of data to partly or wholly secret data before the data is compressed and encrypted can reveal the secret data, and thus the encrypted key for that secure communication session — the "session cookie."
Because most compression algorithms reduce the size of files or data packets by removing duplicate piece of data, an attacker who continually added small but variable bits of known data of the same size to larger quantities of secret data could watch for changes in the size of the resulting encrypted packages.
Closely matching the size of the encrypted packages (which you can do with free traffic-analysis tools such as WireShark) to what was known to have been added would let the attacker deduce what the secret data (in this case, the session cookie) might be.
So if the attacker added the known text string "fish" to a larger packet of secret data before all the data was compressed and encrypted, and the resulting encrypted package was four characters or so smaller than the previous one, then the attacker would know that "fish" appeared at least once in the secret data.
On the other hand, if adding the four-letter text string "eggs" didn't change the size of the encrypted packet, then the attacker would know that "eggs" was not part of the secret data.
The attacker would then use computer automation to rapidly run though combinations of text strings — which can comprise numbers as well as letters — until he or she had "cracked" the secret text.
Because of this, web browsers and other internet-facing applications changed how they handled encrypted HTTPS data in 2012 and 2013.
But those updates didn't fix the problem in the OpenVPN protocol, which also uses TLS. Nor did it solve how compression acted upon unencrypted HTTP as opposed to encrypted HTTPS traffic.
As a result, if HTTP traffic is compressed and encrypted by a VPN service, then an attacker can monitor the stream of encrypted traffic between the target's browser and the VPN server. (This doesn't work with data that is already encrypted before the VPN compresses and encrypts it again.)
The attacker would also need to lure the target's browser (via malicious ads, for example) to an HTTP website that the attacker controls. (Setting up a simple website on rented server space is cheap and easy.) That website would be how the attacker could add variable bits of data to the encrypted stream of data traveling between the target's browser and the VPN service.
If you're the attacker, and you automate this process, you can figure out session keys pretty quickly. During his presentation, Nafeez ran a live demonstration that decrypted a seven-digit, secret OpenVPN session cookie in less than a minute.
Nafeez could have then taken over the legitimate user's account for the rest of the VPN session, until the attacker or the VPN service closed out the session. Depending on the kind of account security the VPN service had, the attacker might have also been able to change the password on the VPN account and capture it permanently, or at least until the legitimate account holder complained.
Nafeez explained that work was being done by web-standards bodies to adjust compression algorithms so that VORACLE attacks would no longer be possible. But until then happens, he said, VPN services should stop compressing data, as TunnelBear did, even if it means a hit on performance.
Nafeez's presentation slides are available on the DEF CON media server.
[UPDATE: An earlier version of this story said it was encryption keys, not session keys, that could be stolen in this attack. The researcher reached out to Tom's Guide to clear up that misunderstanding, and to emphasize that the VPN services that use OpenVPN software he named in his presentation were only meant to show how widespread OpenVPN usage is. He did not mean to imply that specific services were vulnerable to the VORACLE attack. We have removed the names of those services from this story.]