New VORACLE Attack Can Recover HTTP Data From Some VPN Connections (bleepingcomputer.com)

"A new attack named VORACLE can recover HTTP traffic sent via encrypted VPN connections under certain conditions," reports Bleeping Computer, citing research presented last week at the Black Hat and DEF CON security conferences. An anonymous reader writes: The conditions are that the VPN service/client uses the OpenVPN protocol and that the VPN app compresses the HTTP traffic before it encrypts it using TLS. To make matters worse, the OpenVPN protocol compresses all data by default before sending it via the VPN tunnel. At least one VPN provider, TunnelBear, has now updated its client to turn off the compression. [UPDATE: ExpressVPN has since also disabled compression to prevent VORACLE attacks.]

HTTPS traffic is safe, and only HTTP data sent via the VPN under these conditions can be recovered. Users can also stay safe by switching to another VPN protocol if their VPN client suppports multiple tunneling technologies.
In response to the security researcher's report, the OpenVPN project "has decided to add a more explicit warning in its documentation regarding the dangers of using pre-encryption compression."

Comments

This suggests a serious weakness.

[BitterOak]

A good encryption algorithm should be able to protect any data, regardless of whether or not it is compressed. If compressing data before encryption renders the encryption algorithm insecure, I would suggest the algorithm was weak to begin with. Perhaps better, newer algorithms are needed. I'd be wary of a solution that just says "turn off compression and you'll be fine."

Re:This suggests a serious weakness.

[lsllll]

A good encryption algorithm should be able to protect any data, regardless of whether or not it is compressed. If compressing data before encryption renders the encryption algorithm insecure, I would suggest the algorithm was weak to begin with. Perhaps better, newer algorithms are needed. I'd be wary of a solution that just says "turn off compression and you'll be fine."

Huh? Neither algorithm is weak. Did you watch the slides? Each do their own thing well. This is a genius attack, in that it can brute force things like session cookies, passwords, etc.

In a way it reminds me of SQL attacks that try to find table names by going through alphanumeric and underscores one character at a time until they get the whole table name and then do whatever they want once they have the table names.

Re: This suggests a serious weakness.

[Anonymous Coward]

Iâ(TM)m way out of my league here, but the summary didnâ(TM)t make sense to me.

Canâ(TM)t say I understood the article either ... made me think this is some kind of browser/user attack and nothing to do with the encryption or protocol (alone).

Re: This suggests a serious weakness.

[lsllll]

It didn't click for me until slide #70. Here's the link to the slides.

Re: This suggests a serious weakness.

[Anonymous Coward]

I assume you're joking because that link only displays giant oversized emojis and comments for me (probably because my noscript blocks cloudfront and twitter on that site).

Fwiw, the linked article says that they're using the length of the compressed data to extract information. I assume that means they're brute-forcing and attempting to spot when the compressed size goes down = they guessed a prefix that matched something else on the page.

Re:This suggests a serious weakness.

[chill]

You're not understanding the attack. It isn't an attack on the encryption itself, but rather taking advantage of the fact that compression happens first and being able to inject some data. By injecting some data that is then compressed, and observing the change in resultant size, they can infer certain things about the encrypted payload.

For example, if the plain text is "AAAABCDEF" a simple compression tool would turn that into "4ABCDEF" before encrypting. The size changed from 9 bytes to 7.

If you can inject AAA and make it "AAAAAAABCDEF" which then compresses to "7ABCDEF", the size of the resulting encrypted string goes from 12 to 7.

Both the 7 byte streams are perfectly encrypted, but I could now infer that multiple As are part of the plaintext.

Yes, this takes the ability to inject data, hence luring to a compromised site. Yes, it takes a LOT of packets to do this, and it really only works on things like web cookies, which are 4K maximum and much smaller in practice.

But is has nothing to do with the quality of the encryption algorithm.

Re:This suggests a serious weakness.

[BitterOak]

Okay, I think I understand what you're saying, but it sounds like this could only happen if there is a very badly designed system which appends data from an untrusted source to data from a trusted source and compresses them together. It would seem a trivial fix would be to start the compression algorithm fresh whenever the source of the data changes.

Re:This suggests a serious weakness.

[chill]

It does rely on the ability of the bad guy to inject data and observe the change. Really only plain text stuff going thru a VPN, which almost always means HTTP.

Chrome is immune to this, as it splits the header and body of plain requests into separate packets. Firefox sends them in the same packet, so it is not a mitigation. Safari, IE, Opera, Edge, etc. aren't mentioned in the slides.

