ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to http://blog.spiderlabs.com/modsecurity/.

ModSecurity Blog: June 2006

ModSecurity 2: Explicit Normalisation Options

One of the things I realy dislike in ModSecurity 1.x is that its anti-evasion features are implicit. A series of transformations is always performed on input data and always in the same order. This is somewhat convenient because it saves you from having to think about the evasion issues. This approach - implicit normalisation - is not foolproof (no surprises there). First, there are occassions where you need some other (sometimes peculiar) transformation to take place before you look at data. Second, the context in which input data is used *is* important. It is not always appropriate to perform a particular transformation - you might even be helping the attackers avoid detection (or prevention).

That's why, when I set to design ModSecurity 2.x, I came up with a flexible solution that allows one to configure normalisation features correctly in every possible sitation. The new capabilities do not come for free: ModSecurity 2.x is a better tool but it is also more difficult to use. Enough about that, let's discuss the improvements.

There are 19 normalisation functions documented in the ModSecurity 2.x reference manual. They are:

  1. lowercase
  2. replaceNulls
  3. removeNulls
  4. compressWhitespace
  5. removeWhitespace
  6. replaceComments
  7. urlDecode
  8. urlEncode
  9. urlDecodeUni
  10. base64Encode
  11. base64Decode
  12. md5
  13. sha1
  14. hexDecode
  15. hexEncode
  16. htmlEntityDecode
  17. escapeSeqDecode
  18. normalisePath
  19. normalisePathWin

The names of most are self-explanatory. (For the others refer to the manual.) By default ModSecurity 2.x will perform lowercase, replaceNulls and compressWhitespace on input data. If you need something else you will have to reconfigure this setting using the new action "t". As before you can use SecDefaultAction to set the defaults for all rules that follow:

SecDefaultAction log,auditlog,deny,status:403,phase:2,t:lowercase,t:replaceNulls,t:compressWhitespace

The above is an example of a default configuration. You can also have a per-rule setting, either by changing the normalisation options completely, or by adding or removing from the default configuration. Here's an example where "compressWhitespace" is removed and "replaceComments" added.

SecRule ARGS keyword t:-compressWhitespace,t:replaceComments

To completely replace the configured normalisation functions simly use the special name "none".

SecRule ARGS keyword t:none,t:normalisePathWin

And if the built-in normalisation functions are not enough for you there is good news - ModSecurity 2.x has an API that allows you to add a new normalisation function without having to touch its source code. (There are examples of this in the distribution.)

Secure Browsing Mode Proposal

It's very well known (and even widely accepted) that our current web application deployment model suffers from multiple security problems. We've done a lot to mitigate these problems over the years but there is only so much one can do when building on an insecure foundation. I have kept a list of things I'd like to see changed - I wrote about it this time last year.

Since then I placed my ideas in a somewhat coherent form and give it a name - Secure Browsing Mode. From the document:

It is widely accepted today that web applications are inherently insecure. A lot of energy was invested in the past years into making web applications more secure, but there is only so much we can do with the fundamentally insecure foundation. This brief document proposes a set of possible browser improvements that would allow us to establish, gradually, a secure environment for web applications.

Download PDF: Secure Browsing Mode

Apache Security in Japanese!

Apache Security in Japanese cover page

My book was translated to Japanese and published by O'Reilly Japan! This is, apparently, old news, as they did it back in 2005, but I only found out about it from the three-montly royalties statement I received in April.

While we are on the subject of writing, I am starting to get the itch again. There are two or three topics I would like to explore further. Topics such as web application firewalls and ModSecurity, web application security, and application security patterns. On the other hand, I have a few compelling reasons against writing another book:

  • It takes a lot of time (time better spent building Thinking Stone into a stronger business).
  • It's lonesome (but this can be dealth with by finding someone to co-author the book with me.
  • My hands and arms haven't fully recovered from the first book. (This one is the most compelling reason of all - I barely managed to finish Apache Security in the first place. If you are using keyboard extensively make sure to read about RSI and always keep Workrave active.)

