Message-ID: <20040411063608.24463.qmail@www.securityfocus.com>
Date: 11 Apr 2004 06:36:08 -0000
From: JeiAr <security@...ftech.org>
To: bugtraq@...urityfocus.com
Subject: Multiple Vulnerabilities In Tiki CMS/Groupware [ TikiWiki ]




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]&sort_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=priority_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]&sort_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. 

Powered by blists - more mailing lists