Monthly Archives: March 2007

Running IPv6 with Freenet6 when on the road

Posted on by

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!

New WordPress issue + Snort and ModSecurity rules

Posted on by

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.

Modsec2sguil 0.7 released

Posted on by

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

Leaking information by using IPv6

Posted on by

As I wrote before, I’m experimenting with IPv6. I have a tunnel to my ISP from my router. The router is running Linux and uses radvd to advertise my IPv6 prefix to my networks. My dmz, in which this blog is hosted, get the 2001:888:13c5:cafe::/64 prefix. The IPaddresses are then created by taking the MACaddress of a network interface and placing that behind the prefix. It’s a nice and simple autoconfiguration system. So the IPv6 address of the blog is 2001:888:13c5:cafe:20c:29ff:fe13:2b42.

What I didn’t realize when I set this up like this, is that the MACaddress is visible and possibly giving valuable information to an attacker. See for example the output of the following command:

# ipv6calc 2001:888:13c5:cafe:20c:29ff:fe13:2b42 –showinfo
No input type specified, try autodetection…found type: ipv6addr
No output type specified, try autodetection…found type: ipv6addr
Address type: unicast, global-unicast, productive
Address type has SLA: cafe
Registry for address: RIPE NCC
Interface identifier: 020c:29ff:fe13:2b42
EUI-48/MAC address: 00:0c:29:13:2b:42
MAC is a global unique one
MAC is an unicast one
OUI is: VMware, Inc.

The last line said it: I’m running the blog on VMware. This might be interesting info for an attacker, which otherwise would not have been available, or at least not this easy.

To prevent this you can just setup a manual IPaddress, which is wiser from a maintainability point of view anyway, since you don’t want to update your DNS records everytime the server gets a new NIC. But still, it shows that IPv6 has it’s own gotchas and peculiarities in the security area.

Experimenting with IPv6

Posted on by

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 evasion vulnerability

Posted on by

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.

Update on using realtime blacklists with ModSecurity

Posted on by

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!