Vendor : TikiWiki Project

URL : http://www.tikiwiki.org

Version : TikiWiki 1.8.1 && Earlier

Risk : Multiple Vulnerabilities

Description:

Tiki CMS/Groupware (aka TikiWiki) is a powerful open-source Content

Management System (CMS) and Groupware that can be used to create all

sorts of Web applications, Sites, Portals, Intranets and Extranets.

TikiWiki also works great as a Web-based collaboration tool. TikiWiki

is a multi-purpose package with a lot of native options and sections

that you can enable/disable as you need them. It is designed to be

international, clean and extensible. TikiWiki incorporates all the

features present in several excellent wiki systems available today plus

a lot of new features and options, allowing your wiki application to be

whatever you want it to be--from a simple wiki to a complex site for a

whole user community with many intermediate steps. You can use TikiWiki

as a forums site, a chatroom, for poll taking, and much more!

Path Disclosure:

There are several ways to discover the full physical path of the web

directory on a server running TikiWiki. One way is by calling some

files directly with a null or non-existent value as seen below.

banner_click.php

categorize.php

tiki-admin_include_directory.php

tiki-directory_search.php

Some files specifically prevent this by checking to see if they are

called directly. I am not sure why more of the TikiWiki files do not

use the same preventive measure. Also, just about anywhere that there

is potential for SQL tampering (read about that later) you can leave

the value null, and generate an error that will disclose the full

physical path of the web server. Below are a handful of examples, but

surely it is not all of them. The rest of this write up will use the

following key when displaying example URL's

[INT] = Pretty much any integer will do

[VID] = Requires some sort of valid ID

[VPG] = The name of a valid page/user page

[JNK] = Just some random garbage

[SQL] = An evil SQL query ;)

[XSS] = Some code to cause XSS to happen

tiki-searchindex.php?highlight=[JNK]

messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=

messu-read.php?offset=[INT]&flag=&priority=&flagval=

messu-read.php?offset=[INT]&flag=&priority=

messu-read.php?offset=[INT]&flag=

messu-read.php?offset=

tiki-list_file_gallery.php?find=&galleryId=1&offset=[INT]&sort_mode=

tiki-usermenu.php?find=&offset=

tiki-usermenu.php?find=&offset=[INT]&sort_mode=

tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[INT]&so
rt_mode=

tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=

tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[INT]
&comments_maxComments=

tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=p
riority_desc&find=[JNK]

tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=

tiki-directory_ranking.php?sort_mode=

tiki-file_galleries.php?find=&search=find&sort_mode=

tiki-list_faqs.php?find=&offset=[INT]&sort_mode=

tiki-list_faqs.php?find=&offset=

tiki-list_trackers.php?find=&offset=[INT]&sort_mode=

tiki-list_trackers.php?find=&offset=

Cross Site Scripting

There also happens to be a great number of places XSS (cross site

scripting) can take place on a TikiWiki powered site. Below are a

number of examples, but it is far from all of them. TikiWiki is a

VERY large collection of files and it would be a waste of time to

go through and find/list every one of them :)

tiki-switch_theme.php?theme=[XSS]

messu-mailbox.php?flags=&priority=&find=[XSS]

messu-mailbox.php?flags=&priority=[XSS]

messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=date_desc
&find=[XSS]

messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=[XSS]

messu-read.php?offset=[INT]&flag=&priority=&flagval=[XSS]

messu-read.php?offset=[INT]&flag=&priority=[XSS]

messu-read.php?offset=[INT]&flag=[XSS]

messu-read.php?offset=[XSS]

tiki-read_article.php?articleId=[VID][XSS]

tiki-browse_categories.php?find=&deep=off&parentId=[VID][XSS]

tiki-index.php?page=[VPG]&comments_threshold=[INT][XSS]

tiki-print_article.php?articleId=[VID][XSS]

tiki-list_file_gallery.php?galleryId=[VID][XSS]

tiki-upload_file.php?galleryId=[VID][XSS]

tiki-view_faq.php?faqId=[VID][XSS]

tiki-view_chart.php?chartId=[VID][XSS]

