Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Following on from CRIME, now we have BREACH to be presented at Black Hat in Las Vegas Thursday (today). From the linked article, it suggests that this attack against compression will not be as simple to turn off as was done to deter CRIME. What can be done to mitigate this latest assault against HTTP?

EDIT: The presenters of BREACH have put up a website with further details. The listed mitigations are:

  • Disabling HTTP compression
  • Separating secrets from user input
  • Randomizing secrets per request
  • Masking secrets
  • Protecting vulnerable pages with CSRF
  • Length hiding
  • Rate-limiting requests

(note - also edited title and original question to clarify this attack is against HTTP which may be encrypted, not HTTPS specifically)

share|improve this question
12  
See also Is HTTP compression safe? which has some analysis of this kind of attack. Security.SE got there first - 11 months before Black Hat. Go, team us! –  D.W. Aug 2 '13 at 18:42

4 Answers 4

up vote 31 down vote accepted

Though the article is not full of details, we can infer a few things:

  • Attack uses compression with the same general principle as CRIME: the attacker can make a target system compress a sequence of characters which includes both a secret value (that the attacker tries to guess) and some characters that the attacker can choose. That's a chosen plaintext attack. The compressed length will depend on whether the attacker's string "looks like" the secret or not. The compressed length leaks through SSL encryption, because encryption hides contents, not length.

  • The article specifically speaks of "any secret that's [...] located in the body". So we are talking about HTTP-level compression, not SSL-level compression. HTTP compression applies on the request body only, not the header. So secrets in the header, in particular cookie values, are safe from that one.

  • Since there are "probe requests", then the attack requires some malicious code in the client browser; the attacker must also observe the encrypted bytes on the network, and coordinate both elements. This is the same setup as for CRIME and BEAST.

  • It is unclear (from the article alone, which is all I have right now to discuss on) whether the compressed body is one from the client or from the server. "Probe request" are certainly sent by the client (on behalf of the attacker) but responses from the server may include part of that which is sent in the request, so the "chosen plaintext attack" can work both ways.

In any case, "BREACH" looks like an attack methodology which needs to be adapted to the specific case of a target site. In that sense, it is not new at all; it was already "well-known" that compression leaks information and there was no reason to believe that HTTP-level compression was magically immune. Heck, it was discussed right here last year. It is a good thing, however, that some people go the extra mile to show working demonstrations because otherwise flaws would never be fixed. For instance, padding oracle attacks against CBC had been described and even prototyped in 2002, but it took an actual demo against ASP in 2010 to convince Microsoft that the danger was real. Similarly for BEAST in 2011 (the need for unpredictable IV for CBC mode was known since 2002 as well) and CRIME in 2012; BREACH is more "CRIME II": one more layer of pedagogy to strike down the unbelievers.

Unfortunately, a lot of people will get it wrong and believe it to be an attack against SSL, which it is not. It has nothing to do with SSL, really. It is an attack which forces an information leak through a low-bandwidth data channel, the data length, that SSL has never covered, and never claimed to cover.

The one-line executive summary is that thou shalt not compress.

share|improve this answer
5  
thou shalt not compress secrets. Modern javascript frameworks like angularjs can beautifully work around this issue by separating presentation and data. Compress the presentation, not the (sensitive) data. –  user239558 Aug 2 '13 at 19:31
    
Is it me or does the attack seem stupid? If the attacker can inject code into your browser using a https page wouldn't this attack be the least of your worries? –  acidzombie24 Aug 6 '13 at 17:38
1  
The idea is that the attacker can inject his Javascript in a HTTP page from another site, and the Javascript then proceeds to make your browser send requests to the target HTTPS server. Because of the Same Origin Policy, the Javascript cannot send arbitrary requests to the target HTTPS site (in particular no POST), but it can send basic GET requests by manipulating the DOM and adding some <img> tags. –  Thomas Pornin Aug 6 '13 at 17:44
    
Several corrections: the breachattack.com site has the paper. The paper has full details. The attack works on and compressed, encrypted data, not just http or http compression, so long as the secret is consistent and the attacker gets multiple tests. Systems other than browsers are vulnerable. Breach targets the server's response, where crime/beast targeted the client request. They're the same attack, otherwise. Breach can attack header secrets if tls compression is enabled. –  atk Aug 22 '13 at 2:23
    
"... then proceeds to make your browser send requests to the target HTTPS server" - And now we have POODLE... Yet another CSRF that the browser cannot seem to contain even though CSRF is in its anecdotal security model. The W3C should just move CSRF out of its security model because it does such a poor job of defending against it (that seems to be standard fair: if it can't be addressed (like Protected Storage for WebCrypto), just drop it from the model). –  jww Dec 8 at 6:32

BREACH, like CRIME, is a compression-related attack. Turning off compression makes the attack impossible.

ADDED
Note that in this case it appears that you turn off a different compression configuration; whereas CRIME exploits TLS-layer compression, BREACH exploits HTTP-layer compression.

share|improve this answer
1  
I'm having a hard time digging through the ranting and hyperbole, but it seems BREACH relies on HTTP compression rather than TLS compression, so it's different. –  mr.spuratic Aug 1 '13 at 23:19
    
@mr.spuratic So the compression is done in Apache rather than... Apache. Yeah, it's different, but not so different that it can't be dealt with. –  tylerl Aug 1 '13 at 23:43

The attack works by inferring info from the payload size. Artificially padding served HTTPS pages (e.g. a randomly sized comment string) could mitigate its effectiveness.

share|improve this answer
4  
This isn't actually that much of a mitigation; you can simply collect more packets and the variation(s) will become statistically significant. Obviously, this can be an impediment and slow down an attacker, but it doesn't stop the attack. The proper fix is to close the side-channel (stop compression). –  Tinned_Tuna Aug 2 '13 at 10:15
    
That's a good point. While it'd certainly make it harder, it'd still be an issue. –  Max David Aug 5 '13 at 18:58

I just thought of a way to add "Randomizing secrets per request", "Length hiding", and "Rate-limiting requests" to a CSRF mitigation measure.

  1. Consider which forms you wouldn't want an attacker to POST on the user's behalf. These are the forms you'd protect from CSRF.
  2. For each page view, generate a random salt of random length. Send this salt as a hidden input. The random length should help add noise to lengths, even if your front-end load balancer strips comments or otherwise minifies your HTML.
  3. Compute a hash of the salt, the session ID, and a server-side secret, and send this CSRF key as another hidden input.
  4. Optionally log the salt or CSRF key to a table. This allows for rate limiting a particular user account or IP address to a number of hashes per hour and for limiting replays of a particular salt.
  5. When you process the form, compute the hash in the same way as the previous steps, using the salt in the form, and make sure it matches the CSRF key.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.