DVWA – SQL Injection – Blind (Low/Med/High)

In this walk through, we will be going through the SQL Injection – Blind vulnerability section from DVWA Labs. We will be exploring and learn about Blind SQL Injection attacks and what makes an application vulnerable to it. We will start with the security level as Low and will gradually increase the difficulty as we progress further. So, let’s get started with the Hacking without any delay.

SQL Injection – Blind Attacks

Bind SQL Injection Attack is an attack where attacker asks TRUE or FALSE questions from the database and retrieves answers on their behalf. This is also exploited using Time based techniques where for any TRUE statement, a time delay is used to determine the responses. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions.

Security: Low (SQL Injection – Blind)

• Setting the security to low and PHPIDS as disabled.

• As this is a blind SQLi challenge, the application is only returning a True/False type output for our entered user ID.

• I used the payload we used in the previous SQL injection and see it works

1' OR 1='1 --

• It does work as we get a “True” Response however we didn’t get any output. To test the execution in Blind SQL Injection, we can use a time delay. The application will hang for 5 seconds as per our input.

1' AND sleep(5)#

• Let’s enumerate the number of columns we have as this is a blind Injection, we will not get the whole lot of output. We will use the ORDER BY clause and see the result as this will not trigger any error like the last time. We can get a response in False for a user ID and treat that as an error.

1' ORDER BY 1#

• I got a hit of result as “False” for column 3 that means we only have two columns to work with.

1' ORDER BY 3#

• Next let’s enumerate the DB version which is the objective for this task. I used the below payload to check the database length

1' AND LENGTH(database())=1#

• I incremented the number sequentially and and got a “True” response on number 4.

1' AND LENGTH(database())=4#

• It would be very daunting for us to exploit it manually. So, we will use SQLmap to automate the exploitation.

sqlmap -u 'http://localhost/vulnerabilities/sqli_blind/?id=1&Submit=Submit' -p id --cookie 'security=low; PHPSESSID=1ko1sc4hv1rvu0bbooidl1mv24' --dbs

Security: Medium (SQL Injection – Blind)

• Setting the security to Medium and PHPIDS as disabled.

• This challenge uses a drop down version to select the user ID instead of a search box.

• As per the source code, the application is using POST method for the request along with mysqli_real_escape_string function which we have bypassed already in the last SQL injection challenge.

• I intercepted a POST request and changed the input to my payload and it worked.

1 OR 1=1
1 AND sleep(5)#

• Next, let’s see what is the length of the databse here. We got the success at 4 last time. So tried that only and got a “True” response.

1 AND LENGTH(database())=4#

• Now, let’s exploit it using SQLmap to get the Database version. For that, we have to certain changes in the Sqlmap command such as “data” parameter as it takes a POST input. and the security level to medium in cookie value. We got our required information in the results.

sqlmap -u 'http://localhost/vulnerabilities/sqli_blind/' --data='id=1&Submit=Submit' -p id --cookie 'security=medium; PHPSESSID=1ko1sc4hv1rvu0bbooidl1mv24' --dbs

Security: High (SQL Injection – Blind)

• Setting the security to High and PHPIDS as disabled.

• This time application has a link to another page to set or change the user ID. Upon Clicking on the link, a pop window opened and ask for our user ID. After submitting, we can see the result on the main page like before.

• I intercepted the initial request via Burpusite and it was simple GET request for the another page.

• The another page was using POST request with our parameters to submit the request.

• After analyzing the source code, found out that there are no restrictions or filtering is being done like in the medium security rather it just have a LIMIT clause set which we can easily bypass with the comment symbol.

• I used the below payload in my Burpsuite repeater tab and send the request.

1' OR 1=1#
1' AND sleep(5)#

• Let’s find out the length of the database using the below payload. Send the request via Repeater and then refresh the page.

1' AND LENGTH(database())=1#

• Let’s exploit this with sqlmap and dump the DB Version.

sqlmap -u 'localhost/vulnerabilities/sqli_blind/' --data='id=1&Submit=Submit'-p id --cookie 'security=high; PHPSESSID=1ko1sc4hv1rvu0bbooidl1mv24' --dbs

Also Read: DVWA – Reflected Cross Site Scripting (Low/Med/High)

Conclusion:

So, we finally completed all the security levels for the DVWA SQL Injection – Blind Vulnerability. We looked into the various ways how application has been set up in various levels and how we can bypass the security controls implemented. Next, we can mitigate the potential Blind SQL Injection attacks by performing input sanitization and using prepared statements or parametrized queries for every SQL query made by the application to the database. On that note, i will take your leave and will meet you in next one with another DVWA vulnerability writeup, till then “Keep Hacking”.