A fix would be to simple not compress header fields and only compress body data. A quick fix is to just toggle off compression in the OpenVPN client. This was fixed in HTTP for CRIME and it'll get fixed here. Considering how many websites have migrated to HTTPS-only, I'm not worried.

Re: This suggests a serious weakness.

[Anonymous Coward]

Same as CRIME, basically.

Re:This suggests a serious weakness.

[robbak]

No, this is unavoidable if you compress and encrypt. If you do this, you will leak information about your encrypted data through the size of the cyphertext.

The solution is just to never compress data that you are going to encrypt. You might be able to obfusticate matters by padding the compressed data to a standard size, but that only makes the task a little difficult - for instance, you could adjust the size of the compressed payload so your fiddling pushes it across the threshold to the next larger standard size.

Re:This suggests a serious weakness.

[AHuxley]

Find a brand that has fixed their VPN service.

Re:This suggests a serious weakness.

[MrL0G1C]

FTA:
"According to Nafeez, all an attacker needs to do is to lure a user on an HTTP site. This site can be under his control, or a legitimate site where the attacker can execute malicious code â"for example, via malvertising (malicious ads).

This allows the attacker to steal and decrypt "secrets" from that site, such as session cookies, which, in turn, let the hacker log into that website as the user."

Doesn't sound like much to worry about to me, the hacker can only get data from sites under their control or that they have ads on. Not blocking ads yet?

Re: This suggests a serious weakness.

[guruevi]

Hence why in encryption, we typically pad the data stream to a fixed size regardless of input packet size. Yes, this kind of undermines the practicality of weaker (fast) compression but itâ(TM)s more secure. These kinds of attacks have been known about for quite a while and standard test questions in any encryption course.

Re:This suggests a serious weakness.

[johannesg]

If it really works like you describe it's a pretty far-fetched attack method though: the site must already be compromised, but not in a way that allows the attacker to simply read the messages to begin with. The likelyhood of that set of circumstances is about zero.

Re: This suggests a serious weakness.

[Anonymous Coward]

The real reasons why people use VPNs (or should use VPNs) is to prevent insecure communication. VORACLE does not impact HTTP sites behind a VPN, which is what I would bet the old majority of slashdot readers would be concerned about.

Re:This suggests a serious weakness.

[DarkOx]

What you don't understand is that you just described virtually every web page. This is essentially the same attacks that worked on SSL3.0 and TLS1.0 when compression was enabled.

The reason it works is that the attacker has access to 99% (roughly) of the plain text. Lets say I want to discover you bank routing number on a web page. As the attacker I register myself and discover the size and all the non-dynamic content on the page. I can inject my own content say a short string of numeric characters and compress the data. I can than observe the change in size.

Now if I am observing your network traffic and I know what site your pulling say based on the IP address. I can sit and look at the transfer size. When I see a server response the same size as one of my candidate compression tests; I now know at least one possible value for the dynamic content.

Its not a problem with the encryption algorithm. The message would not be recoverable unless I already knew almost all of it. Without thousands of cipher texts I can even begin to work out the change content. TLS address this by padding the responses with a little random length data.The trouble is the plain protocol has no padding and the VPN does not either. This can be fixed easily but its going to have a negative performance impact.

Re:This suggests a serious weakness.

[chill]

Well, I over-simplified. The *site* doesn't have to be compromised, thanks to the way the web works. Injected elements in something like ad rotation will do it. The attacker just has to have SOME way of injecting data into the stream.

But, yes, it is a pretty unlikely scenario.

Re: This suggests a serious weakness.

[lsllll]

VORACLE does not impact HTTP sites behind a VPN

Technically, you're right. It doesn't impact the HTTP site necessarily, but once it gathers the user's credentials to the site, then it has an elevated status on the site and then who knows what?

which is what I would bet the old majority of slashdot readers would be concerned about.

I would think you're wrong. Majority of Slashdot users don't give a shit about the health and safety of the web site they're visiting, but they do care about their own information falling in the wrong hands.

Re: This suggests a serious weakness.

[Agripa]

So the attack is a browser application that loads so much trash that it produces a denial of service via resource exhaustion?

Re:This suggests a serious weakness.

[Anonymous Coward]

you think this is uncommon?

You aren't safe either way

[Anonymous Coward]

Even if VPN was perfect your ISP and your VPN's ISP can still deanonymize you even if the VPN doesn't keep logs.

Re:You aren't safe either way

[darkain]

VPNs are more than just anonymnizing services. They are literally "virtual private networks" - used very commonly for either remote workers in corporate environments or for linking multiple building's private LANs together over public WAN.

Re: You aren't safe either way

[Anonymous Coward]

OK, like I didn't know that. However those VPNs are not VPN service you sign up for. They are custom, self hosted VPN.

