by Tan Chew Keong
Release Date: 2008-07-16
[en] [jp]
Summary
A vulnerability has been found in FreeStyleWiki (FSWiki). When exploited, this vulnerability allows an attacker to gain administrative access to the Wiki without requiring knowledge of the password. This vulnerability affects users who deploy FreeStyleWiki on a Windows system.
Tested Versions
Details
A vulnerability has been found in FreeStyleWiki (FSWiki). When exploited, this vulnerability allows an attacker to gain administrative access to the Wiki without requiring knowledge of the password. This vulnerability affects users who deploy FreeStyleWiki on a Windows-based system. FSWiki deployed on Linux-based systems are not affected, other platforms have not been tested.
FreeStyleWiki uses CGI::Session version 3.94 for session management. Session variables are stored in session data files with filenames that looks like cgisess_24d8fce5b781c9b2497e2f100e48532b. The part "24d8fce5b781c9b2497e2f100e48532b" is the session ID of that particular session. In other words, each logon session has its own session data file with the session ID as part of the filename.
Session data files are stored in the "log" subdirectory within the directory where FSWiki is installed. For example, if FSWiki is installed in "C:\usr\Apache2\htdocs\", the session data files will be stored in "C:\usr\Apache2\htdocs\log\".
FreeStyleWiki receives session IDs from the browser via the CGISESSID cookie value. The session ID received from the cookie is used to construct the filename of the session data file. For example, if FSWiki is installed in "C:\usr\Apache2\htdocs\" and the cookie value is CGISESSID=24d8fce5b781c9b2497e2f100e48532b, the constructed session data filename will be "C:\usr\Apache2\htdocs\log\cgisess_24d8fce5b781c9b2497e2f100e48532b".
Unfortunately, the session ID value that was received via the cookie was not sanitised before being used to construct the filename. This can be exploited via directory traversal sequences to cause FSWiki to read session data files from outside of the session data directory.
For example, by changing the cookie value to CGISESSID=/../../data/TestPage.wiki, the constructed filename to the session data file becomes C:\usr\Apache2\htdocs\log\cgisess_/../../data/TestPage.wiki.
IMPORTANT: At this point, it is important to note that the constructed filename contains the directory cgisess_. This directory does not exist on the web server. On a Linux system, this exploit will not work because the constructed filename is considered to be invalid since the directory cgisess_ does not exist. However, on a Windows system, it is treated as a valid filename. In fact, it is the same as C:\usr\Apache2\htdocs\log\../data/TestPage.wiki.
This means that if FSWiki is deployed on a Windows system, it would be possible for an attacker to cause FSWiki to read session data from arbitrary files outside of the session data directory. If FSWiki is configured to allow users to add new page, or to upload attachments to existing pages, it would be possible for an attacker to create files with content that resembles session data files in predictable locations on the web server. These files can then be used as session data files by exploiting the directory traversal vulnerability.
More specifically, new pages are stored with predictable filenames under "C:\usr\Apache2\htdocs\data\" and file attachments are stored under "C:\usr\Apache2\htdocs\attach\". An attacker who created these files have full control over their contents. Hence, by making the content of these files the same as a valid session data file, it is possible for the attacker to exploit the directory traversal vulnerability to create a valid session for himself. This gives the attacker full control over all session variables, and by setting the value of the "wiki-type" session variable to 0, it is possible for the attacker to gain administrative access to the Wiki.
An example of the content of a session file is shown below.
$D = {"_SESSION_ID" => "dba3e47eb81c94d0368ecfbbc12e9c9f","_SESSION_ETIME" => undef,"_SESSION_REMOTE_ADDR" => "192.168.179.1","_SESSION_CTIME" => "2222222222","_SESSION_ATIME" => "2222222222","wiki_type" => 0,"wiki_path" => "","wiki_id" => "anynamewilldo","_SESSION_EXPIRE_LIST" => {}};
POC / Test Code
Please follow the instructions below to confirm the vulnerability on a Windows system.
Instructions for testing FreeStyleWiki on a Windows sytem:
- Install FreeStyleWiki on a Windows system with Apache2 and ActiveState ActivePerl. Follow the instructions here.
- Download and install Paros proxy on the system that you'll be using the browser on. If you do not have JRE 1.4.2 or later, please install it first. Paros allows you to intercept requests so you can manipulate the session cookie.
- Using a browser, visit the FSWiki page, click on the "Create New Page" link and type in TestPage as the name of the new page (see below). Then click on the "Create" button.
- Copy-and-Paste the content below into the textbox that allows you to specify the page content. The content below are the session variables that we want to use to gain administrative access.
IMPORTANT: Before this, you must change the _SESSION_REMOTE_ADDR IP address below to the IP address of the system that you are accessing FSWiki from. Please copy-and-paste into the textbox as a single-line. Do not put any line-breaks in it. It is OK if the textbox automatically wrap the lines, but you must not add any line-breaks in it yourself.
Content to be copied into the page creation textbox:
$D = {"_SESSION_ID" => "dba3e47eb81c94d0368ecfbbc12e9c9f","_SESSION_ETIME" => undef,"_SESSION_REMOTE_ADDR" => "192.168.179.1","_SESSION_CTIME" => "2222222222","_SESSION_ATIME" => "2222222222","wiki_type" => 0,"wiki_path" => "","wiki_id" => "anynamewilldo","_SESSION_EXPIRE_LIST" => {}};
|
- Click on the "Save" button to save the content. This will create the file "C:\usr\Apache2\htdocs\data\TestPage.wiki" that contains the above contents.
- Run Paros and configure IE to use it as a proxy. Paros listens on 127.0.0.1 port 8080. (see below)
- Enable "Trap Request" in Paros.
- Using IE, try to visit one of the admin pages. For example, "http://fswikiHostName/wiki.cgi?action=ADMINCONFIG". Note that Paro will stop the request. Observe that there is no value for the CGISESSID cookie (see below).
- Change the value of the CGISESSID cookie to /../../data/TestPage.wiki by replacing Cookie: CGISESSID= with Cookie: CGISESSID=/../../data/TestPage.wiki and let the request continue by click on the "Continue" button (see below).
- Note that by changing the value of the CGISESSID cookie to /../../data/TestPage.wiki, CGI::Session will read session data from C:\usr\Apache2\htdocs\log\cgisess_/../../data/TestPage.wiki. This is the same as reading from C:\usr\Apache2\htdocs\data\TestPage.wiki. And since we have placed our desired session variables into that file by creating a new page in step 4, we now effectively have control over all session variables.
- After that, you should see the Admin Configuration page being displayed. Change some configuration settings on that page and save it to confirm that you have full administrator access to the Wiki.
Patch / Workaround
The vendor will release a patch to fix this vulnerability. Download patch here.
Disclosure Timeline
2008-07-10 - Vulnerability Discovered.
2008-07-11 - Initial Notification Sent to Developer of FreeStyleWiki.
2008-07-11 - Received Initial Reply from Developer of FreeStyleWiki.
2008-07-11 - Vulnerability Details Sent to Developer of FreeStyleWiki.
2008-07-11 - Vulnerability Details Sent to Developers of CGI::Session.
2008-07-12 - Sent Suggested Patch to Developer of FreeStyleWiki.
2008-07-12 - Received reply from Developer of FreeStyleWiki that a patch will be released.
2008-07-13 - Developers of CGI::Session released CGI::Session version 4.34, that fixes the vulnerability.
2008-07-16 - Public Release.
2008-07-16 - Updated advisory with patch download link.