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.