Inside the BREACH attack: How to avoid HTTPS traffic exploits
Enterprise threats expert Nick Lewis examines how the BREACH attack exploits HTTPS traffic and what enterprises can do to mitigate the attack risk.
Cryptography was under heavy analysis long before Edward Snowden released the NSA's work undermining encryption. At the ekoparty Security Conference in 2012, Thai Duong and Juliano Rizzo discussed an attack named CRIME that did not significantly affect the security of Secure Sockets Layer/Transport Layer Security (SSL/TLS). At Black Hat 2013, Yoel Gluck, Neal Harris and Angelo Prado, who continued researching SSL/TLS cryptography, revealed a new threat, the Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext -- otherwise known as the BREACH attack -- which could have a far more profound impact on SSL/TLS than CRIME did.
Though the impact on enterprises from BREACH is going to be minimal, thorough analysis can help identify if any websites are vulnerable to the BREACH attack or other attacks on SSL/TLS.
In this tip, we'll discuss what the BREACH attack is, how it works, and the steps enterprises should take to reduce their risk of attack.
Inside the BREACH attack
To beat encryption, the BREACH attack targets the implementation of HTTP responses using HTTP compression, which is critical to many enterprises because it minimizes bandwidth costs and speeds up webpage load times.
The BREACH attack steals information about how data is encrypted from HTTPS-enabled Web applications by essentially combining two existing types of attacks: using cross-site request forgery (CSRF) to change data in transport, and injecting data into the HTTPS headers using a man-in-the-middle attack. The response to these requested changes, based on the injected data, allows attackers to determine the secret used for the encryption of the session one byte at a time, which can then be used to decrypt the data.
While static websites are at low risk for these attacks, full-featured Web applications are highly vulnerable due to the fact that they are designed to accept input from the Web client, making it much easier to measure changes in the webpages served by the Web application and eventually decrypt the connection. Though the practical implications for the attack technique on the server side are minimal, on the client side, updates must be made to prevent man-in-the-middle attacks. Fortunately, this attack may not work against other protocols that use SSL/TLS for transport layer encryption like SSL-SMTP or IMAPS.
Steps enterprises can use to reduce the risk of attack
There are many resources available on mitigating the BREACH attack. Ivan Ristic, director of application security research at Qualys Inc., wrote a blog about possible defenses. Carnegie Mellon CERT lists potential mitigation options in its vulnerability advisory. There is also an Internet Engineering Task Force (IETF) draft that recommends TLS improvement to protect against this attack.
Unfortunately, none of these strategies fully eliminates the issue; as Ristic mentions, remediating the attack requires browser-side improvements. Though the impact on enterprises from BREACH is going to be minimal, thorough analysis can help identify if any websites are vulnerable to the BREACH attack or any other attacks on SSL/TLS.
With a number of different things that enterprises can do to mitigate the BREACH attack, however, it is important to note that, while effective, these strategies can have negative effects on business. For example, disabling header compression greatly lowers the risk of the BREACH attack, but it can have a significant bandwidth impact on high-traffic enterprise websites.
Fortunately, other options exist, including these preventative measures:
- To keep internal clients safe, use an IPsec virtual private network (VPN) to prevent man-in-the-middle attacks. (IPsec can also help protect vulnerable SSL VPNs.)
- Use an intrusion prevention or intrusion detection system (IPS/IDS) to identify malicious clients trying to exploit the vulnerability and alert or block the attacking system.
- Alternately, a Web application firewall or firewall with Web inspection features can identity malicious clients and block them.
- A vulnerability scanner or Web application security tool can identify potentially vulnerable Web applications that require updating.
- A Web proxy or configuration change in the Web server could block client systems that are trying to make more than a set number of connections in 30 seconds. Since the BREACH attack requires a significant number of connections, controlling this could prevent the vulnerability from being exploited.
Conclusion
The SSL/TLS protocols have withstood heavy scrutiny over time yet are still considered among the most effective mechanisms for protecting transactions over public networks.
While there are insecure methods of using these protocols, when SSL/TLS is implemented correctly, it can provide a high level of transport security.
Enterprises can and should still rely on HTTPS using SSL/TLS to secure the transport of Web traffic. Though HTTPS will continue to be vulnerable to man-in-the-middle attacks, a number of improvements in information security and encrypted protocols are helping enterprises withstand these attacks.
The BREACH attack may require quick action to minimize the risk, but long term, this should not dissuade enterprises from using encryption on data transport. The many benefits of encryption, even when vulnerable to this specific attack, still outweigh the costs.
About the author:
Nick Lewis, CISSP, is the information security officer at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Boston Children's Hospital, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.
