TLS and SSL form the foundations of security on the Web. Everything from card payments to OAuth bearer tokens depend on the confidentiality and integrity that a secure TLS connection can provide. So when a team of clever engineers unveiled a new attack on SSL/TLS – called BREACH – at July’s Black Hat conference, more than a few eyebrows were raised. Now that it’s Cyber Security Awareness Month, it seems like a good time to examine the BREACH threat.
There have already been a number of articles in the technology press identifying threats BREACH poses to traditional Web sites and suggesting ways to mitigate the risks but it is important for us to examine this attack vector from an API perspective. API designers need to understand what the attack is, what risks there are to Web-based APIs and what can be done to mitigate the risks.
The BREACH attack is actually an iteration of a TLS attack named CRIME, which emerged last year. Both attacks are able to retrieve encrypted data from a TLS connection by taking advantage of the way data compression works in order to guess the value of a confidential token in the payload. While CRIME relied specifically on exploiting the way TLS-based compression works, the BREACH exploit can target messages sent with compression enabled at the HTTP/S level, which may be much more widely enabled in the field.
HTTP compression is based on two compression strategies for data reduction: Huffman coding and LZ77. The LZ77 algorithm accomplishes its goal of data compression by identifying and removing duplicate pieces of data from an uncompressed message. In other words, LZ77 makes a message smaller by finding duplicate occurrences of data in the text to be compressed and replacing them with smaller references to their locations.
A side effect of this algorithm is that the compressed data size is indicative of the amount of duplicate data in the payload. The BREACH attack exploits this side effect of LZ77 by using the size of a message as a way of guessing the contents of a confidential token. It is similar in nature to continually guessing a user’s credentials on a system that provides you with unlimited guesses.
While the premise is scary, the good news is that the BREACH attack doesn’t give an attacker unfettered access to the encrypted TLS payload. Instead, it is a targeted attack that attempts to retrieve a confidential token through repeated and iterative guesses. In fact, the attack isn’t an exploit of the TLS protocol at all, rather it is an attack that can be applied to any messaging system that uses the gzip compression algorithm (which is a variation of LZ77).
On top of this, BREACH is not an easy attack to pull off. A would-be BREACHer must:
- Identify an HTTPs message which has compressed data, a static secret token and a property that can be manipulated
- Trigger the application or server to generate many such messages in order to have a large enough sample size to iteratively guess the token
- Intercept all of these messages in order to analyze their sizes
Each of these requirements is non-trivial. When combined, they greatly reduce the attack surface for a BREACH attack in the API space. While API messages certainly contain data that may be manipulated and while many APIs do provide compressed response data, very few of those API messages also contain confidential tokens.
But designers of APIs shouldn’t dismiss the possibility of being BREACHed. There are at least two scenarios that might make an API susceptible to this attack vector.
Scenario 1 – Authentication & CSRF Tokens in Payloads:
Many APIs return an authentication token or CSRF token within successful responses. For example, a search API might provide the following response message:
If this response message was compressed and the attacker was able to coerce a victim into sending many requests with specific search terms, it would only be a matter of time before the AuthToken credential was retrieved.
Scenario 2 – Three-Legged OAuth:
APIs that support the OAuth 2 framework for delegated authorization often implement CSRF tokens, as recommended in the OAuth 2 RFC. The purpose of the token is to protect client applications from an attack vector in which a client can be tricked into unknowingly acting upon someone else’s resources (Stephen Sclafani provides a better explanation of the CSRF threat here.) Due to the fact that CSRF tokens are reflected back by the server, the three-legged OAuth dance becomes a possible attack surface for BREACH.
For example, an attacker could coerce a victim to send repeated OAuth 2 authorization requests and utilize the state parameter to guess the value of the authorization token. Of course, all of this comes with the caveat that the OAuth server must be compressing responses to become a target. The fact that a new authorization code is generated for each authorization attempt would make this attack less practical but still theoretically possible.
Ultimately, the simplest way to mitigate the BREACH attack is to simply turn off compression for all messages. It isn’t hard to do and it will stop BREACH dead in its tracks. However, in some cases, designers may need to support compression for large data responses containing non-critical information or because they are supporting platforms with low bandwidth capabilities. In these instances, it makes sense to implement a selective compression policy on an API Gateway.
While disabling compression will certainly negate the impact of the BREACH attack, a more general solution is to impose smart rate limiting on API requests. This will not only negate the sample size that a BREACH attacker needs to guess data, it will also stop other side-effect attacks that don’t rely solely on compression. In addition, log analysis and analytics will make it easier to spot any attempt at an attack of this kind.
An API Gateway is the key component for this type of security mitigation in the API space. A Gateway can provide the level of abstraction needed to enforce configurable compression and rate limiting policies that server side developers may not have the security background to implement effectively. In addition, the Gateway acts as a central enforcement point for security policy – particularly useful in larger federated organizations.
TLS is core to most of the security implementations that have evolved on the Web, including the OAuth 2 framework. This latest published attack does not render the world’s TLS implementations useless but it does introduce an interesting attack vector that is worth protecting against in the API domain. Remember, API rate limiting and usage monitoring are useful for much more than just monetizing an API!