SQLmap is an automated SQL injection tool.
It is very practical in pentests to send a lot of payloads, and find injections that would have gone unnoticed with basic manual tests.
However, some SQL injections require the pentester to script the exploit himself: injections too complex to be detected by sqlmap, server too unstable, and other edge cases.
Some lesser known features of SQLmap can still allow its use despite complex use cases.
This article, intended for advanced SQLmap users, details two of them:
SQLmap request encoding
A DSecBypass pentester encountered a web application that only accepted base64-encoded HTTP POST request bodies.
In this specific case, SQLmap cannot do anything by default: randomly modifying the request body would make the encoding and the data invalid.
However, manual tests show that behind this block of base64 text hides a JSON object, one of whose parameters is vulnerable to SQL injection.
To overcome this problem, tamper scripts can be used. Initially created to modify payloads in order to circumvent application firewalls (WAF), it is possible to create your own script to manipulate the data generated by SQLmap.
Creating and using a Python tamper script is simple:
- In your working directory, create an empty Python file named “__init__.py” ;
- Create a Python3 script “mytamper.py” with the following content:
- Use this script with the following command being in the same directory as the Python files:
sqlmap --random-agent -o -u "https://[...]/application/process/" --data "*" --header "Content-Type: application/octet-stream" --method POST --tamper mytamper.py --random-agent
SQLmap then uses our script to modify each test performed before sending it to the server.
Two-step injections
SQLmap natively offers a solution for ‘second-order‘ injections, ie SQL injections that are exploitable because a second, vulnerable query uses the result of a first, non-vulnerable one.
The tool then proposes the ‘–second-url‘ or ‘–second-req‘ parameters to fetch the result of the injection respectively by a GET on a URL or by replaying the request contained in a file (like ‘-r‘).
This already covers a lot of use cases, however a DSecBypass pentester encountered an application with second-order SQL injection whose second request requires a parameter update.
First POST request (the payload is stored in database)
Second POST request (a vulnerable SQL request uses the stored result of our first request)
The second image shows the ts parameter, derived from the Unix timestamp. If it is invalid, the request is not accepted and SQLmap will not be able to correctly exploit the injection.
Fortunately, the tool offers a mechanism of last resort: postprocessing scripts.
It is again quite simple to use:
- In your working directory, create an empty “__init__.py” file
- Create a Python3 script “mypostproc.py” with the following content:
- We exploit the injection with the following SQLmap command (use of “-r” to indicate to SQLmap to work from a file from the first HTTP request)
sqlmap -r sqli_my_application --force-ssl --dbms postgresql --level 5 --risk 2 --postprocess mypostproc.py --current-user --technique "ST"
Note that this technique works with all types of injection, even time-based since SQLmap will also take into account the execution time of the postprocessing script.
If you are using a proxy with SQLmap, it is also possible to specify it in the Python call to requests with the “proxies” argument.
🛡️ DSecBypass accompanies you on the security audit of your Web applications. Do not hesitate to contact us for additional information and/or a personalized quote 📝.
