ModSecurity Blog

Before I talk to the title of this post, I have to provide a little back story. I have had an ongoing DRAFT blog post whose subject was basically a rant against many vendors who were unwilling to offer vulnerability details. Every now and then I would review and update it a bit, but I never got to the point of actually posting it. I figured it wouldn't do much good in the grand scheme of things and the mere act of updating it provided adequate cathartic relief that a public post was not required.  There has been some recent developments, however that has allowed me to dust off my post and to put a "kudos" spin on it :)

I have long been a proponent of providing options for people to mitigate identified vulnerabilities.  We all realize that the traditional software patching process takes way too long to complete and push out into production when considering that the time it takes for the bad guys to create worm-able exploit code is usually measured in days.  When you combine this with most vendor's vulnerability disclosure policies (which is essentially not to disclose any details), then it is obvious that the bad guys have a distinct advantage in this particular arms race...

Ideally, all vulnerability researchers would work with the vendor and they would jointly release details with patches and then customers would immediately implement them on production hosts.  Unfortunately, reality is much different.  Researchers often have their own agendas and decided to release vulnerability details on their own.  In these cases, the end users have no mitigation options provided by the vendor and are thus exposed to attacks.  For those situations where the researchers and the vendor work together, then the end user at least has fix that they can apply.  The problem is that the standard time-to-fix for organizations to test and install patches is usually a couple months.  So, the vendor has pushed the pig over the fence onto the customer and essentially takes a "it's now your problem now" approach.

What would be useful would be some technical details on the vulnerabilities that are addressed within the patches.  Let's take a look at Oracle's position on public disclosure.  The fact that this is Oracle is irrelevant as many vendors share this same view and that is that they don't want to disclose any technical details of a vulnerability BEFORE patches are released.  I really can't fault them for this stance as they want to ensure that they have patches ready.  What I am focusing on here is when they have a patch set ready, they should provide enough technical details about the vulnerability so that an organization can implement some other mitigation options until the actual patches are installed.  Unfortunately, the vendors position is that they didn't want to release the details as to prevent the bad guys from obtaining the info.  What they are missing, however, is that both the good guys (Sourcefire, iDefense, etc...) and the bad guys are reverse engineering the vendors patches to uncover the details about the vulnerability.  The only people who don't have any details are the end users.

So the point is that Pandora is already out of the box when vendors release patches.  What they should do then is to give technical details for security folks to implement some defenses (for IDSs/IPSs).  A great example of this is when bleeding edge/emerging threats folks would create Snort signatures so that an organization can identify if someone is attempting to exploit a flaw.

Now, the whole point of this post is to highlight that I have fighting the good fight with many vendors to try and get them to see the light on the value of either releasing technical details on web-based vulnerabilities so that end users can create virtual patches with a web application firewall, or even better, for the vendor to release some virtual patches themselves (using the ModSecurity rules language)!  Well, we haven't achieved the latter one yet but we are seeing signs that both Oracle and Microsoft are starting to address the former.  Specifically, Oracle/BEA recently released details about a WebLogic plug-in for Apache and in the mitigation section they actually mentioned the use of ModSecurity to address the problem!  That is a huge step and something that I am extremely excited about.  Then just within the last week we saw the announcement of Microsoft's Active Protections Program (MAAP).  Here is the short overview -

The Microsoft Active Protections Program (MAPP) is a new program that will provide vulnerability information to security software providers in advance of Microsoft Corp.’s monthly security update release. By receiving vulnerability information earlier, security software providers can give customers potential improvements to provide security protection features, such as third-party intrusion detection systems, intrusion prevention systems or security software signatures.

This is certainly an interesting initiative and may help organizations to receive more timely mitigation options to help protect themselves until the official patches are deployed.

Overall, I have have say GREAT job Oracle and Microsoft for truly helping your customers to close their time-to-fix windows.   

