Inliniac

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!

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!

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!

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.

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

Recently I wrote about the idea to log all HTTP transactions into Sguil using my Modsec2sguil agent. I’ve implemented this in the current 0.8-dev5 release and it works very well. All events go into Sguil smoothly and I’ve not experienced slowdowns on the webserver. I’ve been running it for almost a week now, like to share the first experiences here.

I find it to be quite useful. When receiving an alert, it is perhaps more interesting to see what else was done from that ipaddress than to see what was blocked (unless you are suspecting a false positive of course). One area I find to be useful is when I’m creating rules against comment spam on this blog. By seeing all properties of a spam message I can create better rules. For example on broken user-agents or weird codes inserted into the comment field of Wordpress.

It’s easy to search and filter on HTTP response codes because the code is a part of the RT message. For example, when searching for all HTTP 500 error codes, add the following ‘WHERE’ clause to a query:

WHERE event.signature like “%MSc 500%”

This works quite fast although you best limit the query on properties like date and port as well. To get all the HTTP code 500 alerts from the last days do something like:

WHERE event.timestamp > ‘2007-08-18′ AND (event.dst_port = 80 OR event.dst_port = 443) AND event.signature like “%MSc 500%”

One thing that is disappointing is the inabillity to search in the event payloads stored in the database. Technically it’s possible to create mysql queries that search for certain strings, but this process is so slow that it’s hardly usable in practice. The problem here is that the database field containing the payload is not indexed. I’ll show the query I used here (ripped from David Bianco’s blog)

WHERE event.timestamp >= ‘2007-08-18′ AND (event.dst_port = 80 OR event.dst_port = 443) AND data.data_payload like CONCAT(”%”, HEX(”Mozilla/5.0″), “%”)

If you know a more efficient query, please let me know!

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?

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!

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!

I wrote about my experiments with IPv6 before. These were done for my home network where I have an ISP that offers an IPv6 tunnel broker. The last two months I have not been in my home, but instead using internet ‘on the road’ mostly through wireless LANs. There are a number of techniques for using IPv6 if your provider doesn’t offer it, and today I stumbled on one in this NetworkWorld article, so I decided to give it a try.

The artice is about a new IPv6 portal called go6.net, where you can find IPv6 related news and forums. Next to this access to a free IPv6 broker is offered: freenet6. Freenet6 works by tunneling the IPv6 packets in UDP packets over IPv4. Getting it is easy, register an account and download the software. When you are running Debian or Ubuntu you can even skip the last step, a mere ‘apt-get install freenet6′ will do it. This is what I did. Next I just had to enter the username and password I had entered in the registration process in a file called ‘/etc/tsp/tspc.conf’ and issue the command ‘tspc -f /etc/tsp/tspc.conf’. Opening go6.net and kame.net comfirmed I was using IPv6!

Since I’m behind NAT-router internet hosts can’t connect to my laptop directly, but with IPv6 this changes. My laptop is now using a public IPAdress, so I set up a simple firewall script using ip6tables. I found two sites enabling you to check how the internet sees you, here and here. Both showed that my firewall is working. Good.

So now I wanted to blog about this, so I tried to login to my blog… ‘Access Denied’. Oops! Forgot that I only allow certain IPv4 addresses to the admin interface of my blog. This was a good time to see how ModSecurity deals with IPv6 addresses in its rules:

SecRule REMOTE_ADDR “!(192\.168\.1\.2|2001:5c0:8fff:fffe::62fd)” “chain,phase:1,deny,redirect:http://www.inliniac.net/nologin.html”
SecRule REQUEST_URI “/wp-login\.php$”

This rule blocks access to wp-login.php for everyone but 192.168.1.2 and 2001:5c0:8fff:fffe::62fd, and redirects them to a static page called nologin.html. This works using IPv6 as well! As you can see ModSecurity does not only support IPv6, it even allows you to mix IPv4 and IPv6 addresses in rules! Now all that was left was the /wp-admin/ section that didn’t block in ModSecurity, but just with Apache itself:

<Location /blog/wp-admin>
Order deny,allow
Deny from all
Allow from 192.168.1.2
Allow from 2001:5c0:8fff:fffe::62fd
</Location>

After an Apache restart I could write this post using IPv6!