Zero-Day Collaboration: Working With Imperva to Eliminate a Critical Exposure

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.

Bishop Fox’s Approach to Responsible Disclosure

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:

• Working with organizations to help accelerate their response and remediation efforts
• Providing detailed information that enables organizations to protect themselves against potential exposures and understand impact

In this instance, the Imperva team was immediately responsive to our findings and quickly resolved the issue – which is always our desired outcome.

Remediating a Zero-Day Vulnerability

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.

Tune into Our Webcast as We Unpack the Process

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:

• How responsible disclosure and CVE processes work
• How Imperva and Bishop Fox mobilized teams to accelerate information sharing and remediation efforts
• How offensive security strengthens defensive security products and why Imperva’s CTO prioritizes it
• How Log4j has and will change the security landscape in the coming weeks and months

Exploring the Vulnerability

Post Request Bypass

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.

Vulnerability Details

• CVE ID: CVE-2021-45468
• Vulnerability Type: Post Request Bypass
• Security Risk: Critical

Replicating the Vulnerability

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.

Running the Test Script

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.

Scripting

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.

Process to Manually Test for Vulnerability

Send three POST requests:

1. Establish a baseline POST request/response with a valid but harmless POST request
2. Trigger the Imperva WAF using the same POST request, but with extra “malicious” data such as  in the body to verify that Imperva blocks it
3. Add the header Content-Encoding: gzip to the same malicious request and verify that Imperva doesn't block it

Other Encoding

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, there are four valid values for the Content-Encoding header: 

• compress
• deflate
• gzip
• br

In testing, only gzip worked as a bypass.