Apache Programming Book On The Way!

I have been involved with Apache programming for several years now. During this time I've been following the main Apache development list and the module programming one. This is how I got to meet Nick Kew, probably the most helpful person on these two lists. (Perhaps on other lists too, but I only follow these two.) Rumours that Nick is writing a book (spread by the author himself) have been circulating for many months now. I am happy to say this is now official; Nick's book, Apache Programming (I am not sure if this is the official title or not) will be published by Prentice Hall in their Open Source Series. Nick has been kind to invite me to help him as a technical reviewer. This is great news for the Apache community! Apache is a fantastic web server but its growth is being slowed down by the lack of proper documentation for programmers. I only wish I had this book a couple of years back when I was starting with ModSecurity!

Jailing Apache On Windows

Yury Zaytsev wrote to me recently to tell me about his experiences in jailing Apache on Windows. Although, strictly speaking, Windows does not have the chroot system call or an equivalent it is still possible to do a pretty good job restricting its access to the system, as Yury demonstrates. From his email:

All you need is to make a local user, say, called "Apache" (you may even set him a password, don't think that makes any sense, but anyway) and deny him local and network login via group policies. Then you need to explicitly deny this user any access to the local drives (deny just everything: dir listing, read, write, modify etc), that's done via Properties - Security. Now any process spawned with "Apache"'s rights won't be able even to LIST the directories.

Now you've got to grant it the read/list folders access to the Apache Software folder (done via folder properties -> security) and write access to the PID file and log files (hopefully it doesn't need anything else).

And the last thing to do is to edit Apache's system service: you should change it's privileges via My computer - Manage workstation - Services - Apache from System service to "Apache" user (it might prompt you for the password if you've set any).

Reboot, check that Apache process is running as Apache user via the Task Manager, make sure everything is working fine and you're done.

This has also an important positive impact on the scripts security: now even if one manages to hack your poorly coded PHP/Perl script, since PHP/Perl is run via SAPI/mod_perl it couldn't list folders above Apache's root and even change any files you haven't allowed it explicitly inside Apache's root.

As you may see from above, my method is a complete rip off the Unix chroot (and chmod, he-he) technology. It's primitive and efficient (..er how efficient a Windows server can be comparing to Unixes?) Anyway it really saved my butt several times the script kiddies managed to exploit vulnerable PHP scripts.

Embeddable Web Application Firewalls and Impedance Mismatch

Some of you may remember I wrote about impedance mismatch that occurs between security layers. Ryan Barnett made an interesting post to the mod-security-users mailing list the other day:

Those of you running Snort in addition to ModSecurity undoubtedly saw the Snort URI rule bypass bug announced last week - http://www.demarc.com/support/downloads/patch_20060531.

I run both Snort and ModSecurity in my DMZ segment to identify/prevent HTTP attacks. They are a great compliment to each other as they are different tools - 1 a network-based IDS and 1 an embedded WAF within Apache.

Nothing highlights the differences between the 2 and how they handle HTTP data more than this type of vulnerability announcement. Snort is doing the best that it can to interrogate HTTP transactions however the fact is that it is not a web server so there will be mistakes made as it analyzes data. ModSecurity, on the other hand, is integrate into Apache and therefore does not fall victim to this type of HTTP evasion attack.

When this announcement was released, I quickly ran some tests between Snort and ModSecurity to verify that ModSecurity did in fact identify and block my requests with inserted "\r" return characters. Due to the fact that I use the Snort2Modsec.pl script to translate all of the Snort web attack sigs, I had absolutely zero loss of IDS coverage on my web servers while I upgraded/patched Snort :)

He makes an interesting point. It is obvious that running embedded has both positive and negative aspects. Being able to see exactly how web server parses requests is a positive one.

Calendar

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

Feeds

Atom Feed

Search

Categories

Recent Entries

Archives