Sunday, May 29, 2011

Reliably exploiting vBulletin 4

Last month an SQL Injection vulnerability in the vBulletin search feature was patched. The issue was researched fairly well by j0hnx3r, and his research was made public here.

After reading about this issue, I set out to write a Metasploit module for it, and soon realized that the way of exploiting the issue outlined in j0hnx3r's research could be unreliable under certain circumstances such as:
  •  No groups exist, and the attacker can not access user groups
  • The attacker is unable to get a valid forum account
There are probably other scenarios that make exploiting this in a straight forward manner a bit unreliable, but I decided to focus my attention on creating something more reliable, versus exploring the limitations of a more straight forward approach.

During my research in to this issue, I found a couple of interesting things to help aid an attacker in mounting a successful SQL Injection attack against a vulnerable vBulletin installation.
  • This issue can be exploited pre auth
  • The SQL Injection takes place before the CAPTCHA is handled
  • The SQL Injection takes place before flood controls
As a result this issue can be exploited pre auth by an anonymous user regardless of CAPCTHA or flood settings, making it a pretty darn scary bug if you ask me. In order to exploit this issue I ended up using a blind BENCHMARK() enumeration approach since there are a myriad of issues relating to outputting retrieved data that I did my best to avoid altogether.

vBulletin 4 <= 4.1.2 SQL Injection Exploit (Metasploit)


  1. Hello,
    i'm trying your exploit on a local install of vbulletin, this is the output of the exploit with debug enabled, i've tried also to increase valute to 5 and 10 and 20, same result.

  2. an excellent Work man . . .truly . . .chapeau ! . .

    but well . . i have one question . .
    i keep receiving :
    - Request Entity Too Large<-
    The requested resource- /forum/search.php -
    does not allow request data with POST requests, or the amount of data provided in
    the request exceeds the capacity limit.

    in verbose mode . ..
    hmmm . .any thoughts ?