Security researchers have expanded and improved a three-year-old attack that exploits the compression mechanism used to speed up browsing in order to recover sensitive information from encrypted Web traffic.
The attack, known as BREACH, takes advantage of the gzip/DEFLATE algorithm used by many Web servers to reduce latency when responding to HTTP requests. This compression mechanism leaks information about encrypted connections and allows man-in-the-middle attackers to recover authentication cookies and other sensitive information.
The BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) attack was first presented at the Black Hat USA security conference in August 2013 by security researchers Angelo Prado, Neal Harris and Yoel Gluck. While it theoretically affects all SSL/TLS ciphers, their version of the attack was most effective against connections encrypted with stream ciphers, such as RC4.
Another team of researchers, Dimitris Karakostas from the National Technical University of Athens and Dionysis Zindros from the University of Athens, have since made improvements to BREACH that make it practical for attacking TLS block ciphers, like AES, that are more commonly used today than RC4.
Karakostas and Zindros presented their BREACH optimizations at the Black Hat Asia security conference last week and also released an open-source framework called Rupture that can be used to launch such compression-related attacks.
Their presentation included two proof-of-concept attacks against Gmail and Facebook Chat to demonstrate that many websites, including some of the most security-conscious ones, are vulnerable.
BREACH requires the attacker to be in a network position that allows the interception of a victim's Web traffic. This can be achieved on an wireless network, by compromising a router, or higher up in the Internet infrastructure by ISPs or intelligence agencies like the NSA.
The attacker will then have to find a vulnerable part of an application that accepts input through an URL parameter and reflects that input somewhere into the encrypted response.
In the case of Gmail, the researchers found that the search function on its mobile site allowed for such input reflection: a search string passed through an URL parameter was included in the response page, for example in a message saying that there were no results for that particular string. Also, if the request was made from an authenticated session, the response also included an authentication token identifying that session.
The way gzip compression works in HTTP is that, if there are multiple instances of the same string in a response, the first instance is kept and the rest will be replaced with short references to the first instance's location. This reduces the size of the response.
Therefore, in the Gmail case, if the user searches for the exact string that matches the authentication token -- or even a portion of it -- there would be two instances of the same sequence of characters in the response. Because of compression, the response would be smaller in size than other responses for a different search string.
Sign up for CIO Asia eNewsletters.