What is a WAF?
WAF or Web Application Firewall is a technology that is widely used by Organizations to protect their applications from different kinds of attacks. All modern WAFs provide a lot of different configurations. This includes malicious signature detection, which is responsible for keeping an application secured against attacks like XSS, SQLi, Path Traversal, SSTI, LFI, RCE, etc. Although you might find many different write-ups or GitHub repositories (https://github.com/gprime31/WAF-bypass-xss-payloads/tree/master) to partially bypass this detection via a few encoding or escaping techniques but it is extremely difficult to achieve this and very rarely happens, and on top of that WAF company immediately fix these bypass techniques as soon as it gets out in the community.
F5 XC
F5, Inc. is an American technology company specializing in application security, multi-cloud management, and application delivery networking. They have a lot of different SaaS products like F5 DNS Products and Services, Application Delivery Automation and Security Management Solutions, Hybrid Multicloud Networking Products and Services, etc. One of their main products is F5 XC, now officially named F5 Distributed Cloud Services, which is a SaaS-based security platform. It provides services like CDN, Load Balancer, Web App Firewall, networking, etc. F5 XC App firewall is one of the most used WAFs around the world. It has very good signature detection for malicious requests, which is next to impossible to penetrate and bypass. Well, if you are wondering how to determine if the WAF is F5 XC, the answer is, you simply look for something like x-volterra-location or server: volt-adc in the response headers.
You can use Shodan to see how widely it is used by different organizations in many different companies.
shodan search query: HTTP server: volt-adc
shodan search query: HTTP server: x-volterra-location
Here is a demonstration to show how F5 XC blocks XSS and SQLi attacks.
When requesting the application that is behind the F5 WAF, by submitting the malicious payload, observe that it blocks the request.
F5 WAF blocking request by detecting the presence of XSS payload in the request body
If you are a pentester or a security researcher then you probably see this a lot during your pentesting and might have thought that injection based attacks are not very much possible here. But what if I told you that there is a very smooth and simple way that you can try to bypass F5 WAF.
Request body inspection limit
During a security research, we found that F5 WAF thoroughly checks for malicious payloads in the request body. But what if the request body is very huge? As the WAF scans incoming requests against thousands of malicious signatures, the request processing time will increase significantly for huge requests, causing the WAF to hold the request longer. But how big is too big? How much is the request body inspection limit for F5 WAF?
The way we figured this out is very simple. The idea was to prepend junk data before our malicious payload, so that when the WAF starts inspecting the request from the beginning, it should reach its maximum request body inspection limit, causing it to stop scanning before it even reaches our malicious payload. We first tried a request, prepending 8kB of junk data before an XSS payload in the body, but the F5 WAF blocked it again.
HTTP Request Body
{
"junk":"0000000......(till 8kB)", -------> Blocked by F5 WAF
"payload":"<img src=x onerror=alert(1)>"
}Similarly, we tried 16kB and 32kB, but no luck so far. The breakthrough came when we tried 64 kB. We were not facing WAF and instead getting a response from the backend server, indicating it successfully saved our XSS payload.
HTTP Request Body
{
"junk":"0000000......(till 64kB)", -----> Passed by WAF ----> Backend Server
"payload":"<img src=x onerror=alert(1)>"
}This means the F5 WAF has a maximum request body inspection limit of 64KB. If a request exceeds this size, the WAF will only inspect the first 64KB and ignore any data beyond that point. We tried injecting an XSS payload in the name field of the application and it successfully bypassed the F5 WAF.
F5 WAF blocking request carrying XSS payload in the name field.
Bypassing F5 WAF by prepending junk data of 64kB to inject XSS payload.
Misconfiguration
This suggests that the F5 WAF, by default, is configured to inspect only the first 64KB of the request body. We initially assumed this limit might be configurable, but upon reviewing their docs, we could not find any way to increase this limit from 64kB to a higher size such as 128 MB. So we contacted the F5 team to provide a way to configure this and they told us that the feature to increase the size of the inspection limit is not released yet. But they later came up with an alternate solution to block all requests whose size is more than 64kB. This can be configured under the Service Policy section on the F5 management console.
So simply configuring Max Request Size with a value of 64kB easily mitigates this issue. But what about when an application majority of requests are more than 64 kB, in this case you can not simply implement the Max request size. This is a very huge limitation in F5 XC.
Well, What about other WAFs?
We have found the same default configuration on other WAFs like Akamai, Cloudfront, etc as well. Although other WAFs do provide configuration options to increase size of request body inspection.
Here is a document link for Akamai which you can refer to understand how to increase the inspection limit size: https://techdocs.akamai.com/terraform/docs/request-body-settings. By default Akamai keeps the “request_body_inspection_limit” to 8kB and many DevOps Engineers do not configure which weakens the security architecture of Application behind the WAF. Assetnote has done a great research on this. You can read about default request_body_inspection_limit size of other WAF here: https://github.com/assetnote/nowafpls
We found this similar issue on one of the private programs on HackerOne. The Application was behind Akamai WAF and blocking all XSS payload but we were able to bypass Akamai by prepending 8kB of junk data and achieved an XSS. To highlight the issue in Akamai, the team rewarded us $1,750 as bonus.
However all other WAFs provide a way to configure and increase inspection size. Here are some documentation links which you can refer:
- https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-setting-body-inspection-limit.html
- https://techdocs.akamai.com/terraform/docs/request-body-settings
- https://developers.cloudflare.com/workers/platform/limits/#request-limits
- https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/independent-configuration-of-size-enforcement-and-inspection-limits-in-applicati/4235543
Conclusion
Well, first and foremost, if you are using F5 XC WAF, make sure to configure Max Request Size as described above. And if you do not prefer to implement this on WAF level in case it does not align with the Application requirements, for example file upload endpoints can carry data in mbs, then you can simply implement this on your middleware at the backend server.
- If the request body size is more than 64kB , trim it to 64kB.
- If the request body size is more than 64kB , return a 400 Bad Request response.
If you are using any other WAF, make sure to configure the “request_body_inspection_limit”.
Another thing to keep a note here is that this WAF bypass technique only works on request body parameters, and not on query parameters . So this means it will only work for POST, PUT, PATCH methods, and not for GET or DELETE methods.
Security architecture should never be a single point of failure. There should be multiple layers protecting your infrastructure, if one fails others will stand strong to protect your organization. So you should never totally rely on a WAF to protect your applications.
Security is just a Myth