The VPNs people sign up for are for anonymizing traffic. And it doesn't really work, and no because of this flaw. You already know your ISP knows all of your connections, they just need to play ball with the VPN's ISP and see what connections correlate with that time.

Re:You aren't safe either way

[Anonymous Coward]

I'm sure someone will be around any minute to tell us how hosts files can save the day.

Compression after Encryption isn't a good idea

[Anonymous Coward]

Good encryption makes data look like unstructured noise, which isn't compressible. Also, the longer the message, the more a target there is for statistical attacks. This shouldn't be about compression, this should really be about how people should be using IPSec or other stack agnostic VPN solutions rather than the already known to be insecure OpenVPN which leeks metadata like a sieve.

Not particularly worried here

[whoever57]

"According to Nafeez, all an attacker needs to do is to lure a user on an HTTP site. This site can be under his control, or a legitimate site where the attacker can execute malicious code â"for example, via malvertising (malicious ads).

This allows the attacker to steal and decrypt "secrets" from that site, such as session cookies, which, in turn, let the hacker log into that website as the user."

If I understand this correctly, the user has to visit a http: site under the control of the attacker and then the attacker can grab secrets associated with that site?

Re:Not particularly worried here

[lsllll]

All the attacker needs is to be able to inject something into the communication stream, pre-compression, and be able to monitor the length of the packets being sent back and forth. Over time, given that the same information is being sent over and over (think cookies), the attacker can then brute force the contents.

Re:Not particularly worried here

[Anonymous Coward]

This could theoretically be used to then send malicious code BACK to the hacker, compromising his/her system and opening them up to a reverse attack.

Re:Not particularly worried here

[complete loony]

Javascript can easily trigger GET & POST requests for other domains. Add a test sequence to the url or post body while a MITM attack is watching the compressed size of the packets. If it compresses better the test sequence must appear somewhere else in the request bytes sent to the server. See also BREACH & CRIME.

Re:Not particularly worried here

[whoever57]

Javascript can easily trigger GET & POST requests for other domains.

So that means that to attack, I must:
1. Lure someone to a http endpoint that I control.
2. Be able to watch the encrypted traffic.

So, basically, the answer is to bypass the VPN for http endpoints. You should not be sending or receiving anything secure to http websites anyway.

Re:Not particularly worried here

[complete loony]

The biggest target here would be http intranet applications, accessed over VPN's.

Re:Not particularly worried here

[Anonymous Coward]

It works well in the sense you can do a warmer/colder. You don't strictly have to be able to inject data but without that and knowing something about the candidate protocol/data being sent under the hood then you're going to have an extremely hard time, if at all possible.

Attacks based on reading packet sizes and possibly timings as well aren't unknown or some revelation. They're normally not that easily exploitable though. Things like block size are sometimes used to mitigate this. It's very difficult because you've also got bandwidth and latency to worry about.

Even without compression size and timing of packets is, albeit very minor, always an information leak. If you listen to traffic and chart these you will see non-random patterns. This wont let you discern much but in some case you might be able to work out what types of services someone is using and possibly even which website they are browsing (and some hint of first visits). You can try this yourself. Choose two sites. Visit one ten times in a row. Monitor the throughput pattern. Do the same for the other. Chances are between two sites you'll be able to discern some difference.

The reason it's not often a concern is because it's in the very fringe of usefulness and exploitability. The extreme solution is to constantly transmit at some rate.

The extent of the problem may also depend on how you structure your underlying data. The problem with some processes is that they compress everything. Excluding sensitive information from compression will mitigate such attacks but also means you have to do it per protocol running through the tunnel. Secure information is usually sent in a way that doesn't lend well to compression anyway (which makes this attack easier).

It's my hack.

[Anonymous Coward]

To compress 100 Gigazeros to few KB and sent this compressed data to TLS.

how realistic is this?

[hazard]

