The news from last week’s Black Hat and DEFCON security conferences was earth shattering for many reasons, but one of the most unexpected pieces of news was the BREACH attack that takes advantage of a vulnerability discovered within an implementation of HTTPS. The hype that has been generated about this serious vulnerability has been large, but let’s focus on the truth and stay away from a “Chicken Little-like” response.
What is the BREACH attack all the kids are talking about? BREACH is an attack that targets a sensitive piece of data within the body of an HTTPS request that takes advantage of when HTTP compression is being used.
How does BREACH work? For this attack to work, the attacker needs to: 1. Be able to force a user’s browser to create HTTPS requests (This could be done if the user is tricked into visiting a malicious website by falling for a phishing attack) 2. Be able to read the responses that are arriving at the user’s browser ^Neither of these two requirements are exceptionally difficult to create for an attacker^ …And the final requirement for this vulnerability to be present is: 3. HTTP compression must be used on the body of the HTTPS request that contains the sensitive data the attacker wishes to learn
Once these requirements are present... The attacker can attempt to guess the secret data in the HTTPS request by observing how the compressed size of the body of the HTTPS request changes. If the attacker guesses a wrong value, the size will be larger than if the guess is correct. After thousands of guesses, an attacker could eventually figure out the sensitive data without the user’s knowledge that any of this has happened.
Do you want the good news or the bad news first? The bad news is… This is a vulnerability that will take quite a bit of work before a solution is found. This attack takes advantage of how the methods for HTTP compression (gzip and deflate) work, so there is no easy solution. But the good news is… This attack can only target sensitive data in the body of an HTTPS request and is not a total decryption of HTTPS traffic. The most likely target for this attack is a CSRF token, and when used correctly, this token should be a nonce, never to be repeated. If this is the case, then the CSRF token will change with every guess the attacker makes. What is true for one guess will not be true for the next guess. However, CSRF tokens are not always created as nonces. Often, a single CSRF token is created once per session. If that is the case, then that token is at risk of being stolen by the BREACH attack. The sky isn’t falling, but it is important to recognize that this is a vulnerability that needs to be mitigated by following secure coding best practices.
