Blind SQL Injections with SQLMap against the DVWA
As part of our Injection Attacks: The Free 2020 Guide course, we reviewed concepts of SQL injections, including what blind injections are. Then, we practiced various techniques against the OWASP Juice Shop and the Damn Vulnerable Web Application (DVWA) to demonstrate the dangers of such attacks, and also to learn how to defend our own applications. In this post, we perform one of the attacks demonstrated in the course: blind SQL injections with SQLMap against the DVWA.
Start the DVWA container environment
If you’re reading this article, chances are that you’ve already got the Damn Vulnerable Web Application (DVWA) running, but in case you don’t, I recommend using a Docker container to quickly spin it up and later tear it down without having to uninstall anything or dirty up our system.
If you don’t have Docker installed, or if you’re not sure how to go about it, check out our post called How to set up the DVWA on Kali with Docker.
If you do already have that environment up and running, you can use this Docker command to spin up the container:
docker run --rm -it -p 80:80 vulnerables/web-dvwaAfter just a few seconds, the environment will be up and running. Let’s use ZAP to explore the application, and to act as a proxy which will later be useful in carrying out our attacks.
Launch OWASP ZAP
If you’re running Kali Linux, OWASP ZAP should already be included. Otherwise, go ahead and install it depending on the operating system you are running.
Once you’ve got it open, let’s start a new ZAP Session so that we have a clean workspace.
We will want to manually explore http://localhost/ and I’ll go ahead and disable the HUD since we won’t be needing it. (It’s a checkbox below the URL to explore and above Launch Browser)
Once the browser has loaded, you will login with these initial credentials:
Login: Admin/admin
Scroll to the bottom of the page and click on: Create/Reset Database
Click on “Login” at the bottom of the page and log in with admin/password now.
Let’s go change the security level of the application to MEDIUM for now by going to the DVWA Security tab on the left.
Then, go to the Blind SQL Injection tab.
Switch to the History tab in ZAP so we can see requests going through.
Submit an ID change request in the DVWA, and you should see a response back letting us know that it went through.
Pull up the POST request in ZAP by double-clicking it in the History tab, and we should have information that helps us formulate our SQLMap attack, such as seeing what gets sent in the POST request:
id=10&Submit=Submit- The endpoint
- The request type of POST
- Cookies that include a PHPSESSID as well as a security=high value
This gives us the information we need to mount our attacks with SQLMap.
Getting started with SQLMap
Let’s pull up SQLMap now. Again, if you are on Kali Linux, it should be pre-installed. Otherwise, go ahead and install it on your respective operating system.
While I won’t go through each setting and option since they are fairly well documented, there are a few we will need to use.
We’ll need to submit a URL with -u URL or --url=URL.
We’ll need --data=DATA to input our data string to be sent through POST, such as an ID.
We’ll need --cookie=COOKIE to input COOKIE data that helps authenticate us with the PHPSESSID.
We can use -p TESTPARAMATER to specify which parameters to test for, to provide custom injection payloads, or optional tampering scripts.
There are a couple of Detection options we can modify if needed.
And then options that can be used to enumerate the back-end database system, structure, and data.
The first attack we will perform will use the --dbs option which enumerates the DBMS databases.
Executing our first blind SQL injection with SQLMap against the DVWA
So based on our prior POST request, here’s what we can try to formulate:
sqlmap -u "http://localhost/vulnerabilities/sqli_blind/" --cookie="id=10; PHPSESSID=39qedittgtbc7rfsm69gjvidl0; security=medium" --data="id=1&Submit=Submit" -p id --dbsCode language: JavaScript (javascript)Enter Y if it says: “it is recommended to perform only basic UNION tests if there is not at least one other(potential) technique found. Do you want to reduce the number of requests?[Y/n]”
We see a message saying that the POST paramater ID appears to be ‘AND boolean-based blind-WHERE or HAVING clause’ injectable, and that the heuristic test shows that the back-end DBMS could be MySQL.
It then asks you if you want to skip test payloads specific to other DBMSes. Let’s say yes to that since it will cut back on unnecessary tests.
For the next message, it’s up to you, I’ll say yes.
Looks like it found something interesting and it’s asking us if we want to try to find proper UNION column types with fuzzy test, let’s say YES.
It now tells us that it is not exploitable with NULL values, but it can try with random integer values. Let’s say yes.
It tells us that the target URL appears to be UNION injectable with 2 columns. Let’s say yes.
Now it tells us that the ID parameter is vulnerable, and asks if we want to continue testing the others (if any), so let’s say no to that.
We now have a confirmation that the DBMS is MySQL with version greater than or = to 5.0.12, and it found two databases:
DVWAinformation_schema→ which we are already familiar with!
OK, so we’ve found a vulnerable input and we’ve got two database names.
Now, let’s explore the DVWA database.
Exploring the DVWA database
We can replay the same command, but instead of running --dbs, we will extract table names with --tables, but since we really only care about the DVWA database, we can use -D dvwa to limit our results.
Instead of having to answer Y/N questions like we just did, we will also use an option --batch which instructs SQLMap to answer with default values.
I’ll also add one more option which is --threads 5 to speed things up a bit, since it increases the number of concurrent HTTP requests.
sqlmap -u "http://localhost/vulnerabilities/sqli_blind/" --cookie="id=10; PHPSESSID=39qedittgtbc7rfsm69gjvidl0; security=medium" --data="id=1&Submit=Submit" -p id -D dvwa --tables --batch --threads 5Code language: JavaScript (javascript)Extracting and cracking user passwords
After this runs, we now see a guestbook and users table in the DVWA database. Let’s extract information from the users table! We can do that by replacing the -D dvwa with -T users and we will use --dump to dump the table’s contents.
sqlmap -u "http://localhost/vulnerabilities/sqli_blind/" --cookie="id=10; PHPSESSID=39qedittgtbc7rfsm69gjvidl0; security=medium" --data="id=1&Submit=Submit" -p id -T users --batch --threads 5 --dumpCode language: JavaScript (javascript)At this point, not only did it extract all of the information from the users table, but the default options also attempted to crack the passwords, and since they were easy and md5 hash, it cracked them in very little time. So now, the output contains both the hash and the actual password in parentheses.
Already, you can start to see the amount of data we can extract in a very short amount of time using SQLMap.
How SQLMap works under the hood
SQLMap is able to automatically do all of the above because under the hood, SQLMap:
- Identifies vulnerable parameters
- Identifies which SQL injection techniques can be used to exploit the vulnerable parameters, by trying various techniques for different DBMS, unless it knows what DBMS is running already in which case it can drastically reduce the number of techniques to try
- Fingerprints the back-end DBMS to gather as much information as it can, again helping narrow down attacks
- and depending on how vulnerable the application is, and also what options you choose, SQLMap can automatically enumerate data or take over the database server as a whole
It does this by using the same techniques we learn in the Injection Attacks: The Complete 2020 Guide, but for a quick overview, check out SQLMap’s own documentation.
That concludes it for our attacks using SQLMap against the DVWA, thanks for reading!
Responses