Telling sqlmap to Try Harder

When I first started learning about penetration testing sqlmap quickly became one of my favorite tools. For those who haven’t used it, sqlmap is a command line tool which automates the detection and exploitation of SQL injection flaws.

I started by feeding sqlmap  URLs which contains a variable in the URL. The command for a URL like this is:

./sqlmap.py -u "http://172.16.222.100/gallery/gallery.php?id=null"

Once the command is run sqlmap will automatically try a variety of SQL injection techniques to find vulnerabilities.  If it finds a vulnerability it will ask you if it can stop, once you say yes then you can rerun sqlmap with a variety of different options which can do everything from attempting to use the injection vulnerability to give you a shell to using the vulnerability to dump all of the information from the database. If you’re dumping a database and sqlmap recognizes encrypted password hashes it will even ask you if you’d like it to try to crack the password.

After I had already fallen in love with sqlmap I started to notice that quite a few websites didn’t have the variables in the URL as they were using POST instead of GET. That forced me to slightly broaden my repertoire and insert Burp Suite into the mix.

Burp Suite has a ton of functions (most of which I’m not familiar with yet) but it’s main function is acting as an intercept proxy between your web browser and the website it’s viewing. By starting up Burp Suite and telling your web browser to send all traffic through Burp Suite (usually done by switching settings to port 8080) Burp Suite will then act as a middle man and capture all of the traffic routed through it, including traffic that would otherwise not be seen such as components of a HTTP POST request.

Once you have the data from the POST request then you can incorporate that information into your sqlmap request with the –data command like this:

./sqlmap.py -u http://172.16.222.200 --data="uname=admin&psw=adminuser&btnLogin=Login"

If sqlmap finds a SQL injection vulnerability from this command great, but mine did not. The first thing I tacked on was to specify which database the web application is using with the dbms command like this

./sqlmap.py -u http://172.16.222.200 --data="uname=admin&psw=adminuser&btnLogin=Login” –dbms=mysql

Sqlmap then knows to A: not waste it’s time  with commands designed for other database systems and B: format generic commands to be MySQL specific.

How would you know what database a web application was using? Methods I’ve been able to use so far are:

• Forcing a bunch of junk data into an input field to get an error. The error will usually give away which database system is being used.
• Check the nmap scan results to see which services were identified as it will often discover the database server.
• Make an educated guess based upon OS fingerprinting.

Even with me specifying that the database was MySQL sqlmap still wasn’t able to find an SQL injection vulnerability.

My next option was to tell sqlmap (to borrow a phrase from Offensive Security) to “try harder” by adding a level argument:

./sqlmap.py -u http://172.16.222.200 --data="uname=admin&psw=adminuser&btnLogin=Login” –dbms=mysql –level=5

This literally makes sqlmap try harder. For example, by default sqlmap checks for MySQL UNION query 1-10 columns. By adding in –level 5 sqlmap goes all the way to 50 columns. I’ve already found one database that wasn’t compromised until the 40-50 column scan.

Even after all of this sqlmap STILL didn’t find a SQL injection vulnerability. I ended up trying one last thing, I used the risk argument to tell sqlmap to go ahead and run “riskier” commands in an attempt to find vulnerabilities. The command is used just like level:

./sqlmap.py -u http://172.16.222.200 --data="uname=admin&psw=adminuser&btnLogin=Login” –dbms=mysql –level=5 –risk=3

FINALLY after a lengthy scan sqlmap found a sql injection vulnerability on this system and I was up and running. The level and risk arguments can make the scan take A LOT longer but if you have the time they’re well worth trying. They don’t work every time but they’ve worked often enough for me to keep on using them.