Raise your hand if you've ever had sqlmap fail to find or exploit a vulnerability you knew to exist? I imagine there's a lot of folks with their hands up right now. Okay, put your hands down.

I'll be the first person to tell you that sqlmap can almost always be tuned to discover a SQL injection vulnerability found through other means. I'll also be the first to recommend never using sqlmap to discover new SQL injection vulnerabilities. While discovering SQL injection vulnerabilities is not a strength of sqlmap, it is without a doubt the king of exploiting them. The trick is, sqlmap has to discover the vulnerability before it can exploit it. So if it can't discover it, it can't exploit it... you know where I'm going with this. The bottom line is, there is only so much you can do with command line switches and sometimes you run into edge cases where sqlmap just doesn't get it. Hence, the reason for this blog article.

I was on a test recently where I discovered a timing-based blind injection vulnerability in an ORDER BY clause that prevented the use of single quotes. I searched the vast sqlmap help file, explored the tamper scripts, and spent several hours trying to get sqlmap to discover the vulnerability I had found. The developer of sqlmap could probably have configured sqlmap to find it, but I could not. I can honestly say this was the first time this has happened to me. I've talked to many people that say it happens all the time, but I'd be willing to bet it was a result of them not knowing the sqlmap configuration options or the vulnerablity well enough to tell sqlmap how to find it. But I digress. Sqlmap wasn't doing it for me this time.

So I decided to use Burp Intruder. If you've never done blind SQL injection enumeration with Intruder before, it's actualy quite fun. You create insertion points for each part of the query that needs to be enumerated, then you create the associated payload sets and run the attack. Sorting by various columns depending on the vulnerabilty will allow you to determine what was enumerated by the attack. The biggest problem with this approach is that Intruder isn't smart enough to stop enumerating when a successful character is enumerated from one of the payload sets. Therefore, it has to continue all of the other payloads in the set, which at this point we know are going to fail. When the vulnerability is timing-based, this can result in extended wait times. Also, it's extremely noisy from a monitoring perspective. In this case, the timing condition was any response that took longer than two seconds to respond. Start doing the math. Yeah.

I've built my career on finding gaps and filling them. The space between Intruder and sqlmap with regards to exploiting complex SQL injections is space worth filling. So I built something.

https://github.com/lanmaster53/sqli-exploiter

Be warned, this is not a script kiddie tool. Usage requires detailed knowledge of the vulnerability, a thorough understand of the functionality available in the affected RDBMS, and the ability to write Python. However, the good news is that it is highly configurable as a result. I can't imagine an injection scenario that it can't be configured to exploit. Give it a shot and let me know what you think.