When performing a PenTest against a WAF-protected site, what should a Pentester know to enhance the Test-Quality?

Question

I'm running a WAF infront of a bunch of Webapps and we have the Apps regulary tested, and we want to improve our Tests by presenting some kind of livelogs to the testers. What informations, from Server-View, could help the Pentesters?

The objective is NOT to keep the testers out, but to find any possible way to bypass the WAF and internal protections.

EDIT: it's merely a WAF-testbed. The Vulns within the Apps are known and mostly marked as WONTFIX [!sic!]. You know, it's one of that "natural grown" - java-app from once upon a time ...

Answer 1

Your approach should be two-fold:

Technical:
Check for:

• Various escape sequences (e.g. \x00, %s, \\, etc.)
• Unicode tricks (e.g. multi-byte characters that end in 0x22 to produce a ")
• Alternative XSS methods (e.g. <img src=0 onerror=alert(1) /> instead of <script>alert(1)</script>)
• Various nasties (e.g. XSS, SQL injection) inside of cookies and HTTP headers - often WAFs miss these!

Advisory:
Ensure that the client understands that a WAF is just a sticking plaster, and cannot fix a broken limb. If the application is broken in an exploitable way, a WAF may prevent the attack or mitigate some of the impact, but there is no way to be sure if it will be effective.

It is also a double-edged sword, in that people often assume that a bug that a WAF makes unexploitable will always be unexploitable, and therefore doesn't need to be fixed (at least with any haste). Browsers and HTML / CSS / JavaScript / SQL / XML / server-side languages, etc. evolve constantly, so new exploit techniques may come along that make old bugs exploitable.

---

One additional point I'd like to make: if the test is aimed at the web-app, and not specifically aimed at the WAF solution they have deployed, then I would highly recommend asking the client to disable the WAF on their staging site for the duration of the test. Leaving it on makes it much harder for you to give them a reasonable estimate of the security posture of the application, and that means they get less value from the test. If they're really interested in testing the WAF, they could do an additional test day afterwards that compares the exploitability of the found issues with and without the WAF being enabled.

Answer 2

There are three approaches to attacking a web application behind a Web Application Firewall (WAF). If you look at existing WAF bypass exploits you can see that they break down into two major categories. You can bypass a set of rules because it is overly restrictive or does not accurately match a real attack, or attack the pre-processor which will bypass every ruleset. There is a third category of WAF bypass, which doesn't require a WAF bypass exploit.

1. WAF pre-processor attacks are aimed at trying to obscure or remove an attack payload from a request prior to being processed by a WAF's rule-sets. Here are two exploits that are WAF pre-processor attacks:

   PHPIDS had an insecure "Remove Duplicates" pre-processor can be used to obscure any payload that is duplicated 33 times. (Disclaimer: This is my exploit)

   IBM WebSphere had an insecure "Remove Comments" pre-processor can be used to obscure any payload.

2. WAF ruleset attacks are exploiting a weak ruleset that allows an attacker to submit a valid attack string. In this case the rules are overly simplistic an attack can be modified to avoid detection. There are two directions to attacking a web application behind a web application firewall.

   One direction is to attempt to exploit a common vulnerability, such as XSS or SQLi. Determine what rule you violated, and try and modify your attack payload to bypass this rule. Rules can be audited using a Regex Debugger, RegEx Buddy is my favorite tool for this process. After you are able to exploit SQLi, then search for SQLi vulnerabilities in the application. For example, if you had a modified string that would execute sleep(30) on a MySQL database without being detected by the WAF, the you can use this string to fuzz for blind SQLi in the application. Here is an example of a SQL Injection payload modified to bypass mod_security. This is a blackbox approach where you don't have access to the web application its self, but the attacker should always access to the WAF.

   The other direction is the reverse, exploit the web application with a vulnerability like SQLi without the WAF, and then try and create an attack string to exploit this vulnerability without being detected by the WAF. This is a grey-box approach.

3. The third method of attacking a web application behind a WAF is to avoid the problem entirely. It is impossible for a WAF to detect every attack. There are common vulnerabilities in web applications that WAFs cannot prevent. CSRF, Mass Assignment, Insecure Direct Object Reference, Click-Jacking, Cryptographic Oracles, Authentication/Authorization logic errors... use your imagination.