Inliniac

I just read about a new issue with WordPress here at SecurityFocus. It’s a potential credential stealing vulnerability, so I quickly created these ModSecurity 2 rules:

SecDefaultAction “log,deny,status:403,phase:2,t:lowercase,t:escapeSeqDecode”
SecRule REQUEST_FILENAME “/wp-login.php$” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS_NAMES “^redirect_to$” “chain”
SecRule ARGS:redirect_to “(ht|f)tps?\://”

I can still login to my WordPress install, so it seems that the rule does no harm. Use at your own risk!

Update: I’ve created a Snort rule as well:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WORDPRESS wp-login.php redirect_to credentials stealing attempt”; flow:to_server,established; uricontent:”/wp-login.php”; nocase; uricontent:”redirect_to”; pcre:”/redirect_to=(ht|f)tps?\:\//iU”; classtype:web-application-attack; sid:4000003; rev:1;)

Update 2: fixed the Snort rule, thanks to Shirkdog for pointing out that it had some broken pcre in it. The rule is now included in the BleedingThreats ruleset (check here), however that (slightly modified) rule doesn’t detect the attack for me.

Update 3: the Bleeding rule is now fixed. I’ve updated the above rule as well.

Update 4: updated the ModSecurity rule to prevent a possible evasion by prepending tab chars to the redirect url. Thanks to Ryan Barnett for pointing this out.

I’ve just released version 0.7 of Modsec2sguil, the set of perl scripts to feed ModSecurity alerts to the Sguil NSM system. The main change of this release is that it adds support for alerts produced by ModSecurity 2.x, while 1.9.x remains to be supported. Next to this the conversion between ModSecurity’s severity and Snort’s priority was fixed, so alerts should show up in the right pane in Sguil again.

Please give this release a try and let me know how it works for you!

Download it here: http://www.inliniac.net/files/modsec2sguil-0.7.tar.gz

My ISP is one of the few here in the Netherlands that provides a IPv6 tunnel broker. I have played with it some during the last year or so, but now decided to get a little more serious with it. So I’ve decided to enable it for my blog. When opening up my site to IPv6 one thing that is important is security. I will describe the status of IPv6 support of my current setup:

Linux firewalling: IPtables supports IPv6 for quite some time, however it only very recently gained stateful packet filtering support. This hasn’t made it into Debian Sarge or even backports yet, so I’m just using stateless filtering now.

Vuurmuur: my own IPtables frontend has no support for IPv6 at all. I’ve been thinking about adding it for years, but decided to wait at least until stateful support would be available. Next to this my coding time is limited, and many other features are probably more interesting to Vuurmuur users.

Snort/Snort_inline: both Snort and Snort_inline lack support for IPv6. Sourcefire is working on it as far as I know, but no code is available from them. I did find a IPv6 patch for Snort 2.3.3, which can be found here. I ran it in sniffer mode and that works. I haven’t played with it much other than that, but I certainly will in the future.

ModSecurity: my Apache 2 installation has IPv6 enabled by default and ModSecurity 2.x just worked with it without any configuration change! I haven’t looked into how to create rules specific for IPv6 addresses however, so maybe surprises will come up here. I do know from looking at the source that the rbl functionality doesn’t support IPv6 addresses yet, but I haven’t even checked if realtime blacklists exist for IPv6.

Sguil/Modsec2sguil: my modsec2sguil script, that takes ModSecurity alerts and feeds them to Sguil, doesn’t act on the IPv6 alerts because it expects IPv4 addresses. This is not a problem however, since Sguil doesn’t support IPv6 addresses. This makes sense since Snort doesn’t support it either.

So compared to my IPv4 access, protection is somewhat limited. I’m only enabling HTTP for now, so ModSecurity should be able to handle that just fine.

Anyway, it seems to be working fine now, but consider the IPv6 support experimental, as I’m playing with how it all works. So don’t be surpised if it’s broken all of a sudden

ModSecurity author Ivan Ristic just reported that a ModSecurity evasion vulnerability has been published without him being notified in advance, so there is no update available yet. Check here for his announcement. And here for the advisory. Ivan Ristic suggests everyone to use this workaround until an updated version of ModSecurity is released (put on a single line):

SecRule REQUEST_BODY “@validateByteRange 1-255″ “log,deny,phase:2,t:none,msg:’ModSecurity ASCIIZ Evasion Attempt’”

I’ve been using that rule for an hour or so, and have seen no false positives so far.

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.

Next Ivan pointed out a weakness in the rules. My rules looked for /blog/wp-comment-post.php, and would be easily evaded by just using /blog//wp-comment-post.php. He suggested using the ‘normalisePath’ transformation. I did this, but I also slightly changed the rules to not look for the /blog/ part at all (maybe this makes normalisePath useless, but I decided to rather be safe than sorry).

The rules I’m using now look like this:

SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl list.dsbl.org’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl list.dsbl.org”

SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl bl.spamcop.net’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl bl.spamcop.net”

SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl sbl-xbl.spamhaus.org’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl sbl-xbl.spamhaus.org”

Thanks a lot Ivan Ristic for your comments!

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.
(more…)

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).

Next, some shortcuts where removed. In 1.9.4 there was a variable called POST_PAYLOAD, that enabled the user to match against payloads from POST requests easily. Now there is REQUEST_BODY, but since that can be part of non-POST requests as well, you have to use:

SecRule REQUEST_METHOD “POST” chain
SecRule REQUEST_BODY “evil”

instead of:

SecFilterSelective POST_PAYLOAD “evil”

One other change is visible above already. The keyword to create a rule has been changed from SecFilterSelective to SecRule. Many rules can be converted by just replacing the keyword, but certainly not all. A simple find/replace should not be done without a manual review!

I use a number of custom rules to protect certain parts of my server, so I needed to convert my rules. For most of them it was simply enough to replace SecFilterSelective with SecRule. For a few I had to replace the OUTPUT_STATUS variable with the RESPONSE_STATUS variable, as it is called now.

For one rule however, I had quite some problems to get it running correctly. This was the rule in 1.9.4 syntax:

# block wp-login.php
SecFilterSelective REMOTE_ADDR “!10\.1\.1\.1″ chain
SecFilterSelective REQUEST_URI “/wp-login.php” \
log,deny,redirect:http://www.inliniac.net/nologin.html

This rule makes sure only 10.1.1.1 can open the login page, everyone else is redirected to a simple html page containing a ‘Access Denied - Logins disabled’ message. I converted it to the following:

SecRule REMOTE_ADDR “!10\.1\.1\.1″ chain
SecRule REQUEST_URI “/wp-login.php” \
log,deny,redirect:http://www.inliniac.net/nologin.html

Guess what? It didn’t work. I’ve spend quite some time trying all kinds of variations of the rule, and finally I found out what the issue is. In 1.9.4 the rule actions, like deny, redirect etc could be in the final rule of a series of chained rules. With 2.0.4 this doesn’t work correctly. So when I changed the rules to the following, it worked:

# block wp-login.php
SecRule REMOTE_ADDR “!10\.1\.1\.1″ \ “chain,phase:1,log,deny,redirect:http://www.inliniac.net/nologin.html”
SecRule REQUEST_URI “/wp-login\.php$”

I haven’t looked into this further to find out whether this is a bug or a feature.

The last thing that was interesting is the modsec2sguil script. There have been some changes to the alert files. So expect a new version of the script soon!