tiki-survey_stats_survey.php?surveyId=[VID][XSS]

SQL Injection:

Data seems to be passed into a query with little or no validation

just about anywhere you encounter the *sort_mode or offset variable.

It should be noted though that the offset variable takes place after

the LIMIT statement, so the risk isn't very high as compared to data

being passed earlier in the query. It still should be addressed though.

Below are some examples. Once again keep in mind that this is not ALL

instances of the *sort_mode or offset problems.

tiki-usermenu.php?find=&offset=[INT]&sort_mode=[SQL]

tiki-list_file_gallery.php?find=&galleryId=[VID]&offset=[INT]&sort_mode=
[SQL]

tiki-directory_ranking.php?sort_mode=[SQL]

tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[INT]&so
rt_mode=[SQL]

tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[INT]
&comments_sort_mode=[SQL]

tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=[
SQL]

tiki-directory_ranking.php?sort_mode=[SQL]

tiki-directory_search.php?how=or&words=&where=all&sort_mode=[SQL]

tiki-file_galleries.php?find=&search=find&sort_mode=[SQL]

tiki-list_faqs.php?find=&offset=[INT]&sort_mode=[SQL]

tiki-list_trackers.php?find=&offset=[INT]&sort_mode=[SQL]

tiki-list_blogs.php?find=&offset=[INT]&sort_mode=[SQL]

tiki-usermenu.php?find=&offset=[SQL]

tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[SQL]

tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[SQL]

tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[SQL]

tiki-list_faqs.php?find=&offset=[SQL]

tiki-list_trackers.php?find=&offset=[SQL]

tiki-list_blogs.php?find=&offset=[SQL]

Code Injection:

It is possible for a malicious user to inject code into several places

on a TikiWiki powered site including, but not limited to the link

directory and the user profile. Below are examples of my findings, but I

am pretty sure they also exist elsewhere

User Profile > Theme

User Profile > Country Field

User Profile > Real Name

User Profile > Displayed time zone

Directory > Add Site > Name

Directory > Add Site > Description

Directory > Add Site > URL

Directory > Add Site > Country

Remote File/Dir Enumeration Via Traversal:

This issue deals with the map feature TikiWiki uses. If you are using

a version prior to 1.8 or if you have not enabled the map feature this

probably does not affect you. The map feature calls a .map file to display

whatever map a user would like to view, but the problem with this is that

it allows you to traverse out of the web directory and call files elsewhere

on the box. While this does not allow you to say pull up a file for viewing

or download, it will allow you to confirm the existence of both files and

directories on the affected box. Below is an example.

/tiki-map.phtml?mapfile=../../../../var/

I have also coded a small quick and dirty utility to automate the

process of enumerating the existence of files on a machine running

TikiWiki 1.8 with the map feature enabled. The utility can be found

at the following location.

http://www.gulftech.org/vuln/tikitool.txt

Arbitrary File Upload:

It is possible to upload arbitrary files to a TikiWiki installation by

including it in the image upload feature when creating your TikiWiki user

page. The file then will be located here.

http://host/img/wiki_up/filenamehere

It should be pretty obvious that this will let an attacker upload arbitrary

scripts and run commands with the rights of the webserver. This could be

very dangerous.

Solution:

The TikiWiki Devel team have addressed these issues, and updates are available

at their official website. I was VERY impressed with the way these guys handled

the situation. Due to the size of the project, and the way some of these issues

spanned across seemingly hundreds of files there was a great amount of work to

be done. In some cases a dev team would have just addressed the critical issues

and left the small issues like path disclosure for the next official release.

These guys though took EVERY issue very seriously and assembled a security

response team, and very organized response method for these issues and future

issues. I do not think any researcher could ask for a better response from a

vendor. They were friendly, professional, prompt, and serious. Hats off to them,

and TikiWiki users should know they are in good hands, as these guys are a young

project and already take security issues more seriously than alot of the big name

open source projects out there :) Original advisory can be found at the following

location @ http://www.gulftech.org/04112004.php

Credits:

Credits go to JeiAr of the GulfTech Security Research Team.

[ reply ]