SQL Injection Vulnerability – vBulletin 5.x

The vBulletin team just released a security patch for vBulletin 5.0.4, 5.0.5, 5.1.0, 5.1.1, and 5.1.2 to address a SQL injection vulnerability on the member list page. Every vBulletin user needs to upgrade to the latest version asap.

vBulletin is a very popular forum sofware used on more than 100,000 web sites.

Directly from vBulletin.com:

A security issue has been reported to us that affects the versions of vBulletin listed here: 5.0.4, 5.0.5, 5.1.0, 5.1.1, and 5.1.2 We have released security patches to account for this vulnerability. The issue may allow attackers to perform SQL injection attacks on your database. It is recommended that all users update as soon as possible.

You can download the patch for your version here: http://members.vbulletin.com/patches.php

This vulnerability was discovered by the Romanian Security Team (RST), so it could already be used in the wild on 0-day attacks. If you can’t patch vBulletin, we recommend blocking access to the memberlist page in the mean time.

If you are leveraging the Sucuri Website Firewall product, your website is already protected through our virtual patching signatures.

Security Exploit Patched on vBulletin – PHP Object Injection

The vBulletin team just issued a warning, and released patches for a security exploit that affected all versions of vBulletin including 3.5, 3.6, 3.7, 3.8, 4.X, 5.X. They recommend that anyone using vBulletin apply these patches as soon as possible. Here is part of their announcement:

A security issue has been found that affects all versions of vBulletin including 3.x, 4.x and 5.x. We have released security patches to account for this vulnerability. This includes patches for vBulletin 3.8.7, vBulletin 4.2.2 and all versions of vBulletin 5 (including Cloud accounts). The patch is also applied to vBulletin 5.1.0 RC1. It is imperative that you apply these patches as soon as possible.

Due to functionality changes, the minimum PHP version for the patch is 5.2.0. This represents an increase for vBulletin 3. Alternatively customers can install the JSON functions separately in which case it will work with any compatible PHP version that their particular version of vBulletin supports. You will need to collaborate with your hosting provider or systems administrator to apply the changes to PHP.

If you are using vBulletin, you know what to do: Patch now!

What really worries me from this announcement is that they increased their minimal PHP version requirement on the security patch. It means many webmasters will not be able to apply the patch quickly enough, and some may end up breaking their sites.

So, if your host is not running an updated version of PHP, you need to contact them ASAP to get it updated or your site will be vulnerable.

What a Security Exploit Means?

The vBulletin team provided no details on what exactly they patched, or what the vulnerability was. All they have said is it was a “security exploit”, which should be enough of a warning for people to update their forums.

Based on their patches, we were able to clearly see what the issue was:

They removed:
$temp = unserialize($check);
And added:
$temp = json_decode($check, true);

