OpenVPN Vulnerability

[SMS786]

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.

https://www.tomsguide.com/us/vpn-voracle-attack-defcon26,news-27784.html

https://www.bleepingcomputer.com/ne...k-can-recover-http-data-from-vpn-connections/

This attack was revealed at DEF CON last week. Apparently protecting against this vulnerability is as easy as disabling compression on our OVPN servers?

@RMerlin, do you have any recommendations?

 

[RMerlin]

@RMerlin, do you have any recommendations?

Nothing more than what's already said in the article: avoid using LZO compression. Most of today's Internet data can't be compressed any further anyway (either it's encrypted, or it's jpeg/mp3/mp4/zip).

It's another one of these "security exploits" over which I won't be losing any sleep, personally... Likelyhood of this being actively exploited in the wild against generic/random victims is next to nil.

 

[SMS786]

Nothing more than what's already said in the article: avoid using LZO compression. Most of today's Internet data can't be compressed any further anyway (either it's encrypted, or it's jpeg/mp3/mp4/zip).

It's another one of these "security exploits" over which I won't be losing any sleep, personally... Likelyhood of this being actively exploited in the wild against generic/random victims is next to nil.

Got it, thanks much for the clarification!

 

[netware5]

LZ4 compression is much better and faster. Does the above vulnerability affects the LZ4 also?
And second question is: Does setting of tls-crypt option helps in such circumstances?
And finally third question: What about TAP configurations when the OpenVPN encapsulates not IP packets but Ethernet frames?

 

[joe scian]

LZ4 compression is much better and faster. Does the above vulnerability affects the LZ4 also?
And second question is: Does setting of tls-crypt option helps in such circumstances?
And finally third question: What about TAP configurations when the OpenVPN encapsulates not IP packets but Ethernet frames?

since the VORACLE attack report refers to compression only and makes no distinction between LZO , adaptive or LZ4 then you can assume that LZ4 is included.

 

[Wadadli]

https://nordvpn.com/blog/voracle-attack/

 

[DonnyJohnny]

https://nordvpn.com/blog/voracle-attack/

Looking at the requirements needed to complete that Attack..
it is not easily to hack.

1. They need to be on the same network as you;
2. You need to be using an HTTP connection;
3. You need to be using a browser vulnerable to VORACLE (anything but Chrome);
4. You need to visit a website that the hacker controls;
5. You need to be using OpenVPN with compression engaged.

The only chance will only be if you using a unknown wifi hotspot and they used a http log-in page. Otherwise, the chance is very Low.

But I think turning off the compression is a good way to totally prevent things from happening.

 

[58chev]

Set compression to "NONE" or "DISABLE" ?

 

[M@rco]

Set compression to "NONE" or "DISABLE" ?

Here's some clarification on both options:

OpenVPN's LZO settings are highly confusing... It can be set to "no", and it can be set to "disabled", both of which are different. One will instruct the other end you don't want to use compression right now, without disabling the feature itself. The other will completely disable the feature.

You have unfortunately to match what the server requires, in most cases.

I use 'Disabled' for the VPN Server running on my router. My VPN provider (and several others) have completely disabled compression as well (source: https://protonvpn.com/blog/voracle-attack/), so regardless what a client requests, it won't offer any compression on negotiating.

 

[LouisvilleUK]

This link should help and provides good info...
https://community.openvpn.net/openvpn/wiki/VORACLE

Granted, still in "draft" phase.

 

[M@rco]

@RMerlin Would it be possible to set the Compression value to 'Disable' by default?

Unrelated to Voracle, but would you please consider setting "Username / Password Auth. Only" to 'No' by default? @Martineau pointed out yesterday that 'Yes' is less secure. For people with less knowledge, like yours truly, I think setting ('the most') secure options by default would definitely come in handy.

 

[RMerlin]

@RMerlin Would it be possible to set the Compression value to 'Disable' by default?

Worth considering, tho personally I'm not losing any sleep over that particular issue since the issue is more likely to affect you when you are using a client to access the Internet, not when using it just to connect remotely into your home network. Therefore that makes it far more critical for all those VPN tunnel providers whose sole purpose is to let you redirect your traffic through them.

Unrelated to Voracle, but would you please consider setting "Username / Password Auth. Only" to 'No' by default? @Martineau pointed out yesterday that 'Yes' is less secure. For people with less knowledge, like yours truly, I think setting ('the most') secure options by default would definitely come in handy.

Less does not mean it's insecure, just like your home doorlock is less secure than one used on a store or a bank, or AES-128-GCM is less secure than AES-256-GCM. The learning curve to deal with generating your own client certificates is far too steep for the vast majority of users, so I have no intention of changing the default settings.

EDIT: actually, the reasons for this default choice are historical. My original implementation didn't generate a client key/cert pair, it had to be done manually by the end user. Afterward Asus implemented the functionality to automatically generate a key/cert pair for the client. I just rechecked that code, and I see they are automatically used in the exported client config file now, therefore it should be possible to change the default to not be username/password only. That wasn't the case back then.

 

[58chev]

Here's some clarification on both options:

I use 'Disabled' for the VPN Server running on my router. My VPN provider (and several others) have completely disabled compression as well (source: https://protonvpn.com/blog/voracle-attack/), so regardless what a client requests, it won't offer any compression on negotiating.

Thank you M@rco for the clarification.

 

[TheStork]

So just to check: is the compression option ‘None’ also safe from this exploit?

On my OpenVPN server setup it seems that ‘Disabled’ kills access for the clients (they connect but cannot access anything), while ‘None’ seems to work. I’d prefer to not have to reissue all client configs...

 

[SMS786]

So just to check: is the compression option ‘None’ also safe from this exploit?

On my OpenVPN server setup it seems that ‘Disabled’ kills access for the clients (they connect but cannot access anything), while ‘None’ seems to work. I’d prefer to not have to reissue all client configs...

I had a similar predicament. After "Disabling" compression on my server I had to delete the following line from my config files:

comp-lzo XXXXX

The connections worked fine afterwards.

As to having the "None" option being as secure as "Disabled" - I can't speak to that..but I would definitely err on the side of caution.