Facebook Takes Tougher Stand Against BREACH Attack

Facebook Transparency Report

Facebook disclosed today how it has beefed up cross-site request forgery (CSRF) tokens in order to ward off the BREACH attack.

The BREACH attack was the talk of Black Hat last summer. It was disclosed less than two months after the first Snowden leaks and helped renew focus on the security of online communication and the protocols guarding ecommerce and messaging.

What BREACH did was throw a wrench into cross-site request forgery protections by making it easier for hackers to steal CSRF tokens and other secrets from a HTTPS traffic stream by measuring compression ratio changes that leak from a website request and response in the underlying HTTP protocol. BREACH is an extension of the CRIME attack which was released in late 2012.

Facebook, like other large service providers, defended against CSRF by issuing tokens that are supposed to prevent such impersonation attacks because the attacker would need to be in possession of the victim’s CSRF token and present it to a website. BREACH changed that line of thinking, forcing engineers to go back to the drawing board and figure out mitigations beyond some of the initial recommendations, such as turning off HTTP compression.

Today, Facebook disclosed how it’s mitigating BREACH attacks

Today, Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.

The CSRF token contained a truncated SHA-2 hash that incorporated the account ID and current date. A person with three Facebook sessions within a single day would have received an identical CSRF token each time,” Facebook engineers Chad Parry and Christophe Van Gysel said in a statement. “Now our system replaces the token with a new one every time it is requested.”

Cross-site request forgery attacks are used by hackers to gain access to online accounts to which the victim has signed in. An attacker can, in turn, impersonate the victim and steal information or use their account to send spam, for example.

BREACH, or Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, was unveiled last summer in Las Vegas by researchers Angelo Prado, Neal Harris and Yoel Gluck. BREACH, unlike CRIME, is an attack against HTTP responses using the same type of compression side-channel attack used in the CRIME attack. CRIME allows attackers to recover HTTP request headers, which contain cookies and other Web authentication information and relied on TLS compression that is not commonly enabled; disabling TLS compression in the browser mitigates CRIME.

“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 in a paper “BREACH: Reviving the CRIME Attack.” “This allows essentially the same attack demonstrated by [Thai] Duong and [Juliano] Rizzo, but without relying on TLS-level compression.”

Facebook said that in its new method, CSRF tokens are generated by introducing a random 24-bit salt.

“The salt is the last 4 letters at the end of the token and is also included within the hash, which eliminates all repetition anywhere in the token,” Facebook said. “After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.”

In the previous paradigm, an attacker could use the same token to request pages over and over in order to adequately measure changes in compression size. Now, Facebook said, an attacker would rarely see the same token twice.

“BREACH takes advantage of repetition, so the introduction of randomness foils the attempts,” Facebook said.

Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically. Facebook said even turning on compression only for trusted referrers, one of the suggested mitigations for the attack, wouldn’t work because its presence on so many third-party sites would again affect performance.

Suggested articles