It seems that the attack requires the victim to load the same page many times, in order to measure differences in packet length? In real life, how often one visits the same page (and this page doesn't change)? If I understand this correctly, the attack will be very slow in real life, apart from some specific cases where user visits a website which reloads itself continuously.

Also, in this day and age, would anyone trust authenticated sites which do not use https? These sites themselves are the main problem.

Re:how realistic is this?

[Anonymous Coward]

A malicious ad can just issue 256 async page requests and wait for them all to return, and then choose the one with the shortest payload as the next letter of the password (because it compresses better). It repeats that 8x, and then it has your password before you even notice that it was using bandwidth.

Re: how realistic is this?

[Anonymous Coward]

It seems that the attack requires the victim to load the same page many times, in order to measure differences in packet length? In real life, how often one visits the same page

Most web pages now contain the same boilerplate code before the page-proper. They also generally send the same cookies over and over again.

It seems that visiting many pages on the same site would leave one open to this attack just as well as visiting the same page over and over.

But its fairly trivial to deanonynise a vpn user with correlation and timing analysis just by looking at both sides of the stream.

Not sure this attack is as helpful as some claim. Being able to recover some data (that you could already slurp on it's non-encrypted ingress to the vpn server) seems like non-news to me.

Being able to exploit compression to target encryption isn't really news either.

The combination is more useful in suring up your correlation attacks- if you can manipulate the input traffic and see a predictable change in output traffic you can be pretty confident of input -> output path through the black-box vpn server

But it's already long been known that you can (and should) prevent this type of attack with fixed length encrypted packets padded with noise.

Re:how realistic is this?

[AHuxley]

The security services are getting into and around VPN products.
Bullrun (decryption program) https://en.wikipedia.org/wiki/...
The security services like collect/to exfiltrate/coerce private keys. Then its just real time collection. US brands offering pre-encryption access to police/US gov/mil.
ie getting both ways in with Key Provisioning, Key Recovery. The other method is just to create and approve junk crypto with the US gov/mil as the only "creator" under the cover of cybersecurity best practice. The result is weak junk crypto in use as a standard.

Re:how realistic is this?

[hazard]

You mean it is possible to force loading of the parent URL from cross-domain child? I was under impression that it won't work without specific code to support that on the parent side.

Re: how realistic is this?

[hazard]

They would send the same cookies - but packet length would be different also, so as I understand you'd need to open each URL at least twice to make one brute force attempt.

I agree that if attacker is already sitting in the middle of your traffic, and moreover can direct you to his malicious site, there are a lot of other attack vectors to worry about.

Get a better news source

[Anonymous Coward]

Headline. Followed by the same sentence again. Then "bleepingcomputer". Already, I've been swindled out of more time than the article is going to be worth.

Get A Better News Source.

And get us some decent editors while at it. The current crop just doesn't cut it.

Well Sure

[Anonymous Coward]

But to do that, you'd have to build a GUI firewall using VisualBasic. Where the fuck are you going to find a VB programmer in this day and age. Programmers are all using C# and Python now and couldn't program their way out of a wet paper bag unless someone builds a wet paper bag framework for them.

So, good luck with your reverse attack.

A note in the documentation? Seriously?

[Anonymous Coward]

Hey guys, let's not fix the problem or anything, just put a note in the documentation that it's broken. That'll solve the problem. I'm going to start doing this with all my projects. Those aren't bugs, RTFM.

AirVPN has had compression disabled for a while

[nawcom]

My AirVPN configs have had "comp-lzo no" in it since I've been using them so no worries about that. Looking up more info, it seems some of the AirVPN ovpn files generated for specific devices have it enabled because it would otherwise not work on that device (eh what?), but they still have lzo compression disabled on their server end so it is not used regardless.

Source for this info: https://airvpn.org/topic/29036...

Re:AirVPN has had compression disabled for a while

[nawcom]

And I'll just add that it's annoying that on neither TFA or on this /. post is the actual setting comp-lzo specifically mentioned. You have to interpret the patch diff linked in TFA.

To disable lzo compression, make sure "comp-lzo no" is included in the config as mentioned in my parent post.

That's a bummer, but it isn't the important thing

[Anonymous Coward]

What's really important is that my penis is happy. It is covered in peanut butter and sprinkles, and the aardvark will soon be here.

L2TP

[Anonymous Coward]

Is the way to go. OpenVPN is too open.

Why not just add a random length chaffe?

[goombah99]

If the encryption process added a random length null message to the encrypted packet and also to the compression as well, it seems like this threat would become prohibitively difficult. However I don't fully understand it. It seems like the attacker has to have to send repeats of the same message over and over with slight mods. I don't see how that's possible practically. But adding random length chaffe to the message would multiply the effort required so much it probably become impossible to learn anything from the compressed message length.

Re:Why not just add a random length chaffe?

[lsllll]

If the encryption process added a random length null message to the encrypted packet and also to the compression as well, it seems like this threat would become prohibitively difficult..

Interesting. Yes, that would make this much more difficult, but it would have to be of sufficient length (maybe up to 50 characters?) and it need be added to either/or, not both. You're just hoping that the variable end would suffice.

Close call

[Anonymous Coward]

Wow. Started reading this and was legit scared, but then came to the part where ExpressVPN has already disabled compression and I instantly feel better. This...this is why I have no problem paying for a VPN.