Web on Inliniac

ModSecurity rule for Tikiwiki XSS

Mon, 27 Aug 2007 15:06:22 +0000

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:

the escaping of the - and _ chars is not needed, although it seems to be harmless.
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.
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!

Using Modsec2sguil for HTTP transaction logging revisited

Wed, 22 Aug 2007 20:05:34 +0000

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.

Update on using realtime blacklists with ModSecurity

Thu, 01 Mar 2007 08:04:55 +0000

A few days ago I posted a blog article about stopping comment spam with ModSecurity using realtime blacklists (rbl). While the approach was working, I noted having problems with rules when I tried to match on POST methods in HTTP requests.

Luckily, ModSecurity creator Ivan Ristic was quick to point out where the problem is. I’m using the Core Ruleset for ModSecurity, and one thing that ruleset does is use the ’lowercase’ transformation. This converts all text from arguments to lowercase, so my ^POST$ match would never be able to match. So like Ivan suggested, using ^post$ solved this part.

Blocking comment spam using ModSecurity and realtime blacklists

Thu, 22 Feb 2007 22:25:45 +0000

Spammers are known to use compromised hosts from all over the world to send their messages. Many people are blocking or scoring email spam based on realtime blacklist (rbl), which contain ipaddresses of these known bad hosts. In my experience this works fairly well for email. A while ago I noticed in the ModSecurity documentation for version 2.0 that ModSecurity features an operator called rbl, that can be used to check the ipaddress of a visitor with a rbl. So I decided to see if I could use the realtime blacklists to prevent comment spam on my blog. Turns out this works great! In this post I’ll show how to get it working.

Migrating from ModSecurity 1.9.4 to 2.0.4

Sat, 20 Jan 2007 10:34:05 +0000

ModSecurity 2 has been out for a while now, and although I have played with it some, I never found some time to upgrade my own servers. The upgrading generally went quite smooth, even though ModSecurity 2 changed quite a bit.

First of all there are now 5 phases where you can filter. Actually, one of them only applies to the logging, so you can filter in 4 phases. The phases are headers and body for both request and response traffic. Filtering on specific URIs can be done in phase 1 (request headers), while inspecting a POST payload requires phase 2 (request body).

Detecting and blocking Phishing with Snort and ClamAV

Sun, 12 Nov 2006 18:12:31 +0000

ClamAV is a great Open Source virusscanner that can be used for detecting virusses from Snort or Snort_inline using the ClamAV preprocessor. However, by using the anti-phishing and anti-scam signatures by SaneSecurity, this combination can also be used to detect and block phishing and scam attempts. Here is how to set it up.

I’ve decided to run this on my gateway, which is a slow machine. Because I don’t want all my traffic to slow down to much, I’m not going to run the ClamAV defs, only the anti-phishing ones. The default location of the defs on my Debian Sarge system is /var/lib/clamav, so I’ve created a new directory called ‘/var/lib/clamav-phish’. Next I’ve downloaded the defs from SaneSecurity. After unzipping them and the defs were ready.

Rules for reported Tikiwiki vulnerabilities

Thu, 02 Nov 2006 11:02:52 +0000

Yesterday there was a mail to the bugtraq mailinglist about two types of vulnerabilties in Tikiwiki 1.9.5. The most serious is a claimed MySQL password disclosure through a special URI. The second is an XSS, also through an special URI. The message can be found here.

I wrote ‘claimed password disclosure’, because on the Tikiwiki server I run, I could not reproduce it. With that I mean the password disclosure, since I do see that Tikiwiki gives an error that reveals other information, most notably the location of the website on the local filesystem.

ModSecurity: rule for latest Tikiwiki vulnerability

Wed, 06 Sep 2006 13:02:57 +0000

A few days ago a new vulnerability was reported in Tikiwiki 1.9.x, the software I use for the Vuurmuur Wiki. Luckily, the Snort.org Community rules quickly had a rule for detecting the attack. Because I also run ModSecurity on the webserver, i wanted to have protection there as well. This rule should block the attack:

SecFilterSelective POST_PAYLOAD “jhot.php” “log,deny,status:403,msg:‘LOCAL tikiwiki jhot.php attempt’”

Let’s see if I ever get a hit on it. An update for Tikiwiki as been released, so that should fix the issue completely.

