Dangerous vBulletin exploit in the wild

vBulletin is a popular proprietary CMS that was recently reported to be vulnerable to an unspecified attack vector. vBulletin is currently positioned 4th in the list of installed CMS sites on the Internet. Hence, the threat potential is huge.

Although vBulletin has not disclosed the root cause of the vulnerability or its impact, we determined the attacker’s methods. The identified vulnerability allows an attacker to abuse the vBulletin configuration mechanism in order to create a secondary administrative account. Once the attacker creates the account, they will have full control over the exploited vBulletin application, and subsequently the supported site.

Initial analysis

Although vBulletin has not disclosed the root cause of the vulnerability or the impact on customers, they did provide a workaround in a blog post encouraging customers to delete the /install, /core/install in vBulleting 4.x and 5.x respectively.

Additionally, on vBulletin internal forums a victimized user shared his server’s Apache log, providing some visibility into the attacker’s procedure:

This log indicates that the attacker continuously scans, using “GET” requests, for the “/install/upgrade.php” vulnerable resource. Once successful , indicated by the “200”response code, as opposed to “404” response code for non-existing resources, the attacker issues a “POST” request to the same resource with the attack payload. Since the Apache logger does not log the parameters of POST requests, the details of the attack are not yet revealed.

Once we had access to some concrete technical details on the vulnerability, we were able to effectively scan hacker forums in search of an exploit code. Soon after, we found PHP code that implements the attack.

Next, we carefully installed the code in our lab. The interface clearly states the goal of the attack: injecting a new admin. In order to exploit the vulnerability and inject a new Admin user, the attacker needs to provide the following details:

• The vulnerable vBulletin upgrade.php exact URL
• The customer ID.

To get these details, the attackers created an additional auxiliary PHP script. The script scans a site for the vulnerable path, exactly as shown above in the reported Apache log, and extracts the customer ID from the vulnerable upgrade.php page, as it’s embedded within the page’s source code.

Consequently, the attacker now knows both the vBulletin’s upgarde.php vulnerable URL and the customer ID. With this information, the attack can be launched.

Here is an example of the POST request with the attack payload (the red fields match to the information the attacker needed to enter in the PHP interface above).

The result of the attack was exactly what the exploit package described. A new admin user was created (“eviladmin”) that is under the control of the attacker. The site has been successfully compromised.

Recommendations:

• vBulletin has advised its customers to delete /install and /core/install directories in versions 4.x and 5.x respectively.
• For vBulletin users not able to delete these directories – it is advised to block access or redirect requests that hit upgrade.php through via either a WAF, or via web server access configuration.

Barry Shteiman, Director of Security Strategy at Imperva.