OS Exploitation
SQLMap has the ability to utilize an SQL Injection to read and write files from the local system outside the DBMS. SQLMap can also attempt to give us direct command execution on the remote host if we had the proper privileges.
File Read/Write
The first part of OS Exploitation through an SQL Injection vulnerability is reading and writing data on the hosting server. Reading data is much more common than writing data, which is strictly privileged in modern DBMSes, as it can lead to system exploitation, as we will see. For example, in MySql, to read local files, the DB user must have the privilege to LOAD DATA and INSERT, to be able to load the content of a file to a table and then reading that table.
An example of such a command is:
LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE passwd;
While we do not necessarily need to have database administrator privileges (DBA) to read data, this is becoming more common in modern DBMSes. The same applies to other common databases. Still, if we do have DBA privileges, then it is much more probable that we have file-read privileges.
Checking for DBA Privileges
To check whether we have DBA privileges with SQLMap, we can use the --is-dba option:
0xH4shDumb@htb[/htb]$ sqlmap -u "http://www.example.com/case1.php?id=1" --is-dba
___
__H__
___ ___[)]_____ ___ ___ {1.4.11#stable}
|_ -| . [)] | .'| . |
|___|_ ["]_|_|_|__,| _|
|_|V... |_| http://sqlmap.org
[*] starting @ 17:31:55 /2020-11-19/
[17:31:55] [INFO] resuming back-end DBMS 'mysql'
[17:31:55] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
...SNIP...
current user is DBA: False
[*] ending @ 17:31:56 /2020-11-19As we can see, if we test that on one of the previous exercises, we get current user is DBA: False, meaning that we do not have DBA access. If we tried to read a file using SQLMap, we would get something like:
To test OS exploitation, let's try an exercise in which we do have DBA privileges, as seen in the questions at the end of this section:
We see that this time we get current user is DBA: True, meaning that we may have the privilege to read local files.
Reading Local Files
Instead of manually injecting the above line through SQLi, SQLMap makes it relatively easy to read local files with the --file-read option:
As we can see, SQLMap said files saved to a local file. We can cat the local file to see its content:
We have successfully retrieved the remote file.
Writing Local Files
When it comes to writing files to the hosting server, it becomes much more restricted in modern DMBSes, since we can utilize this to write a Web Shell on the remote server, and hence get code execution and take over the server.
This is why modern DBMSes disable file-write by default and need certain privileges for DBA's to be able to write files. For example, in MySql, the --secure-file-priv configuration must be manually disabled to allow writing data into local files using the INTO OUTFILE SQL query, in addition to any local access needed on the host server, like the privilege to write in the directory we need.
Still, many web applications require the ability for DBMSes to write data into files, so it is worth testing whether we can write files to the remote server. To do that with SQLMap, we can use the --file-write and --file-dest options. First, let's prepare a basic PHP web shell and write it into a shell.php file:
Now, let's attempt to write this file on the remote server, in the /var/www/html/ directory, the default server webroot for Apache. If we didn't know the server webroot, we will see how SQLMap can automatically find it.
We see that SQLMap confirmed that the file was indeed written:
Now, we can attempt to access the remote PHP shell, and execute a sample command:
We see that our PHP shell was indeed written on the remote server, and that we do have command execution over the host server.
OS Command Execution
Now that we confirmed that we could write a PHP shell to get command execution, we can test SQLMap's ability to give us an easy OS shell without manually writing a remote shell. SQLMap utilizes various techniques to get a remote shell through SQL injection vulnerabilities, like writing a remote shell, as we just did, writing SQL functions that execute commands and retrieve output or even using some SQL queries that directly execute OS command, like xp_cmdshell in Microsoft SQL Server. To get an OS shell with SQLMap, we can use the --os-shell option, as follows:
We see that SQLMap defaulted to UNION technique to get an OS shell, but eventually failed to give us any output No output. So, as we already know we have multiple types of SQL injection vulnerabilities, let's try to specify another technique that has a better chance of giving us direct output, like the Error-based SQL Injection, which we can specify with --technique=E:
As we can see, this time SQLMap successfully dropped us into an easy interactive remote shell, giving us easy remote code execution through this SQLi.
Note: SQLMap first asked us for the type of language used on this remote server, which we know is PHP. Then it asked us for the server web root directory, and we asked SQLMap to automatically find it using 'common location(s)'. Both of these options are the default options, and would have been automatically chosen if we added the '--batch' option to SQLMap.
With this, we have covered all of the main functionality of SQLMap.
Try to use SQLMap to read the file "/var/www/html/flag.txt".
We see that this time we get current user is DBA: True, meaning that we may have the privilege to read local files.
As we can see, SQLMap said files saved to a local file. We can cat the local file to see its content:
We have successfully retrieved the remote file.
Use SQLMap to get an interactive OS shell on the remote host and try to find another flag within the host.
Last updated