ModSecurity Blog: ModSecurity

ModSecurity versions 2.5.8 and 2.5.9 have been released to fix two vulnerabilities which could be used to cause a denial of service (DoS).  The first vulnerability is fixed in version 2.5.8 and the second (as it was disclosed after version 2.5.8 was already frozen) is fixed in version 2.5.9.  Because of this, the 2.5.8 release should be disregarded in favor of 2.5.9.  Both vulnerabilities, however, have workarounds until ModSecurity can be upgraded/patched.

Vulnerability in the PDF XSS engine

The ModSecurity PDF XSS protection engine prior to version 2.5.8 would allow a NULL pointer to be dereferenced when a non-GET request was used to generate a PDF.  This would cause Apache to crash and allow for a denial of service (Low Risk).

As a workaround, you should disable PDF XSS protection (the default), such as in the following example, until an update to ModSecurity is in place.

SecPdfProtect Off

Vulnerability in the multipart request parser

The ModSecurity multipart request parser prior to version 2.5.9 would allow a NULL pointer to be dereferenced under some circumstances when a zero length part header name is used.  This would cause Apache to crash and allow for a denial of service (Med-High Risk).

As a workaround, you should disable multipart/form-data parsing and add a rule to detect exploitation, as in the following example, until an update to ModSecurity is in place.

###
# BEGIN TEMPORARY WORKAROUND
#
# Force URLENCODED processing so that the vulnerability is bypassed
# and the REQUEST_BODY target variable is populated, but at the 
# expense of no longer being able to parse multipart form arguments.
SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" \
 "phase:1,t:none,t:lowercase,nolog,pass,ctl:requestBodyProcessor=URLENCODED"
#
# Deny any multipart requests with a zero length header name
SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" \
 "chain,phase:2,t:none,t:lowercase,deny,msg:'ModSecurity DoS attempt - NULL part header name'"
SecRule REQUEST_BODY "(?m:^--.*\\x0d\\x0a?:.*\\x0d\\x0a?--)" "t:none"
#
# END TEMPORARY WORKAROUND
###

More details can be found in the CHANGES file within the released source packages.  Special thanks to those at Red Hat and Internet Security Auditors for disclosing the vulnerabilities.

Both of these are excellent examples of how ModSecurity can be used to provide a virtual patch before an upgrade and/or proper patch can be applied -- even a vulnerability within ModSecurity itself.

Deciding to leave a job is rarely easy, but leaving your job and the project you've nurtured for six years is very difficult. In a few weeks' time I will no longer be working for Breach Security and, as a consequence, I will be joining the ModSecurity community as a user. I leave ModSecurity in the capable hands of Brian Rectanus, who has been taking care of it for some time now.

It's been an exciting journey, starting ModSecurity and growing it for all these years. It's been a pleasure working with the community and helping others solve their problems. It's been hard at times, but that made it all the more interesting.

Finally, I would like to take this opportunity to thank every single ModSecurity user, because we, all together, made ModSecurity what it is. I couldn't have done it without you.

I spent the last week importing ModSecurity's source code repository into subversion at Source Forge. I am proud to announce that a read-only version of ModSecurity's subversion repository is now publicly available. In addition to this, Atlassian has graciously given the ModSecurity project a license to use their software. We are currently using Jira to track reported issues, FishEye to track and analyze the code repository and have plans to add Confluence (a wiki) in the near future. Together, these tools allow users to test and apply fixes immediately as well as monitor the progress of reported issues and the progress of ModSecurity as a whole.

This is a big step forward for the ModSecurity project. The project is becoming much more open and feels more like an Open Source project should. Please take some time to look at the new tools. Comments are always welcome.

