Walk On the Fire (WOF)

"Web application firewalls (WAF)" , The today's requirement to secure the web applications without changing the existing infrastructure.But at the same time, it is a big risk in case of WAF behavior and false positives (legitimate traffic blocking). This talk will demonstrates a new concept to evaluate any WAF without taking risk of putting any WAFs into inline mode.Everything will be in learning or in passive mode. This paper describes concept of one special engine,which can be used to evaluate any WAFs with zero risk to the end user (website owner),no matter whether its vendor supports Passive mode or not(i.e. modsecurity or naxsi).

In today's day and age, there are hundreds of vendors come up with Web Application Firewalls (WAFs) with the different type of fancy promises and defacing mechanism. But at the end of the day, for the End user (Website owner or WAF Buyer), Biggest question is WAF behavior and chances of false positives (or you can say legitimate traffic blocking).For example, today there are so many commercial firewalls like F5, Barracuda ,Imperva etc. and also there are some open source firewalls like modsecurity,naxsi etc. But not all of the WAF vendor come up with passive mode (or listening mode, a mode in which attacks are only detected but not blocked by the firewalls).

Generally banking and critical infrastructure sites not recommend to put any WAFs in inline mode but they always wants this in “learning mode or passive mode” which detects attacks. The advantage of doing this is no false positive (no legitimate traffic blocking by WAFs) by WAFs. But what if , WAF vendor doesn't provide passive or learning mode ? (e.g Mod_security or naxsi,or some other commercial or open source WAFs).So here is the solution:

Any Web Application Firewalls are independent from the backend website technologies in front of which WAF is planted (Whether backend website is hosted over apache,IIS etc or whether backend technology is html, php,asp etc.). For example, assume there is one website named www.example.com which is behind a Web Application Firewall, and assume this website has one input parameter “var” which is, at the time of request looks something like :

http://www.example.com/in.php?var=123

In this scenario, WAF, which is planted in front of www.example.com doesn't care whether the parameter name is “var” or it has some other name like “var1” or something else other than “var”.In another words , Web Application Firewalls doesn't have Blueprint (map) of the backend website. We can use this bug of Web application Firewalls to make a passive mode (listening) for any Web Application Firewalls , no matter whether vendor is supporting passive mode(listening mode) or not.We can cheat WAFs by using concepts of HTTP protocol, a stateless protocol (it's tag is showing it's advantage). Assume the same example of www.example.com in which user passes argument “var” equals to “123” which will looks like

http://www.example.com/in.php?var=123,

but let's assume you have one sniffer running on the reverse proxy or on local server on which site is hosted, Now this sniffer (I tested with several WAFs like mod security , naxsi and some other commercial WAFs)will forwards traffic to the WAF which is :

1) Installed on the same machine but listening on different NIC

2) Installed on some public IP with DNS name like

www.waftesting-example.com (On which WAF is in Inline-mode) So this HTTP Stack decoding and mirroring new HTTP Stack with different hostname on which WAF is installed in inline mode. So there is no impact of WAF over the end-website.

I.e. www.example.com/in.php?var=123 will be translated like www.waftesting-example.com/in.php?var=123 by Sniffer listening on Reverse proxy (or on the different NIC of webserver). Now on www.waftesting-example.com, there are no files like “in.php” or no variable named “var” but WAF doesn?t care about this. In another words we are fooling WAF , How ?

I.e. www.waftesting-example.com/in.php?var=123 (by normal user ) which will be dropped by www.waftesting-example.com coz there is no file called “in.php” exist over the server and also value of “var” is not making any attack (you can say it is legitimate and acceptable).But imagine the same request but like this :

www.waftesting-example.com/in.php?var=< script>alert("xss attack vector")< /script> which will try to exploit website variable “var” with XSS attack vector. So the above request will be blocked(though there is no file exist named “in.php” file or there is no parameter exist “var” exist over the WAF box, and due to the reason that WAF doesn't know the blueprint of back-end website, We are fooling WAF).

So there will be two possibilities at WAF End:

1)If traffic is legitimate and not hitting any rule described in WAF, it will be dropped by WAF Box. (Reason: there is a dumb hello page installed on this box with all WAF rules, so no real pages exist) 2)If traffic is hitting some rules of WAF (or traffic issome attack vector, harmful to the website), it will be Forbidden (403) or blocked which is captured by our sniffer. (Reason: It hits a attack signature which is described as a rule in WAF)

So the for understanding, see below setup:

Website Visitors <--> (Reverse_proxy+our sniffer) <--> Actual website behind reverse proxy

(Assume that WAF Box is over some public IP out of the above setup and our sniffer sends mirrored traffic to WAF box in order to execute all the WAF Rules against the mirrored HTTP request from the real source, in another word we are “Simulating Web Application Firewall” with HTTP traffic Mirroring).

So “our sniffer” will decode visitors request (including cookies, referer and all HTTP stack parameters) and it will create and throw one new HTTP request which is mirrored from the original traffic to the WAF box (which is defined by us in sniffer code).Sniffer also logs HTTP RESPOSNSE codes(like 403,406,404 etc) So there will be two possible

response codes:

1) 404 (Not found , for all legitimate traffic which is not hitting any rule of WAF)

Why 404?

Coz if traffic is not hitting any WAF rules then it will be thrown to the apache dumb page (i.e. apache's common “its works” message page)which doesn?t contain any parameters or cookies)

2) 403,406 etc (Forbidden or blocked , for traffic which has attack vector and which hits any of WAF rules)

Why 403 or 406?

Coz Web Application Firewalls rule was hit by the request which is sent by our sniffer. No matter whether in backend apache hello page, the requested variable exists or not.

Final Picture:

1) Request is sent by the end-user of the website

2) Request arrives at reverse proxy box on which sniffer is also installed

3) Request is received by reverse proxy and reverse proxy will forward this to the actual website, At the same time, Sniffer also mirrors all HTTP fields (including cookies,referrer etc) and re-builes and throws the request to the WAF Box (WAF Simulation).

4) Actual Client request is served by respective response by Original webserver , at the same time, Sniffer also gets HTTP_RESPONSE (like 404 or 403,406) code for mirrored request which is sent to the WAF Box(which is in “inline-mode” at some remote box).

5) User can collect the blocking logs from WAF box which is the simulation of the real traffic. Without touching the actual requests.