String-Matching in a Web Application Firewall [WAF]

In a review of a loaner web application firewall, a colleague noticed that it seemed to be regex-centric.  I asked if it was possible for him to extract a list of the regexs used by the applicance and then send me a copy of the set.  I really didn’t have much hope for getting the list, but there it was in my email that evening.

My colleague had set of a test environment having an application server, the WAF (web application firewall), a traditional firewall, and his client PC.  All traffic travelling between the client PC and the application server had to traverse the firewall and the WAF.  He reported that the WAF did a good job identifying and denying his cross site scripting (XSS) and SQL injection attacks on the web application, and did not exhibit excessive false positives during his testing.  It appeared to be equally capable regardless of attempts to attack form fields, hidden fields, or any type of POST or GET values.  Based on that finding alone, this appliance might be worth its cost for specific, known-vulnerable, high-risk situations where it is impossible to remediate the application weaknesses or those repairs will take an extended period of time.  Vulnerable vendor applications come to mind…

So, based on a quick review of the information in the email from my associate, the WAF organizes its regex patterns into the following categories:command injection, credit card numbers, cross site scriptin (XSS), directory traversal, protected files, protected directories, forbidden UNC references, LDAP injection, restricted characters, quotes, carriage return line feed, carriage return, tab,  SQL injection, and SSI injection.  Given the layout of this data, it was difficult for me to immediately determine whether there was a bias or focus on one area over another, so I spent some time reviewing the regexes more carefully.  They fall into the following distribution:

124 command injection,
92 SQL injection,
71 cross site scripting (XSS),
29 restricted characters,
14 SSI injection,
12 credit card numbers,
8 LDAP injection,
4 protected files,
4 protected directories,
2 directory traversal,
2 quotes,
2 carriage return line feed,
1 forbidden UNC references,
1 carriage return,
1 tab.

They appear to be written in a way that requires many of them to be used in combination with each other in order to fire positive alarms without too many false positives.  The appliance does not reveal how it assembles these combinations, or what rules it uses when it identifies certain patterns of rule-firing.

Also, there are some vulnerability categories that were not represented in the regex category listing.  When I think of the common web application vulnerability lists (for example OWASP) along with my own environment, I wonder about the absence of XPath injection, cookie poisoning, some common types of URI parameter tampering, and inappropriate error messages.  There are more as well…

There are certain types of vulnerable applications for which it might be a poor match.  If the application vulnerabilities are clustered around inappropriate use of URI values for identification or access control, then it appeared that this applicance would be especially difficult to configure so that it might resist misuse of those URI-related vulnerabilities.

Based only on reading and some brief experimenting, it appears that WAFs may fit some difficult risk management issues that we already have or expect to see in the near future.  I am very interested in any experience that you might have employing web application firewalls in your infrastructure.

Need Cultural Change at Adobe – Vulnerabilities Too Numerous

From their long and growing list of products and services, Adobe appears to be attempting to dominate the rich, user-centric application, communications, and information-delivery environments.
(see: http://www.adobe.com/products/ and http://labs.adobe.com/)

They have been pumping out new functionality, new development environments, new languages, etc. at a pace that is difficult to imagine.  How do they manage the pool of energy and creativity required to initiate and maintain their current (accellerating) trajectory?

In financial services, “cool” and “new” are not unknown, but we need to manage them into business environments that must constantly demonstrate a threshold level of due care and due diligence.

Adobe products, new and old, keep getting hacked.  On the consumer/customer as well as corporate fronts, the latest include critical vulnerabilities in Flash/AIR/Flex and Adobe Reader/Acrobat.  Both involve remote exploit and potential for executing arbitrary code on an end-user’s PC.  Because Flash and PDF files are found “everywhere” throughout the Internet, this set of vulnerabilities presents a particilarly difficult risk equation for PC users — and for the information security personnel who serve them.

There have been at least 8 publically-disclosed vulnerabilities in Adobe Flash, and at least 6 in Adobe Reader/Acrobat in the last year.  That extended a well-established tradition of vulnerabilities another year.

Because these Adobe products are found on virtually all Windows PCs, the culture at Adobe that generates and accepts this tradition of regularly-vulnerable software must be modified.  We need to raise the volume of our input to Adobe on this topic, and consider going broader with this campaign, maybe even to investors.

What do you think?  What would work most effectively?

– References –
Many of the Adobe collection can be found at: http://www.adobe.com/products/ and http://labs.adobe.com/

Adobe Flash Player (Flex/Air as well) Multiple Vulnerabilities  (Feb 25, 2009 http://secunia.com/advisories/34012/ and http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=773)
Adobe Reader/Acrobat JBIG2 Stream Array Indexing Vulnerability (Feb 2, 2009 http://www.kb.cert.org/vuls/id/905281 and http://secunia.com/advisories/33901/)