search menu icon-carat-right cmu-wordmark

CERT Coordination Center

BREACH vulnerability in compressed HTTPS

Vulnerability Note VU#987798

Original Release Date: 2013-08-02 | Last Revised: 2013-08-08

Overview

By observing the length of compressed HTTPS responses, an attacker may be able to derive plaintext secrets from the ciphertext of an HTTPS stream.

Description

Angelo Prado of Salesforce.com reports:

Extending the CRIME vulnerability presented at Ekoparty 2012, an attacker can target HTTPS responses to recover data from the response body.

While the CRIME attack is currently believed to be mitigated by disabling TLS/SSL/level compression, compressed HTTP responses represent a significant unmitigated vector which is currently exploitable. By injecting plaintext into an HTTPS request, an attacker can learn information about the corresponding HTTPS response by measuring its size.

This relies on the attacker being able to observe the size of the cipher text received by the browser while triggering a number of strategically crafted requests to a target site. To recover a particular secret in an HTTPS response body, the attacker guesses character by character, sending a pair of requests for each guess. The correct guess will result in a smaller HTTPS response. For each guess the attacker coerces the victim's browser to issue two requests. The first request includes a payload of the form:

"target_secret_name=<already known part of secret>+<guess>+<padding>"

...while the second request includes a payload of the form:

"target_secret_name=<already known part of secret>+<padding>+<guess>".

If the size of the first response is smaller than the second response, this indicates that the guess has a good chance of being correct. This method of sending two similar requests and comparing them is due to Duong and Rizzo. If multiple candidates are found, the following is a useful recovery mechanism: move forward in parallel with both candidates until it becomes clear which guess is correct.

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

[In order to conduct the attack, the following conditions must be true]:

    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.

    Impact

    A sophisticated attacker may be able to derive plaintext secrets from the ciphertext in an HTTPS stream.

    Solution

    We are currently unaware of a practical solution to this problem. Please consider the following workarounds.

    Some of these mitigations may protect entire applications, while others may only protect individual web pages.

      • Disable HTTP compression.
      • Separate the secrets from the user input.
      • Randomize the secrets in each client request.
      • Mask secrets (effectively randomizing by XORing with a random secret per request).
      • Protect web pages from CSRF attacks.
      • Obfuscate the length of web responses by adding random amounts of arbitrary bytes.

    Vendor Information

    987798
     
    Affected   Unknown   Unaffected

    Apache HTTP Server Project

    Notified:  June 19, 2013 Updated:  July 30, 2013

    Status

      Unknown

    Vendor Statement

    No statement is currently available from the vendor regarding this vulnerability.

    Vendor Information

    We are not aware of further vendor information regarding this vulnerability.

    Apache Tomcat

    Notified:  June 19, 2013 Updated:  June 19, 2013

    Status

      Unknown

    Vendor Statement

    No statement is currently available from the vendor regarding this vulnerability.

    Vendor References

      Apache-SSL

      Notified:  June 19, 2013 Updated:  June 19, 2013

      Status

        Unknown

      Vendor Statement

      No statement is currently available from the vendor regarding this vulnerability.

      Vendor References

        Apple Inc.

        Notified:  June 19, 2013 Updated:  June 19, 2013

        Status

          Unknown

        Vendor Statement

        No statement is currently available from the vendor regarding this vulnerability.

        Vendor References

          Google

          Notified:  June 19, 2013 Updated:  June 19, 2013

          Status

            Unknown

          Vendor Statement

          No statement is currently available from the vendor regarding this vulnerability.

          Vendor References

            Microsoft Corporation

            Notified:  June 19, 2013 Updated:  June 19, 2013

            Status

              Unknown

            Vendor Statement

            No statement is currently available from the vendor regarding this vulnerability.

            Vendor References

              Mozilla

              Notified:  June 19, 2013 Updated:  June 19, 2013

              Status

                Unknown

              Vendor Statement

              No statement is currently available from the vendor regarding this vulnerability.

              Vendor References

                Opera

                Notified:  June 19, 2013 Updated:  June 19, 2013

                Status

                  Unknown

                Vendor Statement

                No statement is currently available from the vendor regarding this vulnerability.

                Vendor References


                  CVSS Metrics

                  Group Score Vector
                  Base 2.6 AV:N/AC:H/Au:N/C:P/I:N/A:N
                  Temporal 2.3 E:F/RL:W/RC:C
                  Environmental 3.2 CDP:ND/TD:H/CR:H/IR:H/AR:ND

                  References

                  Acknowledgements

                  Thanks goes to the following individuals for reporting this vulnerability: Angelo Prado, Salesforce.com Neal Harris, Square Yoel Gluck, Salesforce.com

                  This document was written by Todd Lewellen.

                  Other Information

                  CVE IDs: CVE-2013-3587
                  Date Public: 2012-09-20
                  Date First Published: 2013-08-02
                  Date Last Updated: 2013-08-08 17:46 UTC
                  Document Revision: 36

                  Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.