Vulnerability on Inliniac

Detecting OpenSSL Heartbleed with Suricata

Tue, 08 Apr 2014 12:16:17 +0000

The OpenSSL heartbleed vulnerability is a pretty serious weakness in OpenSSL that can lead to information disclosure, in some cases even to to private key leaking. Please see this post here http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html for more info.

This is a case where an IDS is able to detect the vuln, even though we’re talking about TLS.

LUA

I’ve written a quick and dirty LUA script to detect it:

alert tls any any -> any any ( \
    msg:"TLS HEARTBLEED malformed heartbeat record"; \
    flow:established,to_server; dsize:>7; \
    content:"|18 03|"; depth:2; lua:tls-heartbleed.lua; \
    classtype:misc-attack; sid:3000001; rev:1;)

The script:

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

Thu, 11 Oct 2007 11:13:44 +0000

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

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!

New WordPress issue + Snort and ModSecurity rules

Tue, 20 Mar 2007 18:03:21 +0000

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:

ModSecurity evasion vulnerability

Tue, 06 Mar 2007 17:35:09 +0000

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.

Snort_inline in svn updated to 2.6.1.3

Thu, 22 Feb 2007 07:59:05 +0000

This week SourceFire published a security advisory for (among others) Snort version 2.6.1.2, on which Snort_inline is based. So I took some time to update Snort_inline. Normally this would have taken Will and me quite some time, but since we switched to using svn those days are gone. I was able to update it in under a hour. I was very happy I blogged about the procedure to follow, since I had already forgotten about it ;-)