Now that we have a valid SQL injection, what's our next step?
Well,
we can check to see what the name of the database is
that the application is using.
We can also find out what user the application is connecting as.
We can do this with the current‑db and current‑user command line arguments.
Going back to our previous command,
we'll add the current‑db parameter and we'll add the current‑user parameter.
Now you see that the current user is dvwa@localhost
and the current database is dvwa.
Being able to retrieve the current database is great.
Now that we know what it is, let's see what tables it contains.
Let's go back to our previous command, let's remove these two parameters.
We'll use ‑D to specify the database,
and then we'll use the tables parameter so that sqlmap will
enumerate the tables in that specific database.
Sqlmap has identified two tables in the dvwa database, guestbook and users.
I don't think I'll have to tell you which one we're going to take a look at.
Now to dump the contents of the users table, we can use the dump argument.
So we'll remove our tables argument,
we'll specify the table using ‑T, and now we'll tell sqlmap that
we want to dump the contents of the table.
Now, here's an interesting feature. Sqlmap detected that one of the
columns retrieved contains potential password hashes.
It's now giving us the option to send the hashes to a file so we
can pass it right into a password cracking tool.
If we say no here,
sqlmap gives us the option to perform a dictionary attack on the hashes.
This happens offline, so there's no harm in giving it a shot.
Let's go ahead and let it run the built‑in sqlmap word list.
For the sake of brevity in the example, we'll skip the
usage of common password suffixes.
And just like that, we have passwords.
While it's unlikely that you'll find that this works in the wild,
the capability is there and you never know when you might need it.
I've seen applications doing all kinds of unusual things,
including storing passwords using very unsafe methods.