The ModSecurity Log Collector (mlogc) is used to send ModSecurity audit log data to a console or Breach Security appliance.  The final packaged release of ModSecurity 2.5.6 did not contain the mlogc source as it should have.  This means that a "make mlogc" will fail.  However, the mlogc source is also packaged separately and can be downloaded from Breach Labs (https://bsn.breach.com/downloads/mlogc/).  Please use the source from Breach Labs to build mlogc until the next release of ModSecurity.

Breach Security (also known as the company behind ModSecurity) is organising an OWASP/WASC party at Black Hat US again this year, but if you are a ModSecurity user we are going to call it a ModSecurity party. See below for details.

2nd Annual Shadow Bar Cocktail Party

Once again Breach Security, OWASP and WASC are hosting the Shadow Bar
cocktail party during BlackHat at Caesar's Palace. Join us for great
food, great people and of course the Shadow Bar entertainment.

When:   Wednesday, August 6, 7:30 PM - 9:30 PM
Where:  Shadow Bar, Caesar's Palace, Las Vegas

RSVP:   Please stop by the Breach Security booth to pick up your
wristband which will give you entrance to the Shadow bar.

We have just released ModSecurity 2.5.6 to address several issues with transformation caching: the subsystem is unstable, can crash your server server, and is even susceptible to evasion in certain circumstances. Although the issues have all been fixed in 2.5.6 we have decided to deprecate the entire subsystem because there has been too many problems with it. If you are using the 2.5.x branch of ModSecurity you are advised to turn transformation caching off (it is on by default until 2.5.6) until you upgrade. You can do this with:

SecCacheTransformations Off

On the positive side, ModSecurity 2.5.6 is the first version to use the previously discussed licensing exception, which allows ModSecurity to be combined with other open source projects.

Although Solaris has been supported as a platform for ModSecurity since the very beginning, it has now become part of Sun's Cool Stack:

Cool Stack is a collection of some of the most commonly used open source applications optimized for the Sun Solaris OS platform. By using these binaries you will enjoy the best levels of performance from your system, while also reducing your time-to-service.

A revised version (but still a draft) of the Enough With Default Allow in Web Applications! paper is now available for download. (My previous post on this topic is here.) The major changes in this version include:

1. Decided to use a flat model of resources, rather than a hierarchical one, after realising the nested approach would make models very difficult to read for any non-trivial application. Also, we wanted to support the virtual patching case, which doesn't work with nesting very well.
2. Behaviours can now specify character encodings, which is very important in order to properly parse parameters.
3. We've allowed for a per-model data dictionary, which would allow parameter types to be defined once and reused throughout the model.
4. Many clarifications and small fixes throughout.

Update (4 Aug 2008): Updated links to point to the final version (spell-checked, reviewed and branded) of the paper.

There are three aspects of the ModSecurity Rule Language we are not very happy with. One comes from a wrong design decision (my own), with further two from constraints of working within the framework of Apache. All three break the principle of the intuitive action being the expected one. I am going to document them here and explain how we are planning to mitigate them in future versions:

1. In a chain starter rule, disruptive actions are processed when the chain matches, but non-disruptive actions are processed when the rule matches. In other words, it is only the disruptive actions that are treated differently in chains, all other action types behave as they would in standalone rules. Have a look at the following:
   
   

   SecRule T1 K1 chain,log,block,setvar:tx.counter=+1
   SecRule T2 K2

   In the example above the counter will be incremented if the first rule matches even if the chain doesn't. The blocking action, although defined with the same rule, would only be processed if both the first rule and the second rule match.
   
   In retrospective, disruptive actions for chains should have been placed with the last rule in a chain, not with the first one. If it is possible to move to that mechanism in the next major version while preserving compatibility with existing configurations we will do that.
   
   
2. SecDefaultAction is valid only for the configuration context in which it is used and is not inherited in child contexts. Configuration contexts are an Apache feature and they come with limitations, one of which is causing this problem.

   SecDefaultAction log,deny
   SecRule T1 K1
   <Location /some/other/path>
   SecRule T2 K2
   </Location>

   In the above example, the first rule blocks, but the second one just uses the ModSecurity defaults and only warns and lets requests through.
   
   In the next major version of ModSecurity (v3) we will handle our configuration ourselves and this problem will probably go away. In fact, the SecDefaultAction directive might be made obsolete in the next major version because we don't like it much. In retrospective, it was a wrong choice too. It is good practice to write rules to be self-contained. That way they will be easier to understand and maintain, and you don't risk configuration errors due to something being changed in the configuration elsewhere.
   
   
3. Configuration contexts other than <VirtualHost> cannot hold phase 1 rules. Again, this is a limitation of the current implementation that relies on Apache for configuration functionality.
   
   Short term (e.g. 2.6), we are planning to see if we can detect phase 1 rules in places where they cannot be run and respond with an configuration error. The problem will go away once we start handling our own configuration.

The title of this blog post is also the title of a research paper we are currently working on. Although the paper is still in draft form, we've decided to circulate it widely (download here) because we believe a public exposure in this early stage would benefit it significantly. Also, as you will see from the paper, for the proposed concept to succeed it must have support from many diverse groups of users. What do we want to achieve? Let's look at the summary:

The default allow deployment model, which is commonly used to implement
and deploy web applications, is the cause of numerous security problems. We propose
a method of modelling web applications in a platform-agnostic way to adopt
a default deny model instead, removing several classes of vulnerability altogether
and significantly reducing the attack surface of many others. Our approach is best
adopted during development, but can be nearly as efficient as an afterthought, or
when used at deployment time.

Our main problem is with these three things:

1. HTTP (in a wider sense, taken to mean all specifications needed to develop and deploy web applications) has grown to be quite complex, but although applications generally use a very small subset they are still expected to support every single feature.
2. Many applications are treated as simple collections of files (if it's on the filesystem it's part of application), and this is creating all sorts of issues.
3. Applications do not specify their external interfaces. This is really a consequence of the above two problems. Applications cannot specify external interfaces because they are all implicit.

The bottom line is that we have a chance to create a beautifully positioned protection layer (between web servers and applications), which would not only increase security overall, but turn applications into verifiable components with external contracts that can be enforced.

We propose a use of a platform-independent format to document what applications are willing to accept from the outside world, with the following use cases envisioned:

1. Creation of full application models, which reduce application attack surface. Such models can be created by application developers (which is preferred) or by application users (which, we expect, could happen with very popular and/or open source applications).
2. Creation of partial application models for use in virtual patching.
3. Automated creation of application models through traffic analysis.

In addition to the paper itself, we are planning to release an open source profiling tool (which I will announce next week) to help with the third use case and automate the creation of positive security models (also known as the learning feature of web application firewalls).

Download Enough With Default Allow in Web Applications!

Update (4 Aug 2008): Changed links to point to the final version (reviewed, spell-checked and branded) of the paper. The follow up post is here.

My list of web application firewall use cases continues to involve. I've decided to shuffle things somewhat:

1. I am going to remove the "Network building blocks" use case because that is really a feature of reverse proxies. If a WAF happens to be implemented on top of a reverse proxy that it will also inherit all of its benefits (and downsides, I should mention). In retrospective, I thought the two (reverse proxies and WAFs) should really stay separate.
2. I am going to add "Learning" as a new use case. As I was looking at the previous list of use cases it stroke me that I was failing to convey the ability of web application firewalls to understand what is going on, and this is what learning does.

Note: This post is part of the Web Application Firewall Concepts series.

We all agree that cross-site scripting is a serious problem, but what continues to amaze me is the lack of good documentation on the subject. It is easy to find instructions how to execute attacks against applications vulnerable to XSS, but finding something adequate to cover defence is a real challenge. No wonder programmers keep making the same errors over and over again. I am sure that one page that describes the problems and the solutions is somewhere out there, but I have been unable to find it. All I am getting is a page after page after page of half-truths and partial information, and even people saying that XSS is impossible to defend against.

Without any planning (so please forgive any omissions), I am now going to write how to produce web applications that are safe against XSS and other injection attacks.

This is what you need to do:

1. Identify all system components other than the application itself. In a typical web application you will have at least the following:
   
   1. Database
   2. Browser output, which further consists of:
      
      1. HTML
      2. JavaScript
      3. CSS
      4. Response headers (e.g. redirection, cookies, etc)
2. Adopt one character encoding (use UTF-8 unless you have a good reason not to) and make sure all components are configured to use it:
   1. Databases typically need to be created with a character encoding in mind
   2. In the HTML pages you create, set the character encoding explicitly
3. Then, for every component:
   1. Identify safe characters
   2. Identify how to make unsafe characters safe by converting them into something else
   3. Write a function that looks at characters one by one to determine if they are safe, and converts those that are not (whitelisting, not blacklisting!)
   4. Every such function must be aware of the character encoding used in the application
4. Then, for every piece of code that sends data from one component into another, make sure you use the correct function to encode data to make it safe
5. Check that every piece of data you receive is in the correct character encoding and that the format matches that of the type you are expecting (input validation). You must use whitelisting (as blacklisting does not work). This is especially important for user-supplied Internet addresses—see below for details. Before you do anything with the input data make sure to canonicalise it (as suggested by Jim Manico in one of the comments), which will reduce the possibility of evasion through the use of multiple representations of the same character.

The first 4 steps from the list are the actual XSS defence. The fifth item is a matter of good practice and does not directly protect against XSS in most cases. In fact, there is only one case where it does protect, and that is in preventing attackers from executing JavaScript code in data pretending to be an Internet address (e.g. instead of http://www.example.com, which you use to create a link <a href="http://www.example.com">Example</a>, you get javascript:alert('xss').

Notes:

1. Google Doctype, which is a reference library for web developers, is by far the best resource on XSS, but it too fails when it comes to defence, advising people to use blacklisting instead of whitelisting.
2. The OWASP Encoding project should be your starting point if you don't want to write all the encoding function yourself.
3. For the cases when you want to accept some HTML/JavaScript/CSS you will need to adopt a different approach: meet AntiSamy.