At the most recent Austin Hackers Association meeting I unveiled a project I've been working on for a couple months now called "SQLol". I was helping a colleague to exploit an SQL injection flaw in the wild with a MySQL backend database. It was a blind SQL injection flaw but none of the myriad of tools available to automate SQL injection were working properly.
I knew a technique existed for extracting data from verbose errors in SQL Server: Cast a non-numeric string to an integer and you'll get an error like the following:
"Failed to cast varchar value 'whateverstringyouwerecasting' to type int."
What's interesting about this error is that you can do a subquery to pull some bit of information out of the database and then have it handed to you in an error message by casting it to an integer. I have a feeling that this sort of extraction method is possible for any type of database you can encounter, it's just a matter of poking through the error messages the database can throw, picking out the ones with dynamic parts (usually they have %s somewhere in there) and figuring out how to get the data you want into one of them.
With some experimentation and research, we found an error-based extraction technique for MySQL and were able to pull data from the database much faster than we could have with blind SQL injection techniques. I mused about the many different techniques for data extraction from SQL injection flaws and lamented the fact that I have never seen a vulnerability test-bed that includes SQLi verbose error extraction techniques. For that matter, I have never seen a vulnerability test-bed which includes SQL injection in a DELETE query. The vast majority of the SQLi fu I have acquired over the years is through real-world exploitation, which is certainly sub-optimal.
So, with inspiration in hand, I set out to make a test-bed specifically for SQL injection flaws, one which would be useful to those who know nothing about SQLi, those who are on the dizzying edge, and all those in-between. To put it poetically, here's a sonnet in iambic pentameter about SQLol:
I humbly posit that the current state
(With much respect to work which does precede)
Of test-beds made with vulns to demonstrate
Is lacking some in flexibility.
Two options are presented present-day,
As far as when one deals with S-Q-L:
A blind injection (bool or time delay)
And UNION statement hax (oh gee, how swell…)
Imagine we could choose how queries read
And how our input sanitizes, oh!
How nimble and specific we could be
To recreate our 'sploit scenarios.
And thus is S-Q-L-O-L conceived:
That we can study how to pwn DBs.
Ahem. Now that I'm done being inexcusably geeky, let's examine some of the customization features that SQLol offers:
Type of query (SELECT, DELETE, INSERT, UPDATE, and custom)
Injection location (String/Int in WHERE clause, column name, ORDER BY clause, etc.)
Type and level of sanitization (Single quotes [remove, escape, double], keyword blacklist [three levels of difficulty], etc.)
Query result verbosity (No rows, One row, All rows)
Error verbosity (No errors, Generic errors, Verbose errors)
Additionally, SQLol comes with a set of challenges which task you with performing some flavor of SQL injection and have pre-configured settings. And if that's not enough, there's even a reset button which allows you to nuke the SQLol database from orbit and rebuild it, should you happen to make it useless, for instance when you experiment with DELETE query injection.
SQLol is be available on the SpiderLabs GitHub.
