sqlmapproject
SQLMAP wasn't able to detect MS SQLI
Describe the bug SQLMAP wasn't able to detect MS SQLI
Successfull Time Based SQL Injection payload should be:
admin' WAITFOR DELAY '0:0:5'-- aZMe
It tested admin') WAITFOR DELAY '0:0:5'-- but not admin' WAITFOR DELAY '0:0:5'--
SQLMAP command I used:
python3 /home/nishant57/BB/sqlmap-dev/sqlmap.py -r req.txt --timeout 60 --threads 10 --flush-session --proxy "http://username:[email protected]:8082" -p TextBox1 -v 3 --dbms=MSSQL --technique=T --level 5 --risk 3
Screenshots
Running environment:
- sqlmap version [1.8.4.5#dev]
- Installation method [git clone]
- Operating system: [Debian 11]
- Python version [3.11]
Target details:
- DBMS [Microsoft SQL Server]
- SQLi techniques found by sqlmap [Time based]
- WAF/IPS [ModSecurity Trustware(Plesk)]
Hii @stamparm,
Sorry for providing insufficient information initially. The issue is not with the target having a WAF; it's actually more complex than that. I managed to solve it by setting some Match and Replace rules in BurpSuite. Initially, I thought it was an isolated case with just this target, so I decided to move on. However, I encountered a similar situation with another target.
The target I am currently testing has geo-restrictions, which prevent access from my country. Therefore, I am using a residential proxy in the BurpSuite upstream settings.
Additionally, the target uses CloudFront WAF. I discovered the Origin IP, and now I need to set the target as an IP and the Host header as the domain hostname, similar to a VHOST.
I saved the request in a req.txt file as follows:
POST /account/login/ HTTP/1.1
Host: 13.115.51.219
Content-Length: 172
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="99", "Chromium";v="124"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
Origin: https://www.example.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Priority: u=0, i
mobile1=1234567890&Password=Test12345&stay_signed_in=0&nextAction=login
In this, I used Host: 13.115.51.219 so SQLMAP sets the target as http://13.115.51.219/, and then in the SQLMAP command, I have to use --force-ssl to make it use port 443 instead of 80.
My SQLMAP command looks like this for intercepting SQLMAP requests/responses in BurpSuite:
python3 sqlmap.py -r req.txt --timeout 50 --threads 10 --level 3 --risk 1 --flush-session --fresh-queries --proxy "http://127.0.0.1:8080" --force-ssl
Then, in BurpSuite, when I see the request, it's like this:
POST http://13.115.51.219/account/login/ HTTP/1.1
Host: 13.115.51.219
Content-Length: 172
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="99", "Chromium";v="124"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
Origin: https://www.example.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Priority: u=0, i
mobile1=1234567890&Password=Test12345&stay_signed_in=0&nextAction=login
Which, for obvious reasons, will not work.
To solve the VHOST issue, I can use this Match and Replace rule:
Match - Host: 13.115.51.219
Replace - Host: www.example.com
However, the issue with POST http://13.115.51.219/account/login/ HTTP/1.1 remains, which can be resolved by removing http://13.115.51.219/ from the endpoint as follows:
Match - POST http://13.115.51.219/
Replace - POST /
The VHOST Match and Replace is justified as it is indeed necessary to be set by the user. But why SQLMAP adds http://13.115.51.219/ in the endpoint doesn't make sense to me. I assume this is a bug that should be fixed. Of course, you know this tool better, and if it's intended behavior, I am still okay; I can use Match and Replace in these cases.
The other consideration is what if someone does not want to use BurpSuite? Well, in that case, one can scan the VHOST target / Target using Origin IP with SQLMAP using the -H flag like this:
python3 sqlmap.py -u "http://13.115.51.219/endpoint?test=sqlmap" -H "Host: www.example.com" --timeout 50 --threads 10 --level 3 --risk 1
And it should work.
But as I mentioned, my target can't be accessed due to geo-restrictions, so I have to use a residential proxy, making my command look like this:
python3 sqlmap.py -u "http://13.115.51.219/endpoint?test=sqlmap" -H "Host: www.example.com" --timeout 50 --threads 10 --level 3 --risk 1 --proxy "http://username:[email protected]:8082"
To see the request, let's change the proxy to BurpSuite:
python3 sqlmap.py -u "http://13.115.51.219/endpoint?test=sqlmap" -H "Host: www.example.com" --timeout 50 --threads 10 --level 3 --risk 1 --proxy "http://127.0.0.1:8080"
And we can see the request made was:
GET http://13.115.51.219/endpoint?test=sqlmap HTTP/1.1
Host: www.example.com
User-Agent: sqlmap/1.8.5.4#dev (https://sqlmap.org)
Referer: http://13.115.51.219/endpoint
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
It's adding http://13.115.51.219/ as path/endpoint which will not work.
@Nishantbhagat57 Did you find any solution ??
I have already provided the solution i.e using BurpSuite "Match and Replace":
To solve the VHOST issue, I can use this Match and Replace rule:
Match - Host: 13.115.51.219
Replace - Host: www.example.com
However, the issue with POST http://13.115.51.219/account/login/ HTTP/1.1 remains, which can be resolved by removing http://13.115.51.219/ from the endpoint as follows:
Match - POST http://13.115.51.219/
Replace - POST /
@Nishantbhagat57 I am unable to reproduce. used exactly the same line you've mentioned here:
p.s. also tried different variations of other lines you've mentioned. not able to reproduce