For our last foray into sqlmap,
we'll work on getting that initial foothold into the server.
Once we've identified a SQL injection,
we can try and have sqlmap upload a web‑based backdoor.
This will provide us the ability to run commands on the remote server.
We can instruct sqlmap to do this by using the os‑shell option.
Before sqlmap can generate the shell,
it needs to know what language we want to use.
Our application is PHP‑based, so we can go ahead and go with the default here.
Now we'll let sqlmap try and provoke full path
disclosure just in case it's able to do so.
We'll go ahead and follow the redirect,
and we see that sqlmap was unable to automatically
retrieve the web server document root.
In order to upload a backdoor, we need a place to upload it to.
This location has to be writeable by the application.
Sqlmap is unable to determine the document root,
so it's asking us how we want to proceed.
We're going to go ahead and go with a list of common locations.
Now if you see this cookie header warning from sqlmap from time to time,
what this means is that the application is sending a new set
cookie header and sqlmap wants to know if we want to merge them
together with the ones that we have set.
We're going to say no and just stick with the ones that we set earlier.
Now sqlmap is attempting to upload the backdoor and
is trying different locations.
This is a two‑part process involving a file stager and the actual backdoor.
Once this succeeds, sqlmap will create a request to call the os‑shell.
The prompt then changes to what you see here.
We can now enter system commands and sqlmap will handle
executing them via the web backdoor.
We can run any command that the operating system on the server supports.
Let's see what user we're running as with the id command.
Each time we run a command, sqlmap will ask us if we want to retrieve the
standard output from the command. We can enter yes here,
or A for always.
Let's go with always.
Sqlmap was able to successfully retrieve the output of the command,
and it looks like we're running as the www‑data user,
which isn't unusual.
Let's take a look at the file listing to see if there's anything interesting.
Configuration directories are usually pretty interesting,
so let's take a look at the config directory.
Let's get the contents of the config.inc.php file,
and up here at the top of the file we can see database configuration,
and we see the database user and the password.
As a final example, let's retrieve the contents of etc/password file.
While this method of access isn't fool proof,
it may be all that we're able to get.
From here,
we can transition to other tools, and I encourage you to experiment with
this and take this initial foothold to the next step.