Our hacker Yosef Kerzner who helps us with Hadoop and Big Data hacking does all other kinds of exploits. Here is his latest on SQL injection attacks.
In December 2015 I joined a large consulting firm to perform vulnerability assessments and penetration tests, phishing assessments, and other projects in the realm of defending networks from intrusion. Prior to that, I worked for a company with an in-house application scanner verifying the scanner’s results and also performing several web application assessments each week. While verifying results I found just 1 certain SQL injection vulnerability and maybe 2 potential others. When doing manual web application assessments I found none (the cool stuff had already been picked out by the previous testing).
I wonder if hitherto unchecked internal environments are more likely to have SQL injection vulnerabilities, especially those that are home-rolled rather than provided by a third-party developer as part of an enterprise solution. As an example, let’s look at this site (specifics have been removed):
http://example.com/dir/default.asp?page=profile&action=lookup&option=Name&StrSearch=
We’re looking up user profiles, testing each parameter for generic XSS and SQL with something like <>”‘%^&*()[] or some other banging of the keyboard. And what do we see when we put a single tick in the StrSearch parameter?
Let’s pull out SQLMap and direct it at the StrSearch parameter, making sure to include the right cookies. Voila, it works!
A shell and all the database content our heart desires.
A second example. This one came courtesy of Nessus which flagged it as a potential Blind SQL injection, using a time-based injection. I wouldn’t have found it otherwise, as this was a pentest where the only IP information given was a list of IPs to exclude. The rest was up to me to find. I found 2100 live hosts and was told there are about 2500 total. Just the 2100 was enough for me.
Here’s the query string (some parameters removed):
http://example.com/index.asp?tbUserName=&tbPassword=&search=&a=verify&t=66
The potentially vulnerable parameter was “t”. After verifying that a time-based injection worked (ala ;WAITFOR DELAY ‘0:0:5’–) by sending various commands that request for a response after a certain number of seconds, I fed it to SQLMap.
Payload: 66 UNION ALL SELECT NULL,CHAR(113) etc etc
And oh hey, look, all the database tables of this company. Users, passwords in clear text (from some tables), PII (which I didn’t dare touch), all your greedy little heart desires. The passwords looked like they came from a time before minimum password restrictions because “1v10” isn’t terribly secure.
So in conclusion: SQL injection is super rare but when you find it you get the keys to the kingdom.