WAF Bypass Issues: Poor Negative and Positive Security

Submitted by Ryan Barnett 6/5/2009

In my previous post I provided an overview of potential WAF identification techniques discussed in a recent OWASP AppSec conference talk. In this entry, I want to discuss the other half of their talk which highlights a few different WAF/security filter bypass issues. From their Advisory report, we find the following two main issues -

Negative Security Signature Bypass

::::: Blacklist / negative model bypass :::::
CVE: CVE-2009-1593
Description: Profense Web Application Firewall with default configuration in negative model can be evaded to inject XSS.
Technical Description:
Versions 2.4 and 2.2 of Profense Web Application Firewall with the default configuration in negative model (blacklist approach) can be evaded to inject XSS (Cross-Site Scripting). The problem is due to the built-in core rules that can be abused using the flexibility provided by HTML and JavaScript.
The vulnerability can be reproduced by injecting a common XSS attack in a vulnerable application protected by Profense Web Application Firewall. Inserting extra characters in the JavaScript close tag will bypass the XSS protection mechanisms. An example is shown below:
http://testcases/phptest/xss.php?var=%3Cscript%3Ealert(document.cookie)%3C/script%20ByPass%3E

As you can see from the bolded section of the closing script tag above, by inserting extra text within this tag, it was able to bypass the negative signature that was within the WAF.

Analysis

When creating negative security regular expression filters, it is challenging to make them accurate and balance both false positives and negatives. In this particular case, it seems as though the Cross-site Scripting (XSS) signatures were a bit too specific, since the signature(s) were able to be bypassed by adding in additional text to the closing script tag. This leads me to believe that perhaps all of the XSS signatures ended with a closing script tag. XSS attacks don't always have to end with this tag for two main reasons -

1. Some browsers only need to see the opening script tag in order to execute the payloads, and
2. Many XSS vulnerabilities manifest themselves because the client supplied data is inserted into an existing script tag in the output so including it within the attack payload is not necessary.

It is for these types of reasons that many people use negative security signatures that look for smaller components of attack payloads rather than trying to describe the entire thing. For instance, in this case, what about some smaller individual regexs that looked for the opening script tag, the alert( action or the document.cookie object on their own? If you use smaller signatures, then you could still correlate matches together as part of an anomaly score and it would be more difficult for an attacker to circumvent them all.

While this specific advisory identified an issue with one particular WAF vendor it could happen to any of them. Anyone who has been in the security industry for a period of time understands that negative security rules or signatures is not bullet proof and evasions are always a concern. It is somewhat like the Anti-Virus market in that user's are constantly playing catchup with the bad guy's newest attack techniques. If you rely upon negative security signatures that are created specifically for known attack vector's then you are doomed to run on the Hamster Wheel of Pain where you have to update the signatures constantly.

Considering that this specific issue was a bypass/evasion of a negative security rule - I do not necessarily believe that it warranted an actual public vulnerability announcement. If public announcements for negative security filter bypasses of a security device was the norm, then we would be flooded with them for all IDS/IPS/WAF systems as they all have bypass problems. It is for this reason that you can not rely upon negative security rules/signatures alone for protection against web application attacks. You need to also utilize positive security rules, which brings us to the 2nd part of the advisory.

Positive Security Model Bypass

::::: Whitelist / positive model bypass :::::
CVE: CVE-2009-1594
Description: 
Profense Web Application Firewall configured in positive model can be evaded.
Technical details:
Profense Web Application Firewall configured to make use of the strong positive model (white-list approach) can be evaded to launch various attacks including XSS (Cross-Site Scripting), SQL Injection, remote command execution, and others. 
The vulnerability can be reproduced by making use of a URL-encoded new line character. The pattern matching in multi line mode matches any non-hostile line and marks the whole request as legitimate, thus allowing the request. This results in a bypass in the positive model. An example is showed below:
http://testcases/phptest/xss.php?var=%3CEvil%20script%20goes%20here%3E=%0AByPass

Similar to the negative security bypass issue shown previously, the security researches found that they could evade the positive security model profile by inserting a url encoded linefeed character (%0A) to the end of the attack payload and then appending a payload that actually matched the acceptable profile.

Analysis

While I somewhat downplayed the previous negative security bypass issue, I do believe that this is a serious vulnerability and it certainly does warrant a public announcement. This is more serious of an issue as it isn't just a particular signature that is evaded but potentially an entire set of signatures/rules that are meant to provide better confirmation of the payload.

The underlying problem with this particular WAF application is that its Regular Expression engine was most likely configured to run in "multiline mode." Combine that configuration with a poorly constructed positive security regular expression ruleset (that is not utilizing proper beginning/end of line anchoring) and you end up with this bypass situation.

Proper construction of positive security regular expression rules is not an easy task. Remo is a GUI rules editor for ModSecurity rules and it is quite useful for manually creating these positive security rules to enforce items such as the expected character set, format of length. Here is a graphical representation of what Remo does with the data inserted by the user.

If you look and see how the data is translated into the ModSecurity rules language syntax, it is using a regular expression operator that is using beginning (^) and end of line ($) anchors to ensure that the character classes specified match against the entire payload and not just a portion of it.

Conclusion

A few closing thoughts on this topic. First of all, this advisory shows that both negative and positive security models can have shortcomings and flaws. It is not enough to rely upon either one alone. A top tier WAF should be able to take data from both the negative security signatures and any anomalies identified from the positive security model and then correlate them together for increased intelligence and coverage. If you look at both of these examples together, these two components were clearly used in a mutually exclusive fashion. It seems as if the positive security model was used, then the negative security signatures were not evaluated. From a sheer performance perspective this might be good, but not from a security one. These two models should be used together for better coverage.

Any web security device that is apply regular expression filters/signatures/rules should be reviewed to validate exactly how the regular expression engine is configured and to review the construction of the rules themselves.