The SQLMap tool can be found in every penetration tester’s toolbox. It is one of the most popular and powerful tools when it comes to exploiting SQL injection vulnerability, which itself tops the OWASP list of Top 10 Vulnerabilities. From confirming the SQL injection vulnerability to extracting the database name, tables, columns and gaining access to a full system, it can be used for multiple purposes.
In this article, we will see different type of SQLMap commands which may come handy while exploiting different scenarios of SQL injection.
SQLMap can be downloaded from the following links:
Linux: git clone –depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
For demo purposes, I am using this machine from Vulnhub.
Let’s look at the basic usage of SQLMap tool on GET and POST requests.
- sqlmap -u http://site-to-test.com/test.php?id=1 -p id
- sqlmap -u http://site-to-test.com/test.php?id=1*
- -u: URL to scan
- -p: parameter to scan
- *: Parameter to scan (if -p switch is not provided)
We can provide the data being passed in the POST request body to scan by the SQLMap tool.
- sqlmap -u http://site-to-test.com/admin/index.php –data=”user=admin&password=admin” -p user
- –data = POST data
Another way is to copy the Burp request into a file and pass the same to SQLMap.
- sqlmap –r <path to the request file>
Let’s go a little bit further to understand other options provided by the SQLMap tool.
Scanning POST login pages
POST login pages are authorized by the cookie header, which is passed in the HTTP header of a GET/POST request. To scan the post login page(s), we have to provide the valid cookie to SQLMap.
- sqlmap -u http://192.168.202.163/admin/index.php?id=1 –cookie=”cookie value”
/admin/index.php?id=1 is a POST login page.
- sqlmap -u http://192.168.202.163/admin/index.php?id=1 –user-agent=infosec
- sqlmap -u http://192.168.202.163/admin/index.php?id=1 –referer= http://192.168.202.163/admin/index.php
Additionally, we can randomize the user-agent header by using the –random-agent option.
Crawl is an important option which allows the SQLMap tool to crawl the website, starting from the root location. The depth to crawl can be defined in the command.
sqlmap -u http://192.168.202.160/ –crawl=1
–crawl: Define a depth to crawl. (Example: Defining 2 will allow the tool to crawl up to two directories)
If we want to exclude any page from the crawler’s scope we can define by –crawl-exclude. This is a useful option when we are crawling a POST login page.
- sqlmap -u http://192.168.202.163/ –crawl=3 –cookie=”cookie value” –crawl-exclude=”logout”
This command will crawl the website up to three directories and exclude any URL where the “logout” keyword is present.
As you can see below, SQLMap has crawled the website but excluded the logout URL.
Let’s run the same command without the –crawl-exclude option:
As seen below when –crawl-exclude is not defined, SQLMap has crawled the logout URL. This would allow the existing session to be invalidated (due to logout) and not complete the scan.
SQLMap through proxy
We can define a proxy’s details from where we allow the request to pass. If we want to pass the request through a proxy tool like Burp, start Burp Suite and configure it to run on localhost on port 8080. Now use the following SQLMap command:
- sqlmap -u http://192.168.202.162/cat.php?id=1 -p id –proxy=”http://localhost:8080″
Now, think about a scenario where the SQLinjection keywords like OrderBy and Union are blacklisted on the server. We can bypass these types of implementations by using the camel casing technique. We will use SQLMap to send the traffic to Burp and use the “match and replace” feature of Burp to bypass the above restriction.
The Match and Replace feature can be found under the “Options” tab, under the “Proxy” tab of Burp.
This will check if the request has a keyword like “union.” If yes, then replace it with “UnIoN.”
In a scenario where the application is accessible only through proxy server, the same can be defined using the following command:
- sqlmap -u http://192.168.202.162/cat.php?id=1 -p id –proxy=”http://localhost:8080″ –proxy-cred=username:password
The batch command is used for non-interactive sessions. When we are trying to scan something, SQLMap may ask us to provide input during the scan: for example, while using the crawl feature, the tool asks the user if the user want to scan the identified URL. When –batch is defined in the command, the tool uses a default value to proceed without asking the user.
A page URL with a form field (say login page) can be provided along with the –form option to parse the page and guide the user to test the identified fields.
Now pages with a large number of form fields can be tested effectively, using the –form and –batch option together. This will parse the page and check for form fields and automatically provide the input on behalf of the user.
If the entire application has to be scanned, the crawl option along with form and switch can be used.
The threads option allows the user to define the number of concurrent requests to be sent by the SQLMap tool. This would reduce the overall testing time. This should not be kept to a higher value, as it may impact the accuracy of the result.
Risk and level
Risk allows the type of payloads used by the tool. By default, it uses value 1 and can be configured up to level 3. Level 3, being the maximum, includes some heavy SQL queries.
The level defines the number of checks/payload to be performed. The value ranges from 1 to 5. 5, being the maximum, includes a large number of payloads in the scan.
The risk and level are recommended to be increased if SQLMap is not able to detect the injection in default settings.
In case we want to see the payload being sent by the tool, we can use the verbose option. The values range from 1 to 6.
Mobile Device Penetration Testing
As we know SQLMap is majorly used for SQL injection exploitation, let’s see some of the commands to enumerate the database through an application vulnerable to SQL injection.
1. –dbs: This option is used to enumerate the database.
2. Now we have the database name. To extract the table for database “photoblog,” run the following command:
3. To extract the column details from the table “users,” run the following command:
4. To dump the data for table “users,” use the –dump command:
5. To identify the current database user:
6. To identify the current database name:
7. To identify the privileges, roles, and if the current DB user is the DB admin:
Bypassing WAF using tamper script
Many times, we come across a scenario where the application is kept behind the web application firewall (WAF). To check if the site is protected by WAF, we can use the following options:
Once the WAF is identified, we can use the tamper script to attack the WAF-protected applications. The tamper script can modify the request to escape WAF detection. The scripts can be found under /usr/share/sqlmap/tamper/ directory.
Running system commands
We can run the OS/system-level commands if the current database user has DBA rights. We can use the following options:
- For a Linux server:
- sqlmap -u http://192.168.202.162/cat.php?id=1 –os-shell
- For a Windows server:
- sqlmap -u http://192.168.202.162/cat.php?id=1 –os-cmd <cmd>
Running SQL queries
We can run the SQL statement on the database by running the following commands:
- sqlmap -u 192.168.202.164/cat.php?id=2 –sql-shell
Some other options include:
1. Scanning a page protected by HTTP authentication like Basic, NTLM and Digest:
- sqlmap -u http://example.com/admin.aspx –auth-type Basic –auth-cred “admin:admin”
2. Scanning a page protected by a key-based authentication:
- sqlmap -u http://example.com/admin.aspx —auth-file=<path to PEM certificate or private key file>
3. To randomize attacking IPs (this can help in cases like WAF detection, or when hiding the attacking source would increase the difficulty of tracing the IP).
To use the default Tor anonymity network:
- sqlmap -u http://example.com/admin.aspx –tor
To define a Tor port:
- sqlmap -u http://example.com/admin.aspx –tor-port=<tor proxy port>
4. If delay is required between each HTTP request:
- sqlmap -u http://example.com/admin.aspx –delay=1 #1 second delay
5. If a page is protected by a CSRF token, we can include the same in the command:
- sqlmap -u http://example.com/admin.aspx –csrf-token=<csrf token>
6. In second-order SQL injection, the SQL payload is stored in the database and retrieved later when accessing a different page. We provide a URL, which will be requested by SQLMap tool after every injection. We can instruct the SQLMap tool to test this injection by using the following commands:
- sqlmap -r /root/Desktop/Burp.txt –second-order “http://target/vulnerbalepage.php”
The Burp.txt file contains the request on which injection is to be performed.
- –second-order “URL” contains the URL which will be accessed by SQLMap after every injection.
SQLMap is a good tool when it comes to detecting and exploiting SQL injection vulnerabilities. With so many supported options, switches and ability to create and use the customize script, it stands out from the many open-source tools for testing SQL injection vulnerability.