Cloudflare analysis by Giuseppe Fuggiano, Pierguido Iezzi and the Cyber Security Research Team .
During a Penetration Testing activity, the Swascan Cyber Security Research Team (CSRT) and Incident Response Team discovered that it may be possible to bypass the Cloudflare Web Application Firewall (WAF) if not configured correctly, allowing attackers to exploit a wide range of application vulnerabilities.
Swascan recommends enabling the rules as described in the “How to Fix” section to improve the security of the web applications protected by the Cloudflare WAF and to mitigate this kind of bypass technique.
In the following sections we also report some technical details including proof-of-concepts.
We would like to thank Cloudflare for the quick response, support and detailed explanations.
Bypass Details
In this document we are describing how to use multipart/form-data HTTP POST requests and a well-known technique, widely used to bypass other WAFs: padding.
Examining Cloudflare we discovered that, in its default configuration, adding about 128 KB of padding before any multipart/form-data POST request will cause the WAF to truncate it to that maximum size, skipping the exceeding part and sending it to the target application.
A potential attacker could then upload malicious payloads, potentially exploiting the underlying application vulnerabilities.
This scenario was exploited during a real Penetration Testing carried out by Swascan.
This is possible because all WAF engines have processing limits, basically to avoid CPU over consumption.
This kind of limit also appears to be reported in this documentation page, but refers only to JSON («The Cloudflare WAF parses JSON responses to identify vulnerabilities targeted at APIs. The WAF limits JSON payload parsing to 128 KB»).
Please note that, after our advisory process, Cloudflare Product Manager, Michael Tremante said: «this bypass can be mitigated by turning on rule 100048. This rule now protects against padding type attacks but it is not deployed by default as it causes a large number of false positives in customer environments. It is, however, important that customers tune their WAF. We are also working on a better longer term solution» (see below).
Proof of Concept
Swascan tested and used this bypass technique to actually bypass Cloudflare WAF and exploited a number of critical vulnerabilities to obtain Remote Command Execution (RCE) on target systems.
HTTP requests and responses analysis
To simulate the attack, we created a small common reverse shell payload that was successfully detected and blocked by the Cloudflare command injection rule. Cloudflare responded with a HTTP 403 (Forbidden) error to the client and the Cloudflare warning page was shown.
To show how the bypass technique works, we first use a number of padding bytes that are not enough to bypass the protection (1000).
Then, we use about 128 KB of padding (line feeds) in order to trigger the WAF truncation logic.
We see that the HTTP response code was HTTP 200, which means that the command injection malicious payload was skipped by the WAF.
Note that it’s also possible to replace the padding bytes and the type of payload to exploit different kinds of vulnerabilities in different scenarios.
Unrestricted File Upload example
To do that, we create a simple PHP page (upload.php) with the following content:
Note that this PHP code is vulnerable since it’s not checking the extension of the file being uploaded.
To exploit this vulnerability, we use a simple PHP web shell like this:
We try to upload the web shell using the upload.php functionality. As you can see, this content is correctly blocked by Cloudflare and the upload is not completed.
However, we now try to bypass the WAF with the padding technique. Since the web shell is a text-based file, we use the line feed character (0x0A):
The web shell is successfully uploaded and possibly executed
How to Fix
To help mitigating this kind of bypass technique we contacted Cloudflare that recommended us to:
- Turn on rule 100048
- Use the following fields in a custom Firewall Rule depending on the need to check headers and/or body
- http.request.body.truncated
- Http.request.headers.truncated
- Please make sure you test these rules in LOG mode before deploying in a more active mode (BLOCK or other) as they are prone to generating false positives depending on the application’s expected traffic.
Also, it is extremely important to detect and correct application vulnerabilities through:
Conclusions
So far, in this document we described how to bypass the Cloudflare WAF in case of multipart/form-data POST requests, such as in file uploads. However, other conditions could also make it possible.
We also described how to mitigate this using the Cloudflare WAF rules, that must be adapted to the needs.
