vBulletin <= 4.2.3 SQL Injection

The vBulletin core forumrunner addon (enabled by default) was affected by an SQL injection vulnerability but gained little to no coverage but a mere forum post. Well, until now.

What is ForumRunner?

Forum Runner is a vBulletin, XenForo, myBB, and phpBB forum add-on that allows your users to access your forum at blazing fast speeds by using a native application installed on their mobile phone (Android or iPhone) or iPad/iPod Touch device

Technical Overview

Versions affected:

• vBulletin 3.6.x – 4.2.3

I have decided not to disclose any exploit code along with this article due to the fact that many forums are still affected. The code excerpts that are shown below are from unpatched vBulletin 4.2.2 software.

vBulletin’s code standards use clean_gpc() and clean_array_gpc() functions to sanitize input data, so PHP superglobal arrays are not accessed directly. I would use the word ‘sanitize’ very loosely here, as this vulnerability has just proven that these sanitizing functions are simply not enough.

The root of the vulnerability, /forumrunner/includes/moderation.php:

function do_get_spam_data() {

…..

$vbulletin->input->clean_array_gpc(‘r’, array(
‘threadid’ => TYPE_STRING,
‘postids’ => TYPE_STRING,
));

……

 

} else if ($vbulletin->GPC[‘postids’] != ”) {
$postids = $vbulletin->GPC[‘postids’];

$posts = $db->query_read_slave(”
SELECT post.postid, post.threadid, post.visible, post.title, post.userid,
thread.forumid, thread.title AS thread_title, thread.postuserid, thread.visible AS thread_visible, thread.firstpostid
FROM ” . TABLE_PREFIX . “post AS post
LEFT JOIN ” . TABLE_PREFIX . “thread AS thread USING (threadid)
WHERE postid IN ($postids)
“);

……

So as we can see from the snippet above, you can see that user input, ($_REQUEST[‘postids’] and $_REQUEST[‘threadid’], both vulnerable) is placed in the $vbulletin->GPC array after being filtered as TYPE_STRING. Then these values are being passed to the database after having undergone this ‘sanitizing’. So what’s the problem? Oh, this type of sanitizing variables looks very familiar . Values filtered as TYPE_STRING do not protect from SQL Injection. It seems that forumrunner had forgotten to use the integer value of these parameters (intval()) as they had done in seemingly every other function in the addon regarding these variables.

The do_get_spam_data() function template and include is made from /forumrunner/support/common_methods.php

…….

/*
* get_spam_data
*
* input:
*
* threadid
* postids
*
* output:
*
* success
*/
‘get_spam_data’ => array(
‘include’ => ‘moderation.php’,
‘function’ => ‘do_get_spam_data’,
),

……

After backtracing the get_spam_data() method we finally reach the hole in the wall where it can be called from, in /forumrunner/request.php

……

$processed = process_input(array(‘cmd’ => STRING, ‘frv’ => STRING, ‘frp’ => STRING));
if (!$processed[‘cmd’]) {
return;
}

…….

if ($methods[$processed[‘cmd’]][‘include’]) {
require_once(MCWD . ‘/include/’ . $methods[$processed[‘cmd’]][‘include’]);
}

if (isset($_REQUEST[‘d’])) {
error_reporting(E_ALL);
}

$out = call_user_func($methods[$processed[‘cmd’]][‘function’]);

…..

From this snippet we can see that we can call the vulnerable get_spam_data() function through $_REQUEST[‘cmd’] parameter (process_input function passes each value from the $_REQUEST superglobal array in /forumrunner/support/utils.php). Setting the $_REQUEST[‘d’] parameter is also handy as it will turn on error reporting which assists with the SQL injection itself. All that’s left is to pass our SQL payload to $_REQUEST[‘postids’]. Combine these three things and you’ve got yourself a working exploit.

The Patch

Patch(es) for various versions can be downloaded from the vBulletin member’s area.

The main addition to the patch was the introduction of the fr_clean_ids function in /includes/general_vb.php

function fr_clean_ids($list = ”)
{
$arr = explode(‘,’,$list);
$cleanarr = array_map(‘intval’,$arr);
return implode(‘,’,$cleanarr);
}

The function gets the integer value that we passed to the parameters and returns it, preventing the injection.

This is called twice within the do_get_spam_data() function in /forumrunner/include/moderation.php , sanitizing both the $postids and $threadids parameter

….

$vbulletin->GPC[‘postids’] = fr_clean_ids($vbulletin->GPC[‘postids’]);

….

if ($vbulletin->GPC[‘threadid’] != ”) {
$threadids = $vbulletin->GPC[‘threadid’];

$threadids = fr_clean_ids($threadids);

….

 

To Wrap Up

Due to how low key this vulnerability has been kept by the vBulletin team, it comes as no surprise that many forums are still vulnerable to it in the wild. In order to raise awareness I have contacted cve.mitre.org and they have assigned it to CVE-2016-6195.

Advertisement