Attack can Steal HTTPS Secrets

Tuesday, August 6, 2013 @ 06:08 PM gHale

A serious attack against ciphertext secrets buried inside HTTPS responses forced the Department of Homeland Security to jump into action and issue an advisory.

The BREACH attack is an offshoot of CRIME, which officials thought had gone away after it ended up disclosed in September. BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes.

Black Hat: SCADA Out of Control
Black Hat: Compromising Wireless Devices
Black Hat: ICS SCADA Honeypot Finds Threats
Black Hat: Weeding Out Insider Threats
Black Hat: NSA Know the Facts

Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at the Black Hat conference in Las Vegas last week. Once the Web application opened and BREACH 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. A number of mitigation suggestions came from 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 (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 users do not always enable. Disabling TLS compression in the browser mitigates CRIME.

BREACH researchers, however, 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.

Prado, Harris and Gluck 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 researchers’ 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 compresses 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],” 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, they said.

Leave a Reply

You must be logged in to post a comment.