ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: June 2007

ScallyWhack: ModSecurity Rules Package to Deal with Trac Comment Spam

Michael Renzmann wrote to the ModSecurity mailing list recently announcing project ScallyWhack. It's a set of rules specially designed to detect comment spam against Trac installations. This is interesting for several reasons. It's a project with potential to be very useful for many people running Trac, it appears to be well thought out and well designed, but it is also the first independent project to focus on writing rules to fit a purpose. First of many I hope!

Another ModSecurity Development Release

Last week I released the second ModSecurity development release, 2.5.0-dev2, in preparation for the next version of ModSecurity.  Some may notice that this version is now 2.5.x where as the first development release was 2.2.x.  Ivan and I decided that because of the large feature sets going into this next release we would bump the version to 2.5.x to signify a halfway point to 3.0.0.  This release is primarily a performance enhancement release, so I want to introduce two of the main new features in more detail.

In this release, I have introduced a phrase matching operator (@pm) to match against a list of phrases.  The new operator uses the Aho-Corasick algorithm and   is many times faster than the default regular expression operator (@rx) for lists of OR'd phrases.  For example, if you want to accept only GET, POST and HEAD requests the following rules are equivalent, but the second is faster (even more so as the list grows):

SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" t:none,deny
SecRule REQUEST_METHOD "!@pm GET POST HEAD" t:none,deny

The new @pm operator should be used for static lists of phrases (black/white lists, spam keywords, etc).  However, for large lists, this new operator may cause the rule to become difficult to read and maintain.  If your lists are large, you can use an alternate form (@pmFromFile) that accepts a list of files and place the phrases into a file or multiple files (one per line) instead of inline.  In this form, the phrase file(s) will be read on startup.  To allow for easy inclusion of third party phrase lists, if the filename is given with a relative path, then ModSecurity will look for it starting in the same directory as the file that contains the rule specifying the file.  For example:

SecRule REQUEST_METHOD "!@pmFromFile allowed_methods.txt" t:none,deny
### And in allowed_methods.txt in the same directory:

Another performance enhancement (that is still being tuned) is transformations are now cached for each transaction.  With previous versions of ModSecurity, the transformations for each rule were applied in the order specified to the original value.  This was done for every variable in every rule.  Starting with ModSecurity 2.5.0-dev2, transformations will only be performed once for each transaction.  If more than one rule uses the same transformed value, then the cached value is used instead of reapplying the transformations.

As always, the source code is available in the download section of the ModSecurity Website.  Below is an outline of the new features and changes in this release so far.  Please see the documentation included in the release for full details and usage examples.  Please direct any comments to the ModSecurity User Support mailing list.

Major Changes Since Version 2.1.1

  • Added new phrase matching operators, @pm and @pmFromFile.  These use an alternate set based matching engine (Aho-Corasick) to perform faster phrase type matches such as black/white lists, spam keywords, etc.
  • Cache transformations per-request/phase so they are not repeated.
  • Added @within string comparison operator with support for macro expansion.  This was discussed as @contained on the user list, but this seemed too similar to @contains.  This operator looks for a variable value within the operator value (opposite of @contains which looks for the operator value in the variable value).
  • Fixed issue with requests that use internal requests.  These had the potential to be intercepted incorrectly when other Apache httpsd modules that used internal requests were used with mod_security.
  • Fixed decoding full-width unicode in t:urlDecodeUni.
  • Added matching rule filename and line number to audit log so that it is much easier to figure out which rule caused an alert to be generated.
  • Enhanced PDF protection allows a choice of forced downloads (of PDF files) or use of token redirection.
  • Various other bug fixes and smaller changes.  See the CHANGES file and/or the ModSecurity Reference Manual in the release for more details.
  • Experimental support for content injection.  You can use @prepend value and @append value to inject content into the output.
  • PDF XSS protection added.
  • Geographical lookups by IP address/hostname were added.  With this you can access the country, city, postal code, etc. -- within a new GEO collection -- from any existing ModSecurity variable by using the new @geoLookup operator.
  • String comparison operators -- @streq, @beginsWith and @endsWith -- to allow an easier-to-use non-regular expression operator.  Values will have macros interpreted prior to a match, so that you can do "@streq %{REMOTE_ADDR}", etc.
  • A length transformation -- t:length -- transforms a value into a numeric character length.
  • Whitespace trimming transformations are now available.  Use t:trimLeft, t:trimRight or t:trim to trim whitespace from the left, right or both, respectively.
  • Added the filename and line number of the rule to the debug log on its execution.  I will add it to the audit log in the next development release.
  • Removed support for CGI style HTTP_HEADER_NAME variables for request headers.  The 2.x REQUEST_HEADERS:Header-Name should now be used.
  • Removed support for %0 - %9 TX variables that expanded to numbered captures.  Use %{TX.0} - %{TX.9} instead.
  • Various other bug fixes and smaller changes.  See the CHANGES file in the release for more details.

