F5 BIG-IP ASM 11.4.1 Filter Bypass

`Details  
=======  
  
Product: F5 BIG-IP Application Security Manager (ASM)  
Vulnerability: Web Application Firewall Bypass  
Author: Peter Lapp, lappsec () gmail com  
CVE: None assigned  
Vulnerable Versions: Confirmed 11.4.0, 11.4.1. Should apply to all releases.  
Fixed Version: None  
  
  
  
Summary  
=======  
  
The F5 ASM is a web application firewall designed to protect web  
applications from attacks. Due to the way that the system processes  
JSON content, it's possible to bypass the ASM using a crafted request  
to a URL that processes both JSON and regular URL encoded requests.  
  
The vendor has acknowledged that this is an issue and has indicated  
that a fix will be released sometime in the future, but doesn't have a  
time frame and it's not a priority. I decided to release the details  
so anyone with a vulnerable configuration is aware of the risk and can  
act accordingly.  
  
  
  
Technical Details  
=================  
  
The problem is that the ASM's JSON parser does not normalize URL  
encoded content. So it will block <script>, but not %3cscript%3e. This  
is fine unless you have a JSON profile applied to a URL that also  
processes normal x-www-form-urlencoded POST requests. In this case,  
it's possible to trick the ASM into thinking the request is JSON, URL  
encode your payload, and slip it through to the application.  
  
Granted, this bypass is limited to a specific configuration, but it's  
really not that uncommon to have a JSON profile applied to a URL that  
also processes other data. Possible scenarios include a generic JSON  
catchall, one automatically created by the policy builder, or you may  
have a web application that uses parameter based navigation (page=json  
goes to one page, page=search goes to another). In any case, if you  
have a JSON profile applied to a URL that also handles POST requests  
with x-www-form-urlencoded content, you're vulnerable.  
  
  
First, in order to bypass the ASM, you have to trick it into thinking  
the request content is JSON. In F5's documentation  
(https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-4-0/14.html),  
they recommend matching *json* in the Content-Type header. This is  
easily tricked by setting the header to "Content-Type:  
application/x-www-form-urlencoded; charset=UTF-8;json".  
I then tested setting it to only match on application/json, but that  
was still tricked by dual content-type headers:  
  
Content-Type: application/x-www-form-urlencoded; charset=UTF-8  
Content-Type: application/json  
  
The application (running on Tomcat) processed the request as  
urlencoded, but the ASM processed it as JSON.  
  
  
>From here, passing through a malicious payload depends on the  
violations that are enabled on the security profile. If Malformed JSON  
is NOT enabled, you can just tag "json" onto the end of the content  
header(or double the header), URL encode special characters in your  
payload and send it away. In this case, a request like the following  
would not be blocked:  
  
POST / HTTP/1.1  
Host: x.x.x.x  
Connection: keep-alive  
Content-Length: 168  
Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json  
  
search=%3cimg+src%3dx+onerror%3alert%280%29%3e  
  
  
If Malformed JSON violations are enabled, then the payload has to be  
valid JSON. A request like the one below will get past that. It's not  
pretty but it works. This request will get past the ASM with all the  
bells and whistles enabled.  
  
POST / HTTP/1.1  
Host: x.x.x.x  
Connection: keep-alive  
Content-Length: 168  
Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json  
  
{"junkparam=&search=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2=":"junk"}  
  
  
The ASM parses that as JSON and it is well formed so there aren't any  
errors. But the application is processing it as x-www-form-urlencoded  
so {"junkparam is just treated as a regular parameter name and the  
second parameter with the payload in it gets through. The last  
parameter is there just to close out the JSON format.  
Also, because JSON profiles don't check for meta characters in  
parameter names, it doesn't trigger an Illegal meta character in  
parameter name violation. If the payload looked like this  
{"param":"junkparam=&locationFilter=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2="}  
then it would still get through but only if the illegal meta character  
in value violation was not set to block.  
  
  
Right now there is no fix for this issue and I haven't been able to  
find a way to block a request like the one above from getting through.  
I consulted F5's engineers and they said this was by design and  
there's no way to block it as of now. There will be a fix for this in  
the future, but until then make sure that your ASM profiles are as  
explicit as possible and you have compensating security controls for  
any URLs that this bypass would apply to. It's just another reason not  
to use a WAF as a band-aid for a vulnerable application!  
  
Feel free to contact me if you have any questions or additional  
information to add to this.  
  
  
  
Timeline  
========  
1/19/2015 - Reported the issue to the vendor  
2/26/2015 - The vendor confirms that it's a valid problem but are not  
going to release a fix in the near term.  
3/13/2015 - Vendor product development creates ID 511951 to track the  
problem and consider adding a fix in a future major release.  
5/5/2015 - Released info to FD.  
  
  
`