WOF(Walk on the Fire)

In today's age, hundreds of vendors have come up with Web Application Firewalls(WAFs) with false promises and defacing mechanism. But at the end of the day, the biggest concern of the End user(Website owner or WAF Buyer) is WAF behaviour and number of false positives(or legitimate traffic blocking) encountered. There are so many Commercial Firewalls like F5, Barracuda, Imperva, etc. and Open Source Firewalls like ModSecurity, Naxsi, etc. But not all of the WAF vendor came up with the idea of 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 does not prefer to put any WAF in Inline Mode as it might block the legitimate data. Instead they want it in Learning/Passive Mode which detects attacks. But what if the existing WAF vendors doesn't provide passive or learning mode? (e.g ModSecurity or Naxsi, or some other commercial or open source WAFs). So here is the solution:

Any Web Application Firewall works independent of the Back End Website technologies on which it is planted(whether Back End Website is hosted over Apache,IIS etc. or whether Back End 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, 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 something else. In other words, Web Application Firewalls doesn't have Blueprint(map) of the Back End Website. We can use this bug of Web Application Firewalls to make a Passive/Listening Mode for any Web Application Firewall, no matter whether vendor is supporting Passive 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 look 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.

Advantages:

Disadvantages:

Conclusion: