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

2009-01-16T00:00:00
ID SECURITYVULNS:DOC:21173
Type securityvulns
Reporter Securityvulns
Modified 2009-01-16T00:00:00

Description

[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 &#40;!$file&#41; {
                    $message = &quot;{$mklib-&gt;lang[&#39;b_compfile&#39;]}&quot;;
                    $mklib-&gt;error_page&#40;$message&#41;;
                    exit;
            }

            //Validate file extension
            $file_ext = preg_replace&#40;&quot;&#96;.*&#92;.&#40;.*&#41;&#96;&quot;, &quot;&#92;&#92;1&quot;, $file_name&#41;;
            $file_ext = substr &#40;$file_name, &#40;strlen&#40;$file_name&#41;-3&#41;, 3&#41;;
            $file_ext = strtolower&#40;$file_ext&#41;;

            switch&#40;$file_ext&#41;
            {
                    case &#39;gif&#39;:
                            $ext = &#39;gif&#39;;
                            break;
                    case &#39;jpg&#39;:
                            $ext = &#39;jpg&#39;;
                            break;
                    case &#39;png&#39;:
                            $ext = &#39;png&#39;;
                            break;
                    case &#39;tif&#39;:
                            $ext = &#39;tif&#39;;
                            break;
                    case &#39;bmp&#39;:
                            $ext = &#39;bmp&#39;;
                            break;
                    default:
                            $ext = &#39;not_supported&#39;;
                            break;
            }
            if &#40;$ext == &quot;not_supported&quot;&#41;  {
                    $message = &quot;{$mklib-&gt;lang[&#39;b_gnotsup&#39;]}&quot;;
                    $mklib-&gt;error_page&#40;$message&#41;;
                    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 = &quot;mkportal/blog/images/tmp/$file_name&quot;;
            $size = @getimagesize&#40;$tmpfilename&#41;;
            //If getimagesize does not recognize file as an image delete file
            if &#40;!$size&#41;  {
                    @unlink&#40;$tmpfilename&#41;;
                    $message .= &quot;{$mklib-&gt;lang[&#39;error_filetype&#39;]}&quot;;
                    $mklib-&gt;error_page&#40;$message&#41;;
                    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 &#40;!$mklib-&gt;check_attach&#40;$file_type, $file_ext&#41;&#41;  {
                    //Delete invalid file and display error
                    @unlink&#40;$tmpfilename&#41;;
                    $message .= &quot;{$mklib-&gt;lang[&#39;b_gnotsup&#39;]}&quot;;
                    $mklib-&gt;error_page&#40;$message&#41;;
                    exit;
            }

            //Validate by file contents
            $fcontents = file_get_contents &#40;$tmpfilename&#41;;
            $carray = array&#40;&quot;html&quot;, &quot;javascript&quot;, &quot;vbscript&quot;, &quot;alert&quot;,

"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.

  1. 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.

  1. 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 :)

  1. 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-&gt;query&#40;&quot;UPDATE mkp_blog SET template = &#39;$template&#39;,

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.

  1. 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>

  1. 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-&gt;query&#40;&quot;UPDATE mkp_blog SET template = &#39;$template&#39;,

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>

  1. 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.

  1. 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.

  1. 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

Greetings: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Greets to ToXiC, y3dips, Sm0ke, Heintz, slimjim100, pexli, mge, str0ke, to all active waraxe.us forum members and to anyone else who know me!

Contact: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

come2waraxe@yahoo.com Janek Vind "waraxe"

Waraxe forum: http://www.waraxe.us/forums.html Personal homepage: http://www.janekvind.com/ ---------------------------------- [ EOF ] ---------------------------------