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.