Archive for the ‘ModSecurity’ Category

Extracting bad url’s from ModSecurity events in Sguil

Thursday, January 15th, 2009

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

Wednesday, July 16th, 2008

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

Wednesday, March 26th, 2008

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!

New security weblog by Ivan Ristic

Tuesday, January 22nd, 2008

I just noticed that ModSecurity developer Ivan Ristic has started a new blog on computer security and open source. Check it out here: http://blog.ivanristic.com/

Great idea Ivan! :)

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

Thursday, October 11th, 2007

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

Monday, August 27th, 2007

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})$”

Using Modsec2sguil for HTTP transaction logging

Wednesday, August 15th, 2007

Modsec2sguil is currently configured to send alerts to Sguil. ModSecurity can be configured to log any event or transaction, including 200 OK, 302 Redirect, etc. Modsec2sguil distinguishes between alerts and other events by only processing HTTP codes of 400 and higher. Since 0.8-dev2 there is a configuration directive to prevent certain codes, such as 404, from being treated as an alert.

Now I have the following idea. Since ModSecurity can log all events with details of request headers, response headers and POST message body, it may be interesting to just send all these events to Sguil. They should not be appearing as alerts, but having them in the database can perhaps be interesting. I know using flow data and full packet captures the same data can be accessed, but having it in the database makes querying it a lot easier and longer available.

Possible problems are mostly the performance hit the webserver may take for sending all these events to Sguil and the storage requirements in Sguil’s database. I estimate the events are about 1kb in size on average, so on a busy site this may cause the database to grow very rapidly. Of course this behavior would be optional so it can be disabled.

Any thoughts on this idea?

First Modsec2sguil release for Sguil 0.7-CVS

Tuesday, August 14th, 2007

I just uploaded a new version of Modsec2sguil. I’ve been working on it the last weeks to get it updated to Sguil 0.7. The scripts are changed all over the place. This is because in the 0.7 framework, my scripts would no longer be a replacement for Barnyard only talking to the sensor_agent on the localhost, instead now it would become a full agent talking to the Sguil server directly.

This brings some challenges. First the connection can be going over the internet, or another untrusted network, so the agent needs ssl support. Second, since the connection may be unreliable we need to be able to detect and deal with lost connections. Next to this I wanted to be able to run without superuser privileges.

The new version of modsec2sguil supports it all, and more:

  • Converted into a real agent for Sguil 0.7 (no more barnyard replacement)
  • Agent can drop privileges
  • Agent can daemonize
  • Pinging the server is supported
  • The agent reconnects to the server if the connection is lost
  • Agent supports SSL for the connection to the server
  • A sguil-compatible configuration file is now used
  • A debug mode was added

So if you run Sguil 0.7-CVS and ModSecurity, go check it out at http://www.inliniac.net/modsec2sguil/

Last but not least, the agent contains a SguilAgent.pm Perl library. I hope it enables developers to easily create Perl agents for Sguil. If you need help with that, please let me know!

Sguil 0.7 CVS installation on Debian Etch

Tuesday, June 12th, 2007

Sguil 0.7 is getting shape quite nicely. One of the most interesting new features is the splitting up of different types of agents and the option to create ‘net groups’. This are groups of agents that Sguil considers part of the same network. You can use this to spread the agents over multiple servers, but still use it from Sguil as if it was one single sensor. For example, this way you can easily create a Snort sensor and a separate full content logging capture server. When you request the full content for a Snort event in Sguil, it will know that it needs to request the packet data from the capture server. This way you can also have multiple Snort agents without the need for capturing the same sancp and full content data over and over again.

David Bianco has written a very nice guide for installing Sguil 0.7 on Redhat Enterprise 4. I used this guide to install the server and sensor on a Debian Etch installation. The main difference is that I used Debian packages where ever possible. These packages could be used:

mysql-server
p0f
tcpflow
tcllib
mysqltcl
tcltls
tcl8.3
tclx8.3

Important: do not use the tcl8.4 package. It is not compatible with Sguil and will produce the following message:

ERROR: This version of tcl was compile with threading enabled. Sguil is NOT compatible with threading.
SGUILD: Exiting…

You can get Sguil 0.7 CVS by checking out the latest CVS version:

cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil login
cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil co sguil

I will update Modsec2sguil soon!

ModSecurity IRC channel

Wednesday, May 16th, 2007

Since a few weeks there is an active IRC channel for ModSecurity. It’s hosted on the Freenode network. The channelname is #modsecurity.

Join us there! :)