A side-channel attack is any attack based on information gained from the implementation of a computer system, rather than weaknesses in the implemented algorithm itself (e.g. cryptanalysis and software bugs). Surprisingly detailed sensitive information is being leaked out from a number of high-profile, top-of-the-line web applications in healthcare, taxation, investment and web search despite HTTPS protection.
Compression side-channel attacks can be used to read some data by knowing only the size of the compressed data such as the CRIME, and BREACH attacks. To understand how compression side-channel attacks work, we must have a fair understanding of compression algorithms.
How compression works
In compression algorithms, any repeated phrase is stored a single time. This means that when a specific string of characters appears again in the text, it is recorded only during its first appearance. Subsequent instances are merely references to this original occurrence. As a result, text that repeats is compressed more efficiently, reducing the overall size. This property can be leveraged in a compression side-channel attack.
If a text contains both a secret and a user-controlled part, we can guess the secret by just looking at the length of the compressed result. Therefore an attacker can read some data if they can read the size of the compressed page, and they have control over some of the data on that page. This is the basis for the CRIME and BREACH attacks, where CRIME depends on compression on the transport layer and BREACH depends on HTTP compression.
SSL/TLS Certificates and Their Prevalence on the Dark Web
CRIME attack
In September 2012, security researchers Thai Duong and Juliano Rizzo introduced CRIME, a compression side-channel attack targeting HTTPS. This attack exploits an information leak in the compression ratio of TLS requests, enabling the decryption of client-server communications. As a result, attackers can capture a user's login cookie, allowing them to hijack the session and impersonate the user on critical sites like banks or e-commerce platforms.
The researchers demonstrated how an attacker could execute this attack to retrieve the headers of an HTTP request. Since HTTP headers include cookies, which are essential for web application authentication post-login, this constitutes a major threat. The CRIME attack is completely mitigated by disabling TLS/SSL-level compression, which was already rarely used and disabled in most browsers. Both Google and Mozilla have released patches to protect against the CRIME attack.
BREACH vulnerability
Although CRIME was addressed by disabling TLS compression, BREACH exploits HTTP responses, which are commonly compressed using standard HTTP compression methods, making it more widespread than TLS-level compression. BREACH, a variant of CRIME, was presented at Black Hat USA 2013 by researchers Angelo Prado, Neal Harris, and Yoel Gluck. This attack enables an adversary to intercept encrypted web messages by injecting plaintext into an HTTPS request and analyzing the resulting compression differences.
BREACH encompasses a range of vulnerabilities rather than a single flaw in specific software. For a web application to be susceptible, it must use HTTP-level compression, reflect user inputs in HTTP response bodies, and include sensitive information (such as a CSRF token) in those responses. It's crucial to note that BREACH is unaffected by the version of TLS/SSL and does not rely on TLS-layer compression.
“Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,” the researchers wrote. “This allows essentially the same attack demonstrated by [Thai] Duong and [Juliano] Rizzo, but without relying on TLS-level compression.”
Prado, Harris and Gluck said at Black Hat that several ingredients make up the attack, starting with compression such as gzip, a stable webpage, the ability to measure the victim’s traffic—usually via man-in-the-middle attack, a CSRF token or some other secret in the response body, an attacker-supplied guess and a bootstrapping sequence.
“It is common for Web applications to reflect user input, such as URL parameters, in HTTP response bodies,” the paper said. “Since DEFLATE (the basis for gzip) takes advantage of repeated strings to shrink the compression payload, an attacker can use the reflected URL parameter to guess the secret one character at a time.”
The BREACH vulnerability can be exploited in less than a minute with just a few thousand requests, though the exact number depends on the secret's length. The attack's strength lies in its ability to guess a secret character-by-character. Each correct guess results in further compression of the response, signaling to the attacker their proximity to uncovering the secret. This provides an oracle that an attacker can exploit to recover the first character of [the token],” the researchers said. “Then, the attacker proceeds in the same manner to recover [the token] byte-by-byte.” Within 30 seconds during their demo, they had the 30-character encrypted token deciphered and could do so with 95 percent accuracy.
A number of mitigations were suggested by CERT and the researchers behind the attack, some of which could protect only individual Web pages rather than an entire application. The mitigations include disabling HTTP compression, separation of secrets from user input, randomization of secrets in client requests, masking of secrets by XORing with a random secret per request, protecting pages from CSRF attacks, and obfuscating the length of Web responses with random bytes of information.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts