Detecting Web Application Firewalls / Proxies
These are protective devices which are placed between the users and the webservice (webserver, web-farms, etc).
There sole purpose is to analyse HTTP traffic to determine if the traffic is “Valid” or “Invalid” (i.e. malicious). They are mainly implemented an Intrusion prevention system to prevent attacks against the web platform and the web application.
Hogwash was one of the first implementations of this technology many years ago. It was originally developed to protect web servers which could not be patched. I.e. A major flaw in the web application. Hogwash would be used to “scrub” the attacking traffic. This technology can be implemented in 3 ways. I will cover them in tomorrow blog
Web application firewalls are still relatively rare to see when pen-testing an application but being able to detect then is still very important. It is enccouragable for clients who engage the service of pen-testers to inform the use of web application firewalls. If this ins’t done, the pen-tester can hit many problems which will slow the testing phase and cold hinder the clients SoW. (I’m speaking from experience!). The examples I’m outlining are not the magic bullet to identify all application firewalls, but they should give you enough information to identify one when you come across one.
If your company is thinking about implementing a Web Application Firewall, then a good place to start the eval is HERE.
Teros
The Teros web application firewall will respond to simple TRACE request or any invalid HTTP method such as PUT with the following error: (note: these responses are from the “out-of-the-box” default setting.. Reponses can be different if setting are changed. BUT, unfortunately I have yet to see a company which does that *cough* a Certain BANK I used to work at *cough*)
TRACE / HTTP/1.0
Host: www.bank.com
User-Agent: Mozilla/6.9 (compatible MSIE 5.01; Widows NT 5.0)
HTTP/1.0 500
Content-Type: text/html
Error: 500
Invalid method code
The other easy way to detect a Teros application firewall is by spotting the cookie it issues. The cookie should look similar to this:
st8id=1e1bcc1010b6e32734c584317443b31.00.d5134d14e9730581664bf5cb1b610784)
The value of the cookie will obviously change but the cookie name “st8id” is pretty much a give away.
F5 TrafficShield
When you send abnormal requests (using a HTTP Fuzzer of some sort) to F5’s TrafficShield, you might get responses that contain errors like those listed here. For example, here we send a PUT method with no data:
PUT / HTTP/1,0
Host: www.bank.com
User-Agent: Mozilla/6.9 (compatible MSIE 5.01; Widows NT 5.0
HTTP/1.0 400 Bad request
Content-Type: text/html
400 Bad Request
The server could not understand your request.
Your error ID is:
5fa97729
TrafficShield also has a standard cookie that is used with their devices. The cookie name is “ASINFO”, and here is an example of what the cookie looks like:
ASINFO=1a92aa506189f3c1cf0e7fc6c6a04458…………………………………………
There is another product out there called Netcontinuum which I have not looked at or test. But if I come across it, I will post the result here.
Again, these product don't mean a thing if the default setting aren't changedor if they are not configured correctly. This is why I will have to blog soon about those $100K+ "Security Analyst/Consultant's" who work at these banks but wouldn't know their asshole from their own head! Yes ladies and gentlemen, the security of the bank relies on these $100K+ so called "Security Analyst/Consultants" who would know a xterm from a xxx show. Some survive by using politics and making problems which don't exist. In an upcoming blog, I will write about these people and let the internet community comment. I will call it " The $100K+ so called Security Consultant"
I will also cover URLScan and SecureIIS tomorrow.
For now, have fun and don’t break things !
