Deconstructing the BREACH attack

Print Friendly, PDF & Email

The Internet is abuzz with discussion on the latest “SSL attack” – BREACH – released last week at Black Hat USA. While the attack is not really an attack of SSL per se, the fact that one can sniff secrets inside of HTTPS gives off that impression to many folks.

The attack is meant to steal “secrets” from HTTPS response bodies that are compressed, using HTTP layer compression (gzip, deflate). It’s a side-channel attack that targets HTTP compression and not SSL/TLS compression. The latter was targeted as part of the CRIME attack last year and is resolved by disabling TLS compression, which already was not widely supported by browsers and servers. However, HTTP response compression is very popular.

Prerequisites for the Attack:

  1. A user input that is reflected in the attack
  2. A secret that is present in the response body (not headers) such as CSRF tokens, or other PII
  3. And the response compressed
  4. Attacker should be able to view the victim's encrypted traffic (e.g. via arp spoofing or unsecured wifi).
  5. Attacker should be able to send requests on behalf of the victim (e.g. using social engineering to get the victim on an attacker-controlled malicious site)

What is the root cause?

There are two key insights to understanding this attack. One, compression ratio (using deflate, etc.) is proportional to the amount of character repetition. For example, in the following two lines, the first one would compress more, as “sec” is repetitive.

secret and secretary
secret and boss

As a result, the size of the compressed payload will be smaller for the top line. Of course, the compressed payload would be the smallest when you try to compress:

secret and secret

The second important observation is that while SSL is great at hiding content, it really doesn't prevent the size of the content from leaking information. The size of the encrypted data is proportional to the size of the input plaintext.

Now assume that “secret” is actually a word that should be guarded and appears in the HTTPS response body. You, as a hacker, can inject a string into the response context, prior to compression. So you can begin with injecting a,b,c …, and when you reach s, you will notice that the compressed and encrypted response has a smaller length. You now have guessed s, the first character of the text that should have been confidential. Similarly, you would proceed to guess the remaining characters.

As you can imagine, if the attacker has the liberty of injecting random strings (e.g. via URL parameters) that are reflected in the compressed response body (such as secretary and boss above), she can progressively refine her guess by monitoring some of the HTTPS response body.

This is a classic example of a chosen-plaintext attack.

How bad is it?

HTTP compression is quite popular, especially in modern rich client web applications that rely heavily on JSON, XML, stylesheets etc. However, when you see the list of pre-conditions required for the attack, i.e. the attacker needs to be on the same network and needs to make you visit a controlled malicious site and should be able to see the encrypted responses, etc., the probability of an attack is low, in our opinion.

Moreover, it intends to steal secrets in the HTTP responses. Besides CSRF tokens, there is precious little that is present in HTTP responses these days (credit card numbers normally are masked out and passwords are not echoed in responses).

That said, for mission-critical applications, security is always better than ignorance.

What can you do?

The Barracuda Web Application Firewall has many ways of mitigating such an attack, without changing any code or altering web server configuration:

#1: Aggressive CSRF Protection:

If you have CSRF Prevention turned on for Forms and URLs, you already are secured, since it prevents the attacker to send either GET or POST requests on your behalf. As noted in the original paper:

3.6. More Aggressive CSRF Protection. An important feature of the attack is its reliance on the ability to coerce the victim to issue requests that elicit certain responses. In the example of OWA, the requests are simple GET requests that don't change state on the server. Until now, it has not been considered necessary to protect these requests from CSRF attacks. Furthermore, making such a change would be a significant retrofit for many web applications. However, we remark that requiring a valid CSRF token for all requests that reflect user input would defeat the attack.

#2 Request Rate Limiting via Brute Force Control

Set up Bruteforce rules to rate control the HTTP requests. For example, deny an IP address from sending more than 50 requests in 60 seconds:


#3 Forcing HTTP Compression Off

Since the attack relies on HTTP compression, disable it by creating a Web Address Translation rules that drops the request header: Accept-Encoding: gzip, deflate

The last approach will provide security but possibly at the expense of performance (data transfer speed over slow networks). Since this will depend on a site-to-site basis, customers should evaluate how much they are affected by disabling compression, if at all.

Questions or comments? Connect with us on Facebook, LinkedIn, Twitter or Google +.


Scroll to top