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.