vBulletin SQL Injection Exploit is released. On June 18th, vBulletin forum pushed a patch for the SQLi injection, which is still working on the number of the website according to our research. If you’re using a version of vBulletin 4 older than 4.2.2, the cyber criminal could probably hack you. Moreover, they could most probably infect all your visitors with ransomware or trojan.
The vulnerability is easy to exploit and so could be used to dump the entire database of the forum. The vBulletin SQL Injection Exploit details are already published publicly.
The exploit resides in the forumrunner, which ships along with vBulletin core files.
x.x.x.x – – [17/Jul/2016:13:45:00 -0400] “GET /forumrunner/request.php?d=1&cmd=get_spam_data&postids=-1)union%20select%201,2,3,(select%20(@x)%20from%20(select%20(@x:=0x00),(select%20(0)%20from%20(user)where%20(0x00)%20in%20(@x:=concat(@x,0x3c62723e,username,0x3a,password,0x3a,salt,0x3a,email))))x),5,6,7,8,9,10–%20- HTTP/1.1” 200 13360 “-” “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0.1
In the First view, this seems to be a blind SQL injection and hence looks most probably difficult to dump the data. However, with a simple GET request.PHP, the attacker can extract the username and password with salts.
As you can see, the forumrunner/request.php is calling /forumrunner/support/
Now, in order to find the root cause of the SQL injection, we will have to investigate in the /support/common_methods.php.
Consequently, after a few hours of code analysis you will find the the moderation.php on line number 665
As you can see, the threadid and postids are declared as TYPE_STRING. TYPE_STRING type variable is not protecting from the SQL injection.
Further, the SQL query uses these variables as shown in the below image.
On the line number 758, the query uses the $postids and this is the postid that is causing the vBulletin SQL Injection Exploit.
In order to stop this vulnerability, you simply need to download the latest version of the vBulletin or download the patch