Fortinet FortiWeb WAF Policy Bypass

Type packetstorm
Reporter Geffrey Velasquez
Modified 2012-05-03T00:00:00


                                            `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:  
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> at BINAR10 S.A.C.