This year, the OWASP's Summer of Code event contains one project that's of particular interest to me (and possibly to you, consider that you're following this blog): Securing WebGoat Using ModSecurity. If you've even seen WebGoat (a learning sandbox that contains samples of many application security issues) then you know how difficult it might be to secure. It's true; it's probably the worst-case scenario for ModSecurity, because it's not your typical application, and it contains a number of problems that require the understanding of application state to exploit (and thus protect too). So we should all congratulate Stephen Evans for pulling through and reaching the end of the project.

I find the project interesting because it stretches the boundaries of what ModSecurity can do. For example, one of the features Stephen relied heavily on is the Lua scripting language, which is currently marked as experimental. As we are currently working on the design for ModSecurity 3, Stephen's feedback is going to be very useful to us.

If this sort of thing is indeed of interest to you then you need to know that Stephen will be sharing his experiences during the OWASP Summit in Portugal next week. If you'll be attending the summit (or even if you can schedule a trip on short notice) do consider attending.

Intrusion detection is a well-known network security technique--it introduces monitoring and correlation devices to networks, enabling administrators to monitor events and detect attacks and anomalies in real-time. Web intrusion detection does the same but it works on the HTTP level, making it suitable to deal with security issues in web applications. This session will start with an overview of web intrusion detection and web application firewalls, discussing where they belong in the overall protection strategy. The second part of the talk will discuss ModSecurity and its capabilities. ModSecurity is an open source web application firewall that can be deployed either embedded (in the Apache HTTP server) or as a network gateway (as part of a reverse proxy deployment). Now in it's sixth year of development, ModSecurity is mature, robust and flexible. Due to its popularity and wide usage it is now positioned as a de-facto standard in the web intrusion detection space.

This is the same talk I presented at ApacheCon Europe 2008 in Amsterdam and the OWASP AppSec US 2008 conference in New York, and it's getting better every time I do it. This is going to be my first ApacheCon in the US and I am really looking forward to it. It's the place to be if you are involved in any way with the projects of the Apache Software Foundation.

I will be giving the updated version of our ModProfiler presentation this Sunday (14th) at the OWASP Israel 2008 conference. ModProfiler has seen a release or two since Black Hat (where it was announced) so I can now speak with more experience about some of the challenges of automated positive model generation.

Ofer (who is organising the conference, by the way) will be speaking about What's Hot in 2008, which is always an interesting and well-attended talk.

The conference schedule looks great, but, judging from the presenters' names alone, I doubt many will be in English. (Not that it matters, as I will have to spend the afternoon working, back at Breach Security's offices in Herzliya.) This conference is the first time that I've seen anyone discussing database firewalls (let alone an open source one) at an application security conference: Yuli Stremovsky will be discussing GreenSQL. We should have that sort of thing more often. In case you're interested, another similar project is Open Database Security and Monitoring Solutions (ODSMS).

Several years ago, a few more than I'd like to admit, I realised our chances for writing completely secure web applications are extremely slim; virtually non-existent. We can certainly try—and many are making heroic efforts—but nothing good can come out of matching humans, which are inherently prone to making mistakes, with insecure programming tools and libraries. That made me toy with the idea of having something else, external to web applications, work to increase their security levels. That something we are calling web application firewalls these days.

Nothing of the sort existed back then (at least nothing open source or easily available, and I didn't even know about the products that had existed), so I decided to start a new project and make it open source. ModSecurity was born. It's the best thing I've ever done, in more ways than one.

I designed ModSecurity for myself: a power tool for those who understand web application security and know what they want to do. It gained popularity over the years and, through the power of free and open source, become the most widely deployed web application firewall. Somewhere along the lines I decided that it was my goal to make the web application firewall technology available to everyone.

I am yet to succeed with this goal. Although the barrier to entry with ModSecurity is low in some ways (the product is free, after all) it's not in others. ModSecurity is a low-level tool: it's very powerful but requires knowledge and, for many tasks, a significant time investment. The real challenge, it turns out to be, is building an easy-to-use tool that yields good results with only a modest time investment. Thus we (I and my colleague, Ofer Shezaf) decided to start a new effort, which we called ModProfiler. It's an tool that generates positive security rules learning from real-life traffic.

Policy generation through learning is a powerful technique, so it is surprising that there aren't many open source products that use it. In fact, to the best of my knowledge, there are none. One can find several very interesting research papers but, unfortunately, nothing for download, let alone production use.

Links:

• ModProfiler

[Note: This blog entry was written to pitch ModProfiler for a Black Hat US talk. Although ModProfiler was first discussed at Black Hat US in August, and version 0.1.0 published in the following week, we failed to announce the project properly due to lack of time.]

I am happy to announce that we've just launched a public issue tracking facility for ModSecurity. It's available at https://www.modsecurity.org/tracker/. We've selected JIRA for this purpose, not only because it is the best issue tracking product our there, but also because we were given a free licence. Atlassian, the company behind JIRA, is generously offering free licences to open source projects. I had used JIRA in a previous job, and have nothing but good things to say about it. I am happy now that we will be using it for my favourite project.

We've been using a private Trac instance to track ModSecurity issues for nearly two years now. There wasn't any particular reason we decided to go with a private system, apart that to run a public system required additional effort. However, you can't really have an open source project with a private issue tracking system, so the pressure to go public (which we've put on ourselves) eventually pushed the task to the top. Furthermore, we've noticed that there are people who are not using the latest version of ModSecurity. Naturally, you are not supposed to upgrade just because there's a new version out there, but we were lacking a facility that would enable our users to judge for themselves whether an upgrade is needed. For example, an upgrade that improves security might be justified, but an upgrade because of a feature you are not using is not likely to be.

Our new tracker is empty at the moment, but it will start to fill-up as we start to use it to plan future releases. The system is open for public registration, so feel free to use it to report the problems you encounter.

Issue tracking is just a start, by the way. The generous people of Atlassian have granted us free licences for all their products. FishEye, Confluence and Crucible are all candidates for installation in the near future.

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.