The security of many well-known virtual private network (VPN) services can be broken by a relatively simple attack that reveals temporary data encryption keys in less than a minute, the attack’s developer revealed at the DEF CON 26 hacker conference in Las Vegas on 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. In other words – yet another OpenVPN bug has been discovered. These providers include NordVPN, PureVPN, Hotspot Shield, ExpressVPN and Private Internet Access. One service, TunnelBear, stopped compressing data after it was informed of Nafeez’s attack earlier this summer.
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 (hint – Hidden Router only uses WireGuard). 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.”
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 encryption 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 encryption 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 decrypted all the HTTP data traveling on that OpenVPN connection until the user (himself, in this case) closed out the session.
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, VPNs should stop compressing data, as TunnelBear already had, even if it means a hit on performance.
If you want to steer away from any potential OpenVPN bugs – you can always grab a Hidden WiFi VPN Router from our store, and enjoy WireGuard at its best, while surfing with speeds of over 200Mbps!
Nafeez’s presentation slides are available on the DEF CON media server.
Source: Toms Guide