Apache Process Infection

A very interesting research paper titled "Apache Prefork MPM Vulnerabilities" was released a few days ago, as you can see in the corresponding Bugtraq post. The paper describes, in detail, the dangers of allowing third-parties to run code under the same account as the Apache web server. This normally happens when dynamic content is produced using Apache modules (e.g. PHP) or when CGI scripts are configured to run without suEXEC. This topic itself is not new. You will find several articles on runtime process infection following this Google search link. I warn about this problem throughout my book and especially in Chapter 6, which is dedicated to those situations when more than one party is using the one Apache installation. However, it is one thing to know that something is possible and another to demonstrate, step by step, how it is done. Another interesting finding resulting from this paper is that it is possible to send a SIGUSR1 signal, as root, to any process on the system instead of just to Apache children processes. This is an issue that will have to be fixed in one of the future versions of Apache.

This problem with running code as the same identity as the web server is well understood (and has been for years) among the advanced Apache users. The solution is to always execute CGI scripts through suEXEC and to never allow third parties access to any of the modules. The real problem is that, as with any other product, there are few people who understand Apache inside out (and they can protect themselves) but there also those who are using the technology but do not have the luxury of learning everything there is about it (and there are many legitimate reasons for that).

The solution is obvious. Apache must be safe out of the box! We should dispense with the idea of running things in the same process. Process isolation facilities (either suEXEC or something else) should be installed and running by default on all installations. We can and should make provisions for those who know what they are doing to shoot themselves in the foot, of course. But the only reason to attempt to run things in the same process is performance and I suspect, in this day and age, virtually all users will be happy with the performance of their web server doing things in a secure manner.

Optimizing Regular Expressions

As many of you have noticed, the Core Rule Set contains very complex regular expressions. For example:


These regular expressions are assembled from a list of simpler regular expressions for efficiency reasons. A single optimized regular expression test takes much less time than a series of simpler regular expression tests. The downside is readability and ease of editing. A future version of ModSecurity will overcome this limitation, but meanwhile, in order to optimize performance you have to think about optimization yourself.

Manual assembly and optimization is both hard and error prone, so for the Core Rule Set we use a clever Perl Module: Regexp::Assemble. As the name suggests, Regexp::Assemble knows how to assemble a number of regular expressions into one optimized regular expression.

Since Regexp::Assemble is not a program, but rather a Perl module, you will need some glue code to use it. The following instructions will help you if you are not Perl Wizards.

If you don't have Perl, you will need to install it. The easiest Perl distribution to install, especially if you use Windows, is ActivePerl.

Now install Regexp::Assemble. If you used ActivePerl, you can use the following command:

ppm install regexp-assemble

If you use another Perl distribution, you will need to download the module and use the normal Perl module installation procedure as outlined in the README file.

Once you have Perl and Regexp::Assemble installed, all you need is this little script:

use strict;
use Regexp::Assemble;

my $ra = Regexp::Assemble->new;
while (<>)
print $ra->as_string() . "\n";

The script will take either standard input or an input file with each line containing a regular expression and print out the optimized expression: simple_regexps.txt > optimized_regexp.txt

On a Unix system you might need to change the fist line to point to the local Perl interpreter. On Windows you may need to precede the script name with the command 'perl'.

And if all this is too complex, you can just download the pre-compiled version for Windows.

Managing ModSecurity Alerts: More Console Tuning

