BREACH Attack: Are you Vulnerable?
June 22, 2023
Introduction
In recent engagements, vulnerability assessments and penetration tests performed by TraceSecurity have revealed that the BREACH Attack is on the rise for improperly configured web applications. This compression side-channel attack feeds off the presence of HTTP-level compression, reflected user data in HTTP response bodies (such as a URL), and exposed secrets such as personally identifiable information [PII], Cross-Site Request Forgery (CSRF) Token, sensitive data, etc. This article will cover what a BREACH attack is, how BREACH is used for unethical gain, what is needed for this attack to be successful, and what your organization can do to protect itself from this attack.
What is BREACH?
The first question that must be answered is, what is BREACH? BREACH, discovered in September of 2012, is an attack that gains information about cleartext data from the cryptographic algorithm used in HTTP-level compression, also known as a compression side-channel attack. In short, this attack looks at the behavior of the HTTP compression algorithm to gain information about the data that was encrypted.
An Easy Exploit
This begs the question; how can an attacker use the BREACH attack for unethical gain? A malicious actor may utilize this attack to gain credentials of a legitimate user to impersonate said user on an affected web application. In fact, breachattack.com says, “The BREACH attack can be exploited with just a few thousand requests, and can be executed in under a minute.” Breachattack.com shows that this attack is practical, and for an experienced malicious actor, this would be a simple vulnerability to exploit. Once this hacker has legitimate credentials, they may access any part of the web application that the real user is able to. That includes revealing and changing personal information (address, SSN, etc.), changing passwords, and in special circumstances, this attack could be strung together with other vulnerabilities to escalate user privileges.
Critical Signs
With the implications of this attack in mind, how can you tell if you are vulnerable? There are three critical signs that a web application is vulnerable to a BREACH attack, all of which must be present simultaneously. The first question to ask is, do you have HTTP-level compression enabled? You can identify if your web application is using HTTP level compression by checking the “Accept-Encoding:” field under HTTP-Response Headers for “gzip/deflate”. An image below illustrates this issue:
The second question is, does your web application reflect user data in HTTP responses? The clearest way to check for this is to look at the URL of your webpage. Does it contain data that is also found in the HTTP response? This is best illustrated by the below image taken from Rafael Palacios et al.’s paper, “HTB: A Very Effective Method to Protect Web Servers Against BREACH Attack to HTTPS.”
In this case, the image shows the reflection of the session token both in the HTTP response and the URL for the affected web page.
The third and final question to answer is, does your web application show a secret such as PII, CSRF Token, or sensitive data? This is the final piece to a BREACH vulnerable web application. This is also best illustrated by the below image sourced from Rafael Palacios, et al’s paper, “HTB: A Very Effective Method..."
The highlighted sections show a CSRF token that can be used as the last piece in this attack.
How To Avoid
Now that the exploitation of the attack is understood, how can an organization prevent this attack from occurring? According to breachattack.com, “A very effective mitigation is HTB (Heal-the-BREACH) that modifies the server-side gzip compression library to add randomness to the size of the response content.” This makes the method of guessing the characters of the aforementioned secret more complex as the response from the HTTP compression algorithm is randomized with each request. This will effectively make the attacker’s easiest route of exploitation much more difficult if not impossible. The other methods of mitigation are as follows: Disable HTTP Compression, Separating secrets from user input, Randomizing secrets per request, Masking secrets (via the use of XOR), Protecting vulnerable pages with CSRF, Length hiding, and/or Rate-limiting HTTP requests.
TraceSecurity recommends annual penetration testing and vulnerability assessments to help identify vulnerable web applications. Some organizations may be vulnerable to an exploit like this and never know. That is why frequent testing is imperative to the well-being of any safe and successful organization.
Resources: