SSL, GONE IN 30 SECONDS

History

SEP

2012

At ekoparty 2012, Thai Duong and Juliano Rizzo announced CRIME, a compression side-channel attack against HTTPS. An attacker with the ability to:

• Inject partial chosen plaintext into a victim's requests
• Measure the size of encrypted traffic

can leverage information leaked by compression to recover targeted parts of the plaintext.

Compression side-channel attacks are not new. Indeed, ten years before Duong and Rizzo's presentation, a paper appeared describing such attacks in general. However, CRIME gave a concrete, real-world example.

The particular demonstration given at ekoparty showed how an attacker might execute this attack to recover the headers of an HTTP request. Since HTTP headers contain cookies, and cookies are the primary vehicle for web application authentication (after login), this presents a significant attack.

By disabling TLS/SSL-level compression – which was already little-used, and in fact disabled in most browsers – the attack as demonstrated at ekoparty is completely mitigated.

While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying gzip to allow for explicit separation of compression contexts in SPDY), BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).

BREACH is a category of vulnerabilities and not a specific instance affecting a specific piece of software. To be vulnerable, a web application must:

•  Be served from a server that uses HTTP-level compression
•  Reflect user-input in HTTP response bodies
•  Reflect a secret (such as a CSRF token) in HTTP response bodies

Additionally, while not strictly a requirement, the attack is helped greatly by responses that remain mostly the same (modulo the attacker's guess). This is because the difference in size of the responses measured by the attacker can be quite small. Any noise in the side-channel makes the attack more difficult (though not impossible).

It is important to note that the attack is agnostic to the version of TLS/SSL, and does not require TLS-layer compression. Additionally, the attack works against any cipher suite. Against a stream cipher, the attack is simpler; the difference in sizes across response bodies is much more granular in this case. If a block cipher is used, additional work must be done to align the output to the cipher text blocks.

How practical is it?

The BREACH attack can be exploited with just a few thousand requests, and can be executed in under a minute. The number of requests required will depend on the secret size. The power of the attack comes from the fact that it allows guessing a secret one character at a time.

We offer several tactics for mitigating the attack. Unfortunately, we are unaware of a clean, effective, practical solution to the problem. Some of these mitigations are more practical and a single change can cover entire apps, while others are page specific.

A very effective mitigation is HTB (Heal-the-BREACH) that modifies the server-side gzip compression library to add randomness to the size of the response content. This randomness precludes BREACH from guessing the correct characters in the secret token. HTB protects all websites and pages in the server with minimal CPU usage and minimal bandwidth increase.

Other mitigations are ordered by effectiveness (not by their practicality - as this may differ from one application to another).

1. Disabling HTTP compression
2. Separating secrets from user input
3. Randomizing secrets per request
4. Masking secrets (effectively randomizing by XORing with a random secret per request)
5. Protecting vulnerable pages with CSRF
6. Length hiding (by adding random number of bytes to the responses)
7. Rate-limiting the requests

Whichever mitigation you choose, it is strongly recommended you also monitor your traffic to detect attempted attacks.

TIME: At Black Hat Europe 2013 (Amsterdam) Tal Be'ery and Amichai Shulman presented "A Perfect CRIME? TIME Will Tell". In their presentation, Tal and Amichai demonstrated an attack using a combination of a compression oracle and time based side channel to extract data from HTTP/HTTPS traffic on HTTP responses.

To help the community better understand this class of vulnerabilities and determine if your application is vulnerable, we are releasing a PoC application, code and research work below. You can also reach us at contact@breachattack.com