In a previous Blog entry, I outlined a number of steps that you could take to increase performance of the ModSecurity open source Console. While these tuning steps will certainly help to increase performance, there is still one big issue that will bring the open source Console to its knees - too many open/active alerts in the Alert Management interface (where the URL is - https://ip_of_your_console:8886/viewAlerts). Having too many open alerts will chew up the available memory for the MUI and it will become unresponsive.

If you are in the scenario where you already have too many active alerts and the MUI is totally non-responsive, you may have to try and bypass the MUI and instead use the Java Derby DB client to interact directly with the DB listener and close the active alerts.

Removing Too Many Existing Alerts from the MUI

Here are the steps:

  1. Stop the currently running console with -
    # ./modsecurity-console stop

    You should then check the "ps" output to ensure that the Java process is not hanging. If it is, you may need to either re-execute that command or issue a kill command to that specific process number.

  2. Enable remote access to the database by editing console.conf and changing the startNetworkServer setting to "true". You will need to use the same username/password when connecting later with the Derby client.
    <Service derby com.thinkingstone.juggler.components.DerbyServer>
        Property password "XXXXX"
        Property startNetworkServer "true"
        Property host ""
        Property username "XXXXX"
        Property port "1527"
  3. Restart the console with -
    # ./modsecurity-console start
  4. Verify that the DB listener is up and running on port 1527 with -
    # netstat -nlp | grep 1527
  5. CD into the modsecurity-console/lib/ directory and then start the
    java commandline utility like this -
    java -classpath derbyclient.jar:derbytools.jar -Dij.driver='org.apache.derby.jdbc.ClientDriver'
  6. Connect to the Derby DB like this (make sure to substitute your Host:port and username/password info) -
    connect 'jdbc:derby://HOST:PORT/consoleDb;username=USER;password=PASS';
  7. To close all open active alerts -
    UPDATE alerts SET alert_status = 'CLOSED' WHERE alert_status = 'OPEN';
  8. Then restart the modsecurity-console -
    # ./modsecurity-console start
  9. Attempt to access the MUI

Is There A Better Way To Manage Alerts?

If you are becoming frustrated with the performance of the open source Console and/or if you have more then 3 ModSecurity sensors to manage, you may want to consider taking a look at Breach's commercial ModSecurity Management Appliance that was just recently made available. It has many significant performance increases and is an enterprise class solution (it can manage up to 50 ModSecurity Sensors).

Extended Validation Certificates: A Change for the Better (But Not Enough)

On June 12th, 2007, the CA/Browser Forum (a group that consists of leading certificate authorities and browser vendors) ratified the first version of the Extended Validation (EV) SSL Guidelines. The goal of the guidelines is to introduce a new type of certificate, Extended Validation Certificate, with intent to standardise the certificate issuance process.

Those of you that remember the early days of SSL certificates will find that the "new" process is pretty much identical to the one we had to undergo years ago. Things such as verifying legal existence, identity, registration number, right to use the domain name--are all there. There is one crucial difference, though. This time the process is mandatory whereas before, it turns out, it was merely a matter of choice. No wonder the quality of the vetting had deteriorated over the years as companies fought for the market by lowering prices.

There are many who do not like the new Extended Validation Certificates. They usually say the new type of certificate will not solve our problems. And that they are merely a way for the certificate authorities to extract more money from their customer base. While I agree with the former, I do not necessarily agree with the latter (but this is not to say the CAs will not be happy to collect the extra funds).

The point is that a solid vetting process should have been a mandatory requirement from the start. The fact that we missed the opportunity to do the right thing then does not mean we have to continue living with the mistake. It is true--the new certificate does fall short of solving our problems. But, guess what, that was never the intention. Citing from the EV Certificate Guidelines (page 13):

(c) Excluded Purposes EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:
  1. That the Subject named in the EV Certificate is actively engaged in doing business;
  2. That the Subject named in the EV Certificate complies with applicable laws;
  3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or
  4. That it is "safe" to do business with the Subject named in the EV Certificate.

SSL certificates have nothing to do with trust. (Admittedly, it's a fact we didn't fully appreciate when they were introduced.) Their purpose is simply to identify the party on the other side of the communication channel. For trust we need to turn to other methods. Actually, we developed perfectly good methods to do this in real life. For example, most people take into account the brand name of the store or that of the manufacturer. You are going to be very comfortable buying from Amazon because you know the company. By the same token, you are probably going to think twice before buying from a badly-designed, badly-built web site you've just run across.

There is one aspect where Extended Validation Certificates fall short, and that's the implementation and the changes in the browser user interfaces. To accommodate the new type of certificate browsers have resorted to displaying the sites protected with such certificates in a slightly different way. There are two problems with this. One is that a normal user stands to gain very little from the change. The other is that, even for the small gain that can be achieved, a huge marketing effort is going to be required to explain the difference. This effort is not only going to be expensive but also take time--a lot of time. It something we can successfully do maybe once or twice in a decade. The EV Certificates are simply not worth it.

A far better solution would have been to, slowly and quietly, reform the certificate issuance process. Let the old certificates expire and start issuing better ones today. While that is happening figure out a way to deal with our real problems and inform the normal Internet users only once we are happy we've done the right thing.

Universal PDF XSS Revisited

The Universal PDF XSS vulnerability was a tipping point for most people involved with web application security. Now we know the Web will never be secure for as long we continue to use the exact same technologies we have in use today.

It so happened that I was swamped with work back in January when the news about the Universal PDF XSS had broken out. I kept my eye on the topic during the initial discovery period but I went back to it a month later to give it the attention it deserves. I discovered that the topic received a tremendous amount of interest initially but that the interest died shortly thereafter. The vulnerability was old news in February although there was much more to say.

My presentation, Protecting Web Applications from Universal PDF XSS, aims to be the one place where you can learn everything you need to know about this problem. It also points to an emerging trend of collaborative vulnerability research and briefly discusses its advantages and disadvantages. (As a sidenote, I find the trend very exciting and will probably revisit the topic here again.)

I gave the presentation at the OWASP conference in Milan in May but it has been updated since (so don't download it from the conference agenda page). You can download the latest version on the OWASP web site, from the web page dedicated to the problem. I will be giving the same talk later this month (June 22) for the OWASP Belgium-Luxemburg chapter.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries