NATIONAL CLEAN OUT YOUR COMPUTER DAYObserved on the second Monday in February,...
“Web application Firewalls”
Mr. Bhaumik Shah is a information security consultant. Bhaumik has over 5 years of professional experience in Information Security Consulting, Enterprise Risk Assessments across industries such as Banking & Finance, BPO, Manufacturing, Telecom, FMCG and Information Technology. His research interests fall mainly in the field of Information Security and new technologies.Bhaumik is currently member of ISACA and he is also CISA and CEH certified. You can reach him at [email protected]
“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 demonstrate 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 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:
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 ofwww.example.com in which user passes argument .var. equals to .123. Which will looks like
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 bywww.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:
by normal user) which will be dropped bywww.waftesting-example.comcoz 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(“xssattack 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
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.
No CPU and memory utilization required on the reverse proxy box.
No interference in the actual HTTP_REQUEST and HTTP_RESPONSE.
No need to put any WAF from any vendor in inline-mode.
No tension of false positive while there is a detection of attacks is going on by WAF.
Overall CPU and Memory usage is pretty lower because WAF rule processing is done over some third party system.
Similar to Gartner’s RASP concept
Disadvantages (Be transparent):
Sniffer should be capable of handling Gbps traffic otherwise it will drop certain HTTP_REQUESTs and HTTP_RESPONSESs (Sniffer should be implemented in PF_RING instead of libpcap or some other TCP wrappers)
Problem in finding some of the Business Logic Vulnerabilities by using above mechanism.
By mirroring the traffic, we are sending two requests, one by reverse proxy and other by sniffer (which is also installed over the reverse proxy machine) to actual website and to WAF box respectively.
WAF Box over some public IP can be in any mode (either .inline mode. or .learning mode.), no matter.
This whole procedure is not even touching the single bit of HTTP_REQUEST or HTTP_RESPONSE due to the reason that HTTP REQUEST and HTTP RESPONSE decoding and encoding is done by Sniffer which is installed on reverse proxy box.
In case of SSL, we can use the same phenomenon by using technique of .SSL-Offloading. In order to get decrypted traffic or you can install this on the same web-server but on different NIC.
Author: Bhaumik Shah
Check our website, where you can order the subscription: