Exploiting (pretty) blind SQL injections, (Mon, Feb 15th)

Although a lot has been written about SQL injection vulnerabilities, they can still be found relatively often. In most of the cases Ive seen in last couple of years, I had to deal with blind SQL injection vulnerabilities. Typically, they can be exploited relatively easy, by carefully modifying the resulting SQL queries and deducing the answer either by monitoring the resulting web page or, for example, by measuring the time it took for the answer to arrive.

What”>743994 OR 1=1 and off you go. Well, it wasnt that easy “>UNION didnt work either the application expected exactly certain values in the columns (not only column types) and all I could get with both of these cases was a nice, generic error screen (hey, no insufficient error handling either!).

The idea here was to prove that this is exploitable and although it looks a bit more complex, it is certainly exploitable here”>queueID = 743994 AND 1=1
queueID = 743994 AND 1=2
queueID = 743995
queueID = 743994

The first 3 queries all return a no results page. The last one returns the generic error page due to the SQL error that happened in the background. A tough cookie.

As with any blind SQL injection vulnerability, we need a true/false cases. And if you take a look we actually have them: the true case can be the no results page, while the false case can be the error page. The only question that remains is how to provoke the error page its easy to do manually by entering a “>queueID = 743994 AND1 = 1 / (select case when substr(banner, 1, 1) = A then 1 else 0 end from (select banner from v$version where banner like %Oracle%”>substr() call) and compared to the letter A. If it is A, the query returns 1, otherwise it returns 0.”>1 = 1 / 0. The former will display the no results page while the latter will display the error page. Game over!
In this particular case the goal was to show what an attacker can do with the vulnerability. While it was relatively easy to confirm its existence, by showing that arbitrary data can be retrieved from the database, the resulting risk indeed gets pretty high.