BREACH Attacks Revived to Steal Private Messages from Gmail, Facebook

The BREACH attack hasn’t been top of mind since the summer of 2013, but two researchers have found new ways to exploit and persistently attack traffic, including Gmail and Facebook chat sessions.

The research was shared late last week in Singapore at Black Hat Asia where Dimitris Karakostas of the National Technical University of Athens and Dionysis Zindros of the University of Athens debuted their attack framework called Rupture, and demonstrated how BREACH can be resurrected to steal private messages sent over Gmail and Facebook.

The revelation last week is disturbing because it was widely believed that BREACH—and its predecessor CRIME—has been largely mitigated by disabling compression at the TLS level at the same time that providers such as Facebook took measures in their own offerings to cut down these attacks.

“The fundamental aspects of BREACH are still not mitigated and popular websites, including Facebook, continue support for vulnerable endpoints,” the researchers wrote in their paper “Practical New Developments on BREACH.” “Our work demonstrates that BREACH can evolve to attack major web applications, confirming the fact that TLS traffic is still practically vulnerable.

“We conclude that all existing mitigation mechanisms are insufficient and can be bypassed or are not practical,” the researchers wrote.

The researchers say that the rampant use of noisy block ciphers, rather than stream ciphers, allowed them to steal secrets from web apps.

“We incorporate statistical methods to bypass noise, induced either due to block ciphers or random data included in the response plaintext,” the researchers wrote. “This allows us to steal secrets that were not previously considered targets of BREACH, as long as the targeted website offers a proper attack end-point.”

The Rupture attack framework allows an attacker to inject code in all unauthenticated HTTP responses received by the victim once the attacker has a presence on the network. The browser executes the injected JavaScript, which makes requests to the target website that are sniffed and analyzed, according to researchers. The script cannot read the requests, which are encrypted, but they are available to the sniffer. The tool can then compare the encrypted lengths and deduce the secret.

“At each stage of the attack, a prefix of the secret is known, because that portion of the secret has already been successfully decrypted. The prefix decrypted grows until the whole secret becomes known, at which stage the attack is completed,” the researchers wrote. “Due to length leak, compressed plaintext that contains the correct candidate will be shorter and so will the encrypted ciphertext.”

The researchers describe their attack in detail in their paper, and also explain how their attacks are six times faster than the BREACH attacks, for example.

BREACH, which stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, is a compression attack similar to CRIME, which was discovered in 2012 by researchers Thai Duong and Juliano Rizzo. While CRIME allowed attackers to recover HTTP request headers, which contain cookies and other authentication data, BREACH went in another direction and attacks HTTP responses with 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,” BREACH researchers Angelo Prado, Neal Harris and Yoel Gluck wrote. “This allows essentially the same attack demonstrated by [Thai] Duong and [Juliano] Rizzo, but without relying on TLS-level compression.”

Karakostas and Zindros did propose a mitigation for their BREACH attacks that requires cookies be marked as first-party only, which eliminates the compression oracle which is used to retrieve secrets from the target website.

“The first-party cookies proposal describes such a mechanism, with the purpose of avoiding CSRF attacks. Interestingly, the same mechanism can be used to defend against compression side-channel attacks and eliminates the possibility completely,” the researchers wrote. “This proposal is still in draft stage and has not been implemented in any browser. We urge browser vendors to adopt it immediately and web service authors to opt-in.”