Fortinet FortiWeb Web Application Firewall Policy Bypass

BINAR10 Report on Fortinet Fortiweb Findings 02/05/2012
- Fortinet FortiWeb Web Application Firewall Policy Bypass -
============================================================

1) Affected Product

Fabricant: Fortinet

Product name: FortiWeb

Version: Latest update to Tue, 2 May 2012

Type: Web Application Firewall

Product URL:
http://www.fortinet.com/products/fortiweb/index.html

2) Description of the Findings

BINAR10 has found a policy bypass occurrence when large size data is sent in
POST (data) or GET request.

3) Technical Details

3.1. POST Request Example

When is appended to a POST request any padding data that surpasses 2399 bytes,
the WAF do not inspect the data sent and the request hits directly the
application. This should occur when the product is not configured to block
malformed requests, but this feature also check the POST size limit, blocking
the request if it surpass a fixed limit, therefore is likely that is being
disabled due to application requirements in medium size forms.
The response is also not verified by the WAF and information disclosure occurs
with details of the infrastructure.
This bypass could be used to inject different types of vectors, as is shown in
the example only is needed to append a new variable at the end of the POST
data filled with arbitrary data that exceeds 2399 bytes.

---POST example
POST /<path>/login-app.aspx HTTP/1.1
Host: <host>
User-Agent: <any valid user agent string>
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: <the content length must be at least 2399 bytes>

var1=datavar1&var2=datavar12&pad=<random data to complete at least 2399 bytes>

3.2. GET Requests

The same issue with POST Request but it could be done through the sending
arbitrary data at the end of the URL.

--GET example
http://<domain>/path?var1=vardata1&var2=vardata2&pad=<large arbitrary data>

4. Validation Required
It requires the validation of other researchers who have access to product.

5. Time Table
04/27/2012 - Vendor notified.
04/27/2012 - Vendor response, requiring some tests.
05/02/2012 - Vendor indicates that this is a configuration problem and not
a product vulnerability.

6. Credits
Geffrey Velasquez <geffrey at gmail.com> at BINAR10 S.A.C.