ModSecurity: rules against comment spam

Wed, 23 Aug 2006 08:07:40 +0000

Lately the wiki of my Vuurmuur project has been receiving quite a lot of comment spam. Although removing the spam manually is boring work, i still don’t really mind the spam, because it enables me to practice with ModSecurity rules to fight it off. So far, the spam seems to be following a pattern, in which the spam is posted by bots, and has the same general layout for longer periods of time. That makes it worthwhile to spend time on creating rules against it. Yesterday a new type of spam emerged on the wiki. The following audit_log is for one of them. I had to slightly edit it for layout reasons.

ModSecurity: more security by obscurity

Thu, 17 Aug 2006 07:27:13 +0000

Yesterday, Philippe Baumgart showed me that my obscurity setup is not yet perfect. In fact, he could very easily enter an URL that didn’t exist and caused the webserver behind my proxy to respond with a 404. In this 404 the name and the version of the webserver were exposed.

After some testing i found that adding the following to my config worked very well.

# enable output scanning in Mod Security. SecFilterScanOutput On

ModSecurity: further improvements to the reverse proxy

Mon, 14 Aug 2006 08:52:55 +0000

People can reach my webserver in three ways: by my domain inliniac.net, by the hostname connected to my dsl, and by my ipaddress. What i now wanted is setup the proxy in such a way, that only people visiting inliniac.net would be proxied to the webserver.

Blocking requests that are IP based instead of name based have an important advantage. IP based requests are mostly used by scantools and other forms of malicious traffic that just attempt connecting to port 80 on large IP-ranges. So this way one should be able to keep a lot of crap like worm traffic out.

ModSecurity: redirection

Tue, 08 Aug 2006 22:09:50 +0000

Another nice feature of ModSecurity is rule based redirection. Lets say i want to block visitors of my website from opening the login page of wordpress, /blog/wp-login.php. I could of course just deny access to it, so the visitor gets a 403 error. This works fine, however sometimes you might want to use a more userfriendly message, for example: ‘Due to maintainance logins are currently disabled’.

To do this i first created a very simple html file called nologin.html, and placed it in the webroot of the server. Then i added the following rules to Mod_Security:

ModSecurity: directory hiding a.k.a. security by obscurity

Sun, 06 Aug 2006 20:24:07 +0000

Ok, that’s a bit misleading, because i’m not just hiding, but also blocking and logging. What i wanted is this: I’m running awstats on my reverse proxy, but i don’t want anyone to know. So i just made the entire ‘cgi-bin’ part forbidden for everyone, so that covers the script. The fact that my webserver has a cgi-bin directory is nothing special and won’t tell you i’m using awstats. However, awstats also uses icons, and these are by default in /awstats-icon/

ModSecurity: setting up a reverse proxy

Sat, 05 Aug 2006 13:35:49 +0000

A few weeks ago i wrote that i wanted to investigate setting up a reverse web proxy with mod_security. I have now finally found a little time to do so. What surprised me was how easy it actually is!

<IfModule mod_proxy.c>

#turning ProxyRequests on and allowing proxying from all may allow #spammers to use your proxy to send email.

ProxyRequests Off

<Proxy *> Order deny,allow Allow from all #Allow from .your_domain.com

ModSecurity: my first rules

Tue, 11 Jul 2006 09:37:33 +0000

I have been using ModSecurity for quite some time now to protect a webserver, but i never felt the need to write my own rules. Recently though, my site got quite a lot of spam in the comments of my TikiWiki based site. Since i was not willing to disable the anonymous comment posting i decided to see if i could use Mod_Security to block the spam.

The spam all looked alike with the following characteristics. It all contained a list uri’s with a pipe | before them. So decided to try the most easy way, by blocking all posts with this characteristic.

Books: Preventing Webattacks with Apache

Mon, 10 Jul 2006 21:54:51 +0000

I just finished Preventing Webattacks with Apache by Ryan C. Barnett. Even though the title says it is about Apache it is really mostly about Mod_Security, and this is why i really love the book.

Especially cool is the part of the book where the author challenges the user to setup his ‘Buggy Bank’ example application to play with the vulnarebilities and with the possible counter measures.

This book got me even more exited about Mod_Security, which I use already to protect one webserver. I plan to check out setting up a reverse filtering web proxy soon.