One year ago, an SQL injection vulnerability was reported for vBSEO 3.6.0. A parameter (aids) wasn't properly sanitized before being included in an SQL query, resulting in a supposed Time-Based Injection. As vBSEO is (was) quite common on the Internet, we decided to take a look and explore the vulnerability in detail.
The "useful" code is the following:
We can see that vbseo_get_forum_announcement() is called twice, with different parameters:
That is quite a lot of code, so let us sum it up for you:
1) Upon having only the $r_ann_id parameter, vbseo_get_forum_announcement is called.
$fanna = vbseo_get_forum_announcement(0, $r_ann_id);
2) Here comes the vulnerable SQL query:
If we go for the time-based injection, we are done. The query was executed and we get our trigger. Let's nevertheless take a deeper look.
3) Let's now say we have results, somehow; we enter the if($rid) and the while loop.
4) The for loop is executed once, since the $ids array contains only 0 (zero). We therefore obtain:
$vbseo_gcache['forum']['announcement'][$arr['announcementid']] = $arr['title'];
Therefore, the 3rd column of our SQL result, $arr['announcementid'], is stored in the $vbseo_gcache['forum']['announcement'] array, under the key $arr['announcementid'], the second column of our result.
5) We reach the "return $arr;" statement. That is, the data returned by this function is the first row of the SQL results.
After this, the vbseo_announcement_url() function is called, with parameters $r_forum_id, zero in our case, and $r_ann_id, our injection string.
This function simply fetches the announcement title ($ann_title) from the cache:
$ann_title = $vbseo_gcache['forum']['announcement'][$announcementid];
and returns an URL containing it. The user is then redirected to the URL.
Therefore, if we can put SQL results in $ann_title, we can fetch them easily afterwards by looking up the Location header. We've got our UNION injection. Well, not quite yet. Now comes the tricky part.
What do we control?
1) Well, first off we control $r_ann_id, which is our injection string.
2) Second, we potentially control what vbseo_get_forum_announcement() returns, since it is the result of our injected SQL query. So we control the $fanna array, which is the result of a single-row 3-column SQL query, with columns referenced as (forumid, announcementid, title).
3) vbseo_get_forum_announcement() also set values in the cache, and that is: $vbseo_gcache['forum']['announcement'][$fanna['announcementid']] = $fanna['title'];
4) We know that the value $vbseo_gcache['forum'][$forumid]['announcement'][$r_ann_id] will be contained in the Location header of the HTTP response.
Therefore, we need $r_ann_id to be equal to $fanna['announcementid']. But we also need $r_ann_id to be our injection string. Hence, the second row of our SQL result must be equal to... our SQL injection string.
The semi SQL Quine
First of, what is Quine? Let us refer to Wikipedia:
A quine is a computer program which takes no input and produces a copy of its own source code as its only output. The standard terms for these programs in the computability theory and computer science literature are self-replicating programs,self-reproducing programs, and self-copying programs.
After some Google searches, one can easily find SQL Quines. The problem here is that we do not only need the injection to self-copy itself, but also produce a result. We also have some contraints due to the fact that we need the result to be returned first, because vbseo_get_forum_announcement() returns after fetching the first result.
We figured the best way to handle this problem was to define two variables:
@x would be defined first and contain the end of the injection string, the part after the definition of @y.
@y would be defined second and contain the beginning of the injection string, including the definition of @x.
Using this scheme allows us to define @y in function of @x since @x is defined first. On the other hand, @x would not have to define @y because it doesn't include it. After some time, we came up with a solution:
' UNION SELECT 2,NULL,@x:=' UNION SELECT 3,NULL,@y:=CONCAT(\'\\\' UNION SELECT 2,NULL,@x:=\', quote(@x)) UNION SELECT 1, CONCAT(@y, @x), [INNER_QUERY] ORDER BY 1 LIMIT 1 -- -' UNION SELECT 3,NULL,@y:=CONCAT('\' UNION SELECT 2,NULL,@x:=', quote(@x)) UNION SELECT 1, CONCAT(@y, @x), [INNER_QUERY] ORDER BY 1 LIMIT 1 -- -
The ORDER BY 1 LIMIT 1 unsures that only the last row of these 3 UNION clauses is returned, instead of returning @x or @y.
Now one might think that implementing it would require re-inventing the wheel and be a very annoying task, but not if we use a proper framework. Elliot represents injection methods such as Blind, Union-based, Time-based SQL injection as standard python classes. We'll now see how to create a custom injection method. The aim is to get results from an SQL statement.
The StackedMethod is one of the most used abstract class; it's only requirement is the inject() method. The injection process is the following:
1) The to-be-injected statement is transformed so that instead of producing an array of results, it produces a simple string, with results separated and marked. For instance:
SELECT username, password FROM userswould become
SELECT CONCAT([TAG], username, [SEPARATOR], password, [TAG]) FROM users
2) When possible, a method is used so that instead of producing several rows, it only produces one. That is, the whole array of SQL results is compiled as a single string.
3) This statement is fed to the inject() method, that returns the page containing the results.
4) The results are afterwards parsed out of the page.
Here is an Elliot SQL injection method designed specifically for this exploit:
Let's try it out:
With some thinking and the help of the Elliot framework, we were able to drastically improve the time required to run the exploit. Indeed, we went from the slowest type of injection, time-based, to the fastest, union. The use of the framework allowed us to design a very specific exploitation in the matter of minutes.