BREACH Compression Attack Steals SSL Secrets

msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."

Comments

Seems pretty dangerous

[mstefanro]

This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".

Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case.
It is usually very easy to inject some plain-text in the source code of webpages.

On facebook:
https://www.facebook.com/photo.php/INJECT_WHATEVER_YOU_WANT_HERE/
If you view the source of that URL you can see the text "INJECT_WHATEVER_YOU_WANT_HERE" appears 3 times in the source code.
By appending the query string, on youtube:
https://www.youtube.com/watch?v=hLkugwOYbFw&INJECT_WHATEVER_YOU_WANT_HERE
And on google:
https://www.google.com/?INJECT_WHATEVER_YOU_WANT_HERE

That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.

When I first read about this attack, the first fix that came into my mind was to just append /* [random text of random size] */ to all text/html responses.
  But this may cause troubles: if the random padding is too large, the purpose of compression
is defeated. If it is too small, workarounds may be found.

Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?

Re:Piece of Cake

[phantomfive]

Here's the list of requirements from CERT. All of these must be true for the attack to work. From this list, a creative person could think of many ways a website could avoid this exploit, but it's harder for the client.

1. HTTPS-enabled endpoint (ideally with stream ciphers like RC4, although the attack can be made to work with adaptive padding for block ciphers).
2. The attacker must be able to measure the size of HTTPS responses.
3. Use of HTTP-level compression (e.g. gzip).
4. A request parameter that is reflected in the response body.
5. A static secret in the body (e.g. CSRF token, sessionId, VIEWSTATE, PII, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownSecretVariableName="".
6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.