Friday, January 17, 2014

Using SQLMAP's Eval Functionality for Successful Exploitation

Recently I was performing a web application assessment and ran across a SQL injection bug. This bug was verified by two different tools and one of those tools was even able to pull back the database name, but nothing else. As usual, I turned to my favorite SQLi exploitation tool, SQLMAP.

After spending a while trying to get SQLMAP to find the injection being specific as I could and increasing the level flag, I began to realize that I was going to need to customize some parts of the requests. I eventually located the issue, being that a successful injection required a %09 (URL encoded version of a tab) instead of a %20 (URL encoded version of a space).

It is for this very type of scenario that SQLMAP implements the --eval flag, allowing the user to execute any python code at run-time before each request is sent. All you need to do is reference the parameter that you want to modify, such as "id", etc. The example in the wiki located here illustrates the proper syntax:
--eval="import hashlib;id2=hashlib.md5(id).hexdigest()"
In this instance they are setting "id2" parameter to the MD5 value of the "id" parameter.

Keeping this awesome feature in mind, I decided to use pythons replace() method to modify the space characters (%20) and replace them with tab characters (%09). We will also need to escape quotes so that we do not terminate the eval parameter.

My initial attack went something like this:
./sqlmap.py -l bob.txt -p email --eval="email=email.replace(\"%20\",\"%09\",15)" -v 5
This attack, however, still failed as the requests were still using the %20 as the space character instead of the %09.

After some digging through the source code, it was apparent that I would need to use the actual space character " " instead of its URL-encoded represetatation:
 ./sqlmap.py -l bob.txt -p email --eval="email=email.replace(\" \",\"%09\",15)" -v 5
This time I saw that the requests were being successfully modified and was greeted with the pretty green text:


This just shows one possible use for this super powerful flag within SQLMAP, and another reason why the tool is only as good as the tester using it, as this was the difference between a relatively* successful and unsuccessful exploitation.

* I say relatively because I ended up enumerating the username manually so i didnt technically need SQLMAP, but a tool like SQLMAP just makes extracting data SO much faster.

No comments:

Post a Comment