Category Archives: tikiwiki

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

Posted on by

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

Posted on by

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

Rules for reported Tikiwiki vulnerabilities

Posted on by

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.

Anyway, since I’m running Tikiwiki I was eager to protect myself, so I started to write some rules.

XSS

Since I run ModSecurity on this server, I started with a rule for that:

SecFilterSelective REQUEST_URI “/tiki-featured_link.php?type” “chain,status:403,msg:’LOCAL tikiwiki featured link XSS attempt’,severity:6”
SecFilterSelective REQUEST_URI “/iframe>” log,deny,status:403

I did the same for Snort, and submitted it to the Bleeding Edge ruleset, see here.

Passwd/filesystem disclosure

This one is much harder to catch in a rule. The problem is in how Tikiwiki handles the sort_mode option in an URI. Only if the argument to sort_mode is valid (such as hits_asc or hits_desc for sorting on number of hits) the error is prevented. If the argument to sort_mode is empty or invalid then the disclosure condition triggers.

The only way I can think of to write rules for this is by adding some positive security filtering. In other words, create a rule that defines the valid arguments to sort_mode and drop anything else. Below is an example of one of the affected pages in Tikiwiki:

SecFilterSelective REQUEST_URI “tiki-listpages.php” chain
SecFilterSelective REQUEST_URI “sort_mode=(pageName|hits|lastModif|creator|user|version|
comment|flag|versions|links|backlinks|size)_(asc|desc)” pass,skip:2

SecFilterSelective REQUEST_URI “tiki-listpages.php” “chain,msg:’LOCAL tikiwiki listpages mysql passwd disclosure attempt’,severity:7”
SecFilterSelective REQUEST_URI “sort_mode=” log,deny,status:403

As you can see, here are two logical rules, each consisting of two chained rules. The first rule defines all the possible valid options to sort_mode and then has the action ‘pass,skip:2’. This says that this rule should not use the default action of deny and that the next two rules should be skipped. These next two rules drop every use of the sort_mode option, thus blocking the attack.

I have not yet looked at doing this in Snort. According to the advisory, there are 21 different vulnerable URI’s in Tikiwiki, which all have different arguments to sort_mode. So only 20 more to go! 😉

ModSecurity: rule for latest Tikiwiki vulnerability

Posted on by

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.