Later in the code where they were running “serialize($_POST”, they changed it to “json_encode($_POST)”. It appears like a PHP Object injection where they are passing user supplied data to an “unserialize” function.

This may lead to privilege escalation, remote code execution, or maybe even allow an attacker to run any PHP function they want. We don’t know how bad it is yet, but our team is still investigating this issue and trying to confirm the severity, and what can really be done.

Users running our Website Firewall are already protected against PHP Object injections, and we are building a custom virtual patching signature for it as well. Stay tuned for updates.

Security issue on vBulletin’s uploader.swf

The vBulletin team recently disclosed a XSS (cross site scripting) vulnerability in the uploader.swf file that is included by default on vBulletin 4 and 5. This file comes from the YUI library that is not supported anymore, so the vBulletin team is recommending everyone to remove that file asap from their installs.

This is their full note:

It has come to our attention that there is a security issue in the uploader.swf file included as part of the Yahoo User Interface (YUI) library included in vBulletin 4. As the version of YUI included in vBulletin is end-of-lifed, Yahoo will not be fixing this issue.

We recommend that you replace this with an empty file of the same name (attached). What this will do is force vBulletin to use a fallback javascript based uploader which is already provided in your system.

The vulnerable file is also present in the vBulletin 5 download package though not used by the vBulletin 5 front-end. We recommend that you delete the file and replace it with the attached file.

To resolve this issue take the following steps:

-Delete uploader.swf located in clientscript/yui/uploader/assets or /core/clientscript/yui/uploader/assets
-Replace it with the attached file.

If you run vBulletin, please remove that file as soon as you can. Note that users of our CloudProxy website firewall are already protected against this threat.

Stealing Credit Cards – A WordPress and vBulletin Hack

What better way to celebrate Thanksgiving than to share an interesting case that involves two of the most popular CMS applications out there – vBulletin and WordPress.

Here is a real case that we just worked on this week, involving an attacker dead set on stealing credit card information. Enjoy!

The Environment

The client runs a fairly successful e-commerce website. They run two main applications within their architecture – vBulletin and WordPress.

vBulletin is used for their support and collaboration forums, while WordPress for their main website and e-commerce. This appears to be a pretty standard configuration across most larger web application environments these days.

Everything is sitting on a LAMP (Linux / Apache / MySQL / PHP) stack, so nothing too special there. For the most part, things are up to date, they might be a version or two behind, but none of it earth shattering or something worth writing home about.

In regards to security, they are running CloudFlare.

All in all, it probably sounds a lot like your environment[s].

Read More

vBulletin.com Compromised

The vBulletin team recently announced that they suffered a compromise which allowed the attackers access to vbulletin.com servers and database. On their own words:

We take your security and privacy very seriously. Very recently, our security team discovered sophisticated attacks on our network, involving the illegal access of forum user information, possibly including your password. Our investigation currently indicates that the attackers accessed customer IDs and encrypted passwords on our systems. We have taken the precaution of resetting your account password. We apologize for any inconvenience this has caused but felt that it was necessary to help protect you and your account.


Read More

Potential vBulletin Exploit (4.1+ and 5+)

The vBulletin team just posted a pre-disclosure warning on their announcements forum about a possible exploit in versions 4.1+ and 5+ of vBulletin.

They don’t provide many details, but did state that webmasters need to remove the /install and /core/install from their websites. This is the full message:

A potential exploit vector has been found in the vBulletin 4.1+ and 5+ installation directories. Our developers are investigating this issue at this time. If deemed necessary we will release the necessary patches. In order to prevent this issue on your vBulletin sites, it is recommended that you delete the install directory for your installation. The directories that should be deleted are:

4.X – /install/
5.X – /core/install

After deleting these directories your sites can not be affected by the issues that we’re currently investigating.

vBulletin 3.X and pre-4.1 would not be affected by these issues. However if you want the best security precautions, you can delete your install directory as well.

Going back to our logs, we don’t see any specific scans for /core/install, but we see constant discovery requests for /install. We don’t yet know if that is related to vBulletin or other CMS’s.

Our team will be watching it closely, and any client under our CloudProxy WAF is already protected by it since we only allow access to the “install” directories by white listed IP addresses.

vBulletin Infections from Adabeupdate

vBulletin is a popular forum platform that is also starting to become a popular target for web attacks. vBulletin (and vbSEO) had some serious security vulnerabilities in older versions, and when a forum using them is not properly updated, it ends up hosting malware like the one we will analyze here in this post.

vBulletin in SiteCheck

Technical Analysis

vBulletin is very unique on how it stores its templates and plugins, It’s different than WordPress and Joomla, all the content is saved in the database. That makes it a bit more complicated for webmasters because they can’t just use common command line tools (like grep) to search through all their files. They need to use phpMyAdmin or another database tool to try to find and fix those issues.

Read More

vBulletin Conditional Malware – myFTP.biz Malicious iFrames

We have to be honest here, there’s no fun in cleaning up infected .htaccess files. It’s boring, but it happens a lot! But it’s not the case here. I will also caveat that while in this specific instance we’ll be talking to one specific platform, we are seeing this same tactic spread across a number of other popular platforms as well like Joomla and WordPress.

There are different types of infection, some are automated (like the htaccess I mentioned) and some are targeted and well crafted, like the one we saw today.

One of our clients was receiving complaints from the site’s readers that when accessing the site it was trying to do a drive-by-download, install malicious software on their computer[s].

When checking the page source we found the following code in the headers:

Screen Shot 2013-06-12 at 12.57.21 PM

This code translates into a hidden iframe:

Read More

Sneaky vBulletin Script Injections

In the past few days/weeks we have been seeing some nasty vBulletin infections that are proving difficult to find. In this post we’ll describe it and what we have done to remove it.

We recently wrote about Conditional Malware, this is but another instance of that. In this instance, the conditions are set around specific referrers and user-agents.

When a user visits the forum via Google search engine result pages (SERP), they are greeted with this payload:

Read More

vBulletin Websites Using VBSEO Being Infected with Malware

We are seeing a large number of vBulletin/vBSEO websites getting compromised lately and we keep getting requests for info as to what’s going on.


Read More