Sandro Wendel

From Security Weekly Wiki
Jump to navigationJump to search

Special Guest: Sandro Gauci Wendel Henrique

Sandro Gauci: Chief Consultant and Founder,

Mr. Gauci has over 8 years experience in the security industry and is focused on analysis of security challenges and providing solutions to such threats. His passion is vulnerability research and has previously worked together with various vendors such as Microsoft and Sun to fix security holes. He is currently based in Malta and enjoys working with both International and local organizations.

Wendel Guglielmetti Henrique is a consultant for penetration testing at Trustwave's SpiderLabs, the advanced security team within Trustwave focused on forensics, ethical hacking, and application security testing for premier clients. He has worked with IT since 1997, during the last 7 years he has worked in the computer security field. He found vulnerabilities in many softwares like Webmail systems, Access Points, Citrix Metaframe, etc. Some tools he wrote already were used as examples in articles in national magazines like PCWorld Brazil and international ones like Hakin9 Magazine. Recently spoke in YSTS 2.0, Defcon 16, H2HC and others. During the past 3 years he has been working as a Penetration Tester.


"WafW00f," a tool that applies their research and automates the process of identifying WAFs. WafW00f can precisely identify 20 different brands of WAFs and detect if they are in reactive mode. A second tool they've created, "WafFun," allows them to bypass and exploit WAF systems. Together, their tools allow them to identify the traffic blocked by the WAF and modify their attacks in a way that is completely blind to the WAF system, enabling the exploitation of the Web-facing application.

Consequently, if the WAF system is circumvented then the Web application is returned to a state prior to the installation of the WAF. If an attacker is able to exploit a flaw in the WAF, the attacker can take complete control of the system, resulting in disabled rules, copying of local files, and using the WAF system to launch further attacks.

During their presentation, Henrique and Gauci will use WafW00f, WafFun and other original tools to detect, bypass and exploit commercial WAF systems, showing first-hand the vulnerabilities associated with these systems.

Comments on tool

Another interesting presentation that was given by Wendel Guglielmetti Henrique, Trustwave & Sandro Gauci, EnableSecurity at the recent OWASP AppSec EU conference was entitled The Truth about Web Application Firewalls: What the vendors don't want you to know. The two main topics to the talk were WAF detection and evasion. WAF DetectionThe basic premise for this topic is that inline WAFs can be detected through stimulus/response testing scenarios. Here is a short listing of possible detection methods:

   * Cookies - Some WAF products add their own cookie in the HTTP communication.
   * Server Cloaking - Altering URLs and Response Headers
   * Response Codes - Different error codes for hostile pages/parameters values
   * Drop Action - Sending a FIN/RST packet (technically could also be an IDS/IPS)
   * Pre Built-In Rules - Each WAF has different negative security signatures

The authors even created a tool called wafw00f to help automate these fingerprinting tasks. The tool states that it is able to identify over 20 different WAFs (including ModSecurity) so I thought I would try it out against my own ModSecurity install to see how it works. After reviewing the python source code and running a few tests, it is evident that in order for wafw00f to identify a ModSecurity installation, it is relying upon the Pre Built-In Rules category as mentioned above. Specifically, if a ModSecurity installation is using the Core Rule Set and has the SecRuleEngine On directive set, then the OS command/file access attack payloads sent by wafw00f will trigger the corresponding rules and a 501 response status code will be returned.

Reliance upon the returned HTTP status code is not a strong indicator of the existence of a WAF as this can be easily changed. Looking on the other end of the spectrum, and taking a defensive posture, this scenario reminds me somewhat of best practice steps for virtual patch creation. One of the key tenants for creating these patches is that you don't want to key off of attributes in an attack payload that are superfluous. The point being is that there are only a small set of key elements that are key to the success of the exploit. These are the items that you want to focus on for a virtual patch. If, however, you key off of non-essential data from some proof of concept code, your virtual patch can be easily evaded if the attack alters this data. In this particular case with wafw00f, the HTTP response code generated by ModSecurity is customizable by the polices so the identification effectiveness is reduced to only "Default Configurations." With ModSecurity, for instance, it is trivial to update the status action of the Core Rule Set to use some other status code. This can be accomplished in a number of ways such as by using the block action in the rules or SecRuleUpdateActionById directive to change what status code is returned.

This is an interesting tool in that it aids with the pentesting/assessment steps of footprinting the target network. The more details that you can identify about the target, the more finely tuned your attack strategy can be. With this in mind, if you want to easily trick wafw00f, you could always update the SecServerSignature ModSecurity directive to spoof the server response header and impersonate another WAF product :) Take a look at the wafw00f code for hints on what data to use.