Homeland Security released an advisory on the BREACH attack, a side-channel compression attack similar to CRIME, except that it steals secrets from HTTPS responses.

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. 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.

BREACH, which stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, is a compression attack similar to CRIME. The CRIME attack, however, enabled attackers to recover HTTP request headers, which contain cookies and other Web authentication information. That attack relied, however, on TLS compression, which is not commonly enabled. Disabling TLS compression in the browser mitigates CRIME.

The BREACH researchers have turned that paradigm on its ear, and attack HTTP responses instead with the same type of compression side-channel attack.

“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 said 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.

Prado said the attack works on any version of TLS or SSL, and requires the attacker and victim to be on the same network.

“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.”

During their demo, the researchers showed exactly that. They were able to steal the CSRF token from the HTTP response body and via the BREACH attack, begin guessing characters. With each correct guess of the secret, the response is compressed further, indicating to the attacker that they are getting closer.

“The upshot is that fewer bytes go over the wire when the guess is correct. This provides an oracle that an attacker can exploit to recover the first character of [the token],” they 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, they said.