Author

waraxe

Risk

[

Security Risk Unsored

]

0day-ID

0day-ID-4682

Category

web applications

Date add

15-01-2009

Platform

unsorted

====================================================
MKPortal <= 1.2.1 () Multiple Remote Vulnerabilities
====================================================



[waraxe-2009-SA#070] - Multiple Vulnerabilities in MKPortal <= 1.2.1
==============================================================================

Author: Janek Vind "waraxe"
Date: 15. January 2009
Location: Estonia, Tartu
Web: http://www.waraxe.us/advisory-70.html


Description of vulnerable software:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MKPortal is a free Portal/Content Management System (CMS) which seamlessly
integrates with the most popular forum softwares. It uses the forum user
management system and other features and adds many powerful modules to create
and manage a light but powerful web site. MKPortal has an intuitive user
interface and is very simple to install and administer.

Homepage: http://www.mkportal.it/


List of found vulnerabilities
===============================================================================

1. Insecure file upload in blog personal gallery
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: critical
Preconditions:
 1. attacker must be registered user
 2. attacker must have blog editing privileges

Registered users with blog keeping privileges can access personal gallery
functionality, example URL:

http://localhost/mkportal.1.2.1/index.php?ind=blog&op=p_gal

They can also upload image files to the server. File uploading can be
dangerous without proper security checks. So let's have a closer look
at the source code of "modules/blog/index.php" line ~2452: 

---------------------[source code]---------------------
function upload_imm () {
		global $mkportals, $DB, $mklib, $Skin, $_FILES;

..
		$file =  $_FILES['FILE_UPLOAD']['tmp_name'];
		$file_name =  $_FILES['FILE_UPLOAD']['name'];
		//$file_type =  $_FILES['FILE_UPLOAD']['type'];
		$peso =  $_FILES['FILE_UPLOAD']['size'];		
		
		if (!$file) {
			$message = "{$mklib->lang['b_compfile']}";
			$mklib->error_page($message);
			exit;
		}

		//Validate file extension
		$file_ext = preg_replace("`.*\.(.*)`", "\\1", $file_name);
		$file_ext = substr ($file_name, (strlen($file_name)-3), 3);
		$file_ext = strtolower($file_ext);

		switch($file_ext)
		{
			case 'gif':
				$ext = 'gif';
				break;
			case 'jpg':
				$ext = 'jpg';
				break;
			case 'png':
				$ext = 'png';
				break;
			case 'tif':
				$ext = 'tif';
				break;
			case 'bmp':
				$ext = 'bmp';
				break;
			default:
				$ext = 'not_supported';
				break;
		}
		if ($ext == "not_supported")  {
			$message = "{$mklib->lang['b_gnotsup']}";
			$mklib->error_page($message);
			exit;
		}

--------------------[/source code]---------------------

So this piece of code suppose to be let in only files with specific extensions.
In reality it will pass through files like "foobar.agif" or "whatever.pbmp ...
Let's assume, that we have jpg picture named "pic.php.jjpg". This can be valid
picture file and in same time contain malicious php code inside.

What happens next:

---------------------[source code]---------------------
		//Move file from server tmp directory to blog "tmp" directory			
		if (!move_uploaded_file("$file", "mkportal/blog/images/tmp/$file_name")) {
			$message = "{$mklib->lang['b_nopermupl']}";
			$mklib->error_page($message);
			exit;
		}
		@chmod("mkportal/blog/images/tmp/$file_name", 0644);
	
		//Validate by mime type
		$tmpfilename = "mkportal/blog/images/tmp/$file_name";
		$size = @getimagesize($tmpfilename);
		//If getimagesize does not recognize file as an image delete file
		if (!$size)  {
			@unlink($tmpfilename);
			$message .= "{$mklib->lang['error_filetype']}";
			$mklib->error_page($message);
			exit;
		}
--------------------[/source code]---------------------

As this image file is perfectly normal jpg picture, then it will bypass
"getimagesize()" successfully. And "chmod()" will not make any differents in
specific situation.

Next:

---------------------[source code]---------------------
$file_type = $size['mime'];

		if (!$mklib->check_attach($file_type, $file_ext))  {
			//Delete invalid file and display error
			@unlink($tmpfilename);
			$message .= "{$mklib->lang['b_gnotsup']}";
			$mklib->error_page($message);
			exit;
		}

		//Validate by file contents
		$fcontents = file_get_contents ($tmpfilename);
		$carray = array("html", "javascript", "vbscript", "alert",
 "onmouseover", "onclick", "onload", "onsubmit");		
		foreach ($carray as $fch) {
            		if (strstr($fcontents, $fch)) {
                		@unlink($tmpfilename);
				$message .= "{$mklib->lang['error_filetype']}";
				$mklib->error_page($message);
                		exit;
            		}
        	}
        	if (preg_match("#script(.+?)/script#ies", $fcontents)) {
           		@unlink($tmpfilename);
			$message .= "{$mklib->lang['error_filetype']}";
			$mklib->error_page($message);
            		exit;
		}
--------------------[/source code]---------------------

Again, MIME-type will be correct and html-code detection can't stop
malicious php code inside of that jpg file. 

Finally:

---------------------[source code]---------------------
$image = $totr.$file_name;

//move file from "tmp" directory to "images" directory
@rename($tmpfilename, "mkportal/blog/images/$image");
--------------------[/source code]---------------------

What's the possibilities? Attacker can upload picture file with php code
inside with filename like "pic.php.pjpg" and it will be stored in remote
server as result. And when attacker issues direct request to uploaded
picture:

http://localhost/mkportal.1.2.1/mkportal/blog/images/1pic.php.pjpg"

.. then in case of Apache webserver php code inside of picture will
be executed. Therefore it's basically remote php code execution.


2. Insecure file upload in Downloads module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: critical
Preconditions:
 1. attacker must be registered user

Registered users can add new files in downloads module by default:

http://localhost/mkportal.1.2.1/index.php?ind=downloads&op=submit_file

Let's look at "mkportal/modules/Downloads/index.php" line ~662:

---------[source code]--------------------------
function add_file() {

    	global $mkportals, $DB,  $_FILES, $mklib, $mklib_board;
..
	//Replace illegal sub-extensions
	$com_types = array('com', 'exe', 'bat', 'scr', 'pif', 'asp',
 'cgi', 'pl', 'php');
	foreach ($com_types AS $bad) {
		$file_name = str_replace(".$bad", "_$bad", $file_name);
---------[/source code]--------------------------

At first look this seems to be good security measure. If we try to upload
trojanized file with php code inside named "test.php.zzz', then it will be
transformed to "test_php.zzz" and php code execution is not possible.
But wait a minute ... "str_replace()" is case sensitive, right? So, what if
we try to upload "test.Php.zzz"? Yes, code fragment above will not trigger and
we end up with potentially dangerous uploaded file on remote server. It's easy
to find out URL to that file. First, let's look at file's download link:

http://localhost/mkportal.1.2.1/index.php?ind=downloads&op=download_file&ide=3
&file=test.Php.zzz

Here we can determine, that "ide=3". And this is the direct file request URL:

http://localhost/mkportal.1.2.1/mkportal/modules/downloads/file/mk_3_test.Php.mk

And it appears, that Apache does not care, if it's "php" or "Php" or "PHP", it
will parse the file as php script anyway. And as result any registered user with
file adding rights in downloads block can have arbitrary php code execution
possibilities in remote server.


3. Race condition in multiple modules file upload functionality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions:
 1. attacker must be registered user
 2. multiple tries needed for successful exploitation

Affected modules are Blog (gallery file upload), Reviews and Image Gallery.
For example let's look at Image Gallery's file upload code:

---------[source code]--------------------------
if (!$FILE_UPLOAD && $FILE_URL) {
	//Copy file from remote server to gallery "tmp" directory
	if (!copy("$file", "mkportal/modules/gallery/album/tmp/$file_name")) {
		$message = "{$mklib->lang['ga_errorupl']}";
		$mklib->error_page($message);
		exit;
		}
	} else {
		//Move file from local server tmp directory to gallery "tmp" 
directory
		if (!move_uploaded_file("$file", "mkportal/modules/gallery/album/
tmp/$file_name")) {
			$message = "{$mklib->lang['ga_errorupl']}";
			$mklib->error_page($message);
			exit;
		}
	}
	@chmod("mkportal/modules/gallery/album/tmp/$file_name", 0644);
..
//Validate by mime type
$tmpfilename = "mkportal/modules/gallery/album/tmp/$file_name";
$size = @getimagesize($tmpfilename);
//If getimagesize does not recognize file as an image delete file
if (!$size)  {
	@unlink($tmpfilename);
	$message .= "{$mklib->lang['ga_notsup']}";
	$mklib->error_page($message);
	exit;
}
---------[/source code]--------------------------

So there exists timeframe, where temporary file is allready  moved to "tmp"
directory, but it is not yet deleted. If attacker manages to issue request
like this

http://localhost/mkportal.1.2.1/mkportal/modules/Gallery/album/
tmp/pic.php.pjpg

.. in right time, then remote php code execution may be possible.
It is classical race condition and success probability of single try is
very limited, but it's possible to make thousands of tries, until hitting
the jackpot. And by the way, "chmod(0644)" does not matter in specific case  :) 


4. Sql Injection in Blog module template editing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions:
 1. attacker must be registered user
 2. attacker must have blog editing privileges
 3. magic_quotes_gpc=off (rare in real-world servers)

Let's look at source code of "modules/blog/index.php" line ~1441:

---------------------[source code]---------------------
function save_template () {
		global $mkportals, $DB, $Skin, $mklib;
..
		$idb = $mkportals->member['id'];
		$template = $_POST['template'];
		$template = $this->clean_template($template);
		$template2 = $_POST['template2'];
		$template2 = $this->clean_template($template2);

		$DB->query("UPDATE mkp_blog SET template = '$template',
 template2 = '$template2' WHERE id = '$idb'");
--------------------[/source code]---------------------

No "addslashes()" or "mysql_real_escape_string()" is used, so sql injection
is possible, if "magic_quotes_gpc" setting is "off".

Proof of concept:

a) Go to blog template editing interface:

http://localhost/mkportal.1.2.1/index.php?ind=blog&op=edit_template

b) Insert text into the "Home Template" textarea:

',template=@@version,template2='

.. and hit "Update Template". As result MysSql version is shown instead
of blog content.



5. Reflected XSS in "handler_image.php"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions: none

Example:

http://localhost/mkportal.1.2.1/mkportal/modules/rss/handler_image.php
?i=<script>alert(123);</script>


6. Stored XSS in blog templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions:
 1. attacker must be registered user
 2. attacker must have blog editing privileges

MKportal offers blog functionality to all registered users. Blog access and
creation is enabled by default. Quick search in Google reveals, that many
websites have enabled blog module.

Google dork: inurl:"index.php?ind=blog"

Any registered user with blog editing privileges can modify his own
blog templates. Templates are stored in database. Blog owner can manipulate
templates html source in arbitrary ways, but some security filtering is
in place, in order to prevent inserting potentially malicious content
(Javascript, VBScript, ...) into blog templates.

Let's look at source code of "modules/blog/index.php" line ~1441:

---------------------[source code]---------------------
function save_template () {
		global $mkportals, $DB, $Skin, $mklib;
..
		$idb = $mkportals->member['id'];
		$template = $_POST['template'];
		$template = $this->clean_template($template);
		$template2 = $_POST['template2'];
		$template2 = $this->clean_template($template2);

		$DB->query("UPDATE mkp_blog SET template = '$template',
 template2 = '$template2' WHERE id = '$idb'");
--------------------[/source code]---------------------

So we can see, that security filtering is handled by function
"clean_template()". Let's look inside of this function:

---------------------[source code]---------------------
function clean_template ($t="") {
..
        while( preg_match( "#script(.+?)/script#ies", $t ) ) {
                $t = preg_replace( "#script(.+?)/script#ies", "" , $t);
        }
        $t = preg_replace( "/javascript/i", "", $t );
        //$t = preg_replace( "/about/i"	, "", $t );
        $t = preg_replace( "/vbscript/i"	, "", $t );
        $t = preg_replace( "/alert/i"	, "", $t );
        $t = preg_replace( "/onmouseover/i", "", $t );
        $t = preg_replace( "/onclick/i"	, "", $t );
        $t = preg_replace( "/onload/i"	, "", $t );
        $t = preg_replace( "/onsubmit/i"	, "", $t );

..
	$t = preg_replace( "/ecmascript/i"	, "", $t );
 	$t = preg_replace( "/about:/si"	, "", $t );
	$t = preg_replace( "/data:/si"	, "", $t );
	$t = preg_replace( "/onfocus/i"	, "", $t );
	$t = preg_replace( "/onblur/i"	, "", $t );
	$t = preg_replace( "/ondblclick/i"	, "", $t );
	$t = preg_replace( "/onmousedown/i"	, "", $t );
	$t = preg_replace( "/onmouseup/i"	, "", $t );
	$t = preg_replace( "/onmousemove/i"	, "", $t );
	$t = preg_replace( "/onmouseout/i"	, "", $t );
	$t = preg_replace( "/onkeypress/i"	, "", $t );
	$t = preg_replace( "/onkeydown/i"	, "", $t );
	$t = preg_replace( "/onkeyup/i"	, "", $t );
	$t = preg_replace( "/onunload/i"	, "", $t );
      $t = preg_replace( "/onabort/i"	, "", $t );
      $t = preg_replace( "/onerror/i"	, "", $t );
	$t = preg_replace( "/onchange/i"	, "", $t );
	$t = preg_replace( "/onreset/i"	, "", $t );
	$t = preg_replace( "/onselect/i"	, "", $t );	
	$t = preg_replace( "/document\./i"	, "", $t );
	$t = preg_replace( "/window\./i"	, "", $t );
	
..
        return $t;
    }

--------------------[/source code]---------------------

This kind of filtering is example of flawed-by-design implementation.
If someone wants insert javascript into blog template, then it's still
possible! Here are some working examples:

<body ononsubmitload=aleonsubmitrt(123);>

<salertcript>aalertlert(123);</salertcript>


7. Stored XSS in Reviews module comments functionality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions:
 1. attacker must be registered user
 2. attacker must have Reviews comments editing privileges

There are some security measures against script injection in comments
text, but still it's possible to sneak through those filters. Example:

<marquee loop=1 onfinish=alert(document.cookie) width=0></marquee>

This script will be executed, when someone opens review with this comment.
As result, cookie theft and other attacks may be possible. 


8. Stored XSS in News module comments functionality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: medium
Preconditions:
 1. attacker must be registered user
 2. attacker must have news comments editing privileges

Same story, as in previous case - filtering exists, but can be bypassed.



9. Full path disclosure in "index.php"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security risk: low
Preconditions: display_errors = Off

Example:

http://localhost/mkportal.1.2.1/?ind[]

Result:

Warning: Illegal offset type in isset or empty in 
C:\apache_wwwroot\mkportal.1.2.1\index.php on line 102



#  0day.today [2024-11-16]  #