Blind SQL Injection: An Expert’s Guide to Detect and Exploit

Blind SQL injection, a stealthy and cunning form of SQL injection attack, poses a unique challenge for security professionals due to its elusive nature and difficulty in detection and exploitation. In this comprehensive article, we'll delve into the world of blind SQL injection, uncovering the subtle nuances that set it apart from other SQL injection attacks.

Throughout the article, we'll discuss various tools and methods, focusing on Kali Linux as our preferred platform, although you could use the tools mentioned in most OS. As we wrap up, we'll provide you with a set of tried-and-tested best practices for defending your web applications against these elusive and potentially damaging attacks. By the end of this article, you'll be well-versed in understanding, exploiting, and defending against blind SQL injection vulnerabilities.

Now, let's dive into this detailed guide and get you set up with the essential knowledge and techniques to effectively tackle the challenges posed by this type of vulnerability.

What Is Blind SQL Injection?

SQL injection is a prevalent web application vulnerability that occurs when an attacker manages to execute unauthorized SQL code on a web application's database. Attackers do this by inserting malicious SQL statements into user input fields, such as search boxes or login forms. When successful, an attacker can obtain sensitive information from the database, modify or delete data, and even execute administrative commands.

Blind SQL injection, a more concealed variant, happens when the attacker can't directly see the output of their injected queries. In this case, they need to deduce the results indirectly by using content-based or time-based techniques. This type of attack is used when the application does not visibly display the results of an injected SQL query, making it difficult for the attacker to confirm the success of their actions.

The benefit of using blind SQL injection over a standard SQL injection attack lies in its subtlety. Since the attacker doesn't directly view the output, it can be more challenging for security systems or administrators to detect the attack. The attacker often uses conditional responses (boolean-based) or delays in the application's response time (timing-based) to infer whether their injected SQL code has had the desired effect. 

By slowly and methodically gathering information about the database structure and content, an attacker can still exploit a blind SQL injection vulnerability to access sensitive data and manipulate the system without raising immediate suspicion.

Discovering and Exploiting Blind SQLi

Now that you have a solid understanding of blind SQL injection and how it differs from regular SQL injection, let's dive into the process of discovering and exploiting these vulnerabilities. 

First, we'll guide you through setting up your lab environment, then go through testing for blind SQL injection manually, and finally use tools like SQLMap and Burp Suite to streamline the exploitation process.

Setting Up Your Lab

To start off, you’ll need to set up your lab to discover and exploit blind SQL injection vulnerabilities. There are several tools you can use, and we'll be using the following tools and resources:

Damn Vulnerable Web Application (DVWA): DVWA is an intentionally vulnerable web application that provides a safe environment for practicing various techniques. It comes pre-installed on Kali Linux or you can download it with sudo apt install dvwa. Once installed, set the difficulty level to “low” or "medium," and navigate to the "SQL Injection (Blind)" challenge. We'll use this to simulate a real-world scenario and demonstrate testing methods.

SQLMap: This powerful open-source tool automates detecting and exploiting SQL injection vulnerabilities. It comes pre-installed in Kali Linux, so if that’s the OS you’re using, you don't need to download it separately. We'll use SQLMap to automate the exploitation of the discovered blind SQL injection vulnerability in DVWA.

Burp Suite: Burp Suite is a widely-used web application security testing toolkit. For this article, we'll use the Community Edition, which comes pre-installed on Kali Linux. This will be used to intercept requests made to the DVWA. We'll demonstrate an alternative method of testing with SQLMap by capturing a request with Burp, saving it as a text file, and then running it through SQLMap.

Testing for Blind SQL Injection

Detecting blind SQL injection involves sending queries that produce conditional responses or delay the server's response time. We’ll guide you through each process step so you can thoroughly test for blind SQL injection and understand the reasoning or behavior behind each action.

Step 1: Normal response

Start by submitting a normal response, such as entering '2', to see how the application behaves under regular circumstances. This helps establish a baseline for the expected behavior without injected SQL code.

Step 2: Simple test

Perform a simple test by entering a single quote (2‘#) after the '2' to check if this might indicate a potential vulnerability in the web application. If an error occurs or the behavior changes, it could suggest that the application is improperly handling user input and may be susceptible to SQL injection. This (‘) isn’t required in all cases and may vary by the DB you’re testing on.

Step 3: True/False test

Conduct the true/false tests by injecting "2’ AND 1=1#" (always true) and "2’ AND 1=0#" (always false) conditions, and observe the application's responses to both queries. If the application's behavior changes based on the truthfulness of the injected condition, it indicates that the SQL code is being executed, confirming the presence of a vulnerability. 

Step 4: Timing-based test

Test the timing-based method by introducing "2’ AND SLEEP(5)#" to the query. Compare the response time with and without the sleep command. A noticeable delay indicates a potential vulnerability, as it demonstrates that the application is executing the injected SQL command and waiting for the specified time before returning a response.

Step 5: Determine columns

Determine the number of columns in the database using the "2’ ORDER BY X#" condition, where X is the number of columns we’re testing for. Increment the number until the application's behavior changes, signifying you've found the correct length. This step is essential for understanding the database structure, which can be useful when exploiting the vulnerability.

In our case, the web application threw an error when we tested for a column length of 3. This change in behavior let’s us know that we’ve identified the correct number of columns is 2, since that was the last successful test before the change. This is learned by watching for the change in response. 

Step 6: Determine the length of DB

Next, we’ll demonstrate the "2’ AND LENGTH(DATABASE())=X#" condition, where X is the number of characters being tested. This can be used to determine the length of the database name. We’ll use the same approach as we just did to determine the number of columns, except this time, we’re trying to elicit the number of characters in the DB name. To do this, we’ll test by character length in an iterative manner.

This can also be performed with a sleep command in cases where a visual indicator isn't available. For example, use "2’ AND LENGTH(DATABASE())=X AND SLEEP(5)#" where X is the suspected length of the database. If the application's response is delayed by the sleep command, it confirms the correct length of the database.

Step 7: Determine the database name

Finally, we can start enumerating the actual name of the database. We already know that it’s four characters long, but we can do more by determining what those characters are. To do this we’ll be going through testing different ASCII characters by using 2’ AND ASCII(SUBSTR(DATABASE(),X,X))>YY#. In this case X is the character position we’re testing for, and YY is the ASCII character decimal.

With this method you’re asking the database if the first character is greater than a set letter. If it’s not, it will respond with a negative. We’ll start somewhere near the middle of the lowercase alphabet with “l” (which is ASCII decimal 108). So the query looks like: 2’ AND ASCII(SUBSTR(DATABASE(),1,1))>108#.

Based on the response, know that the first character is not greater than “l” so we have to change the operation to ask if it’s less than “l”. We do this be changing the query to 2’ AND ASCII(SUBSTR(DATABASE(),1,1))<108#.

Based on this response, we now know that the first letter is somewhere between lowercase “l” and all preceding ASCII characters. Technically, this does include all uppercase, numbers, and special characters. Knowing this we can begin to test incrementally until we see a change in the response. In our case, we see a changed response once we enter 100.

This is now telling us that the character is not less than a lowercase “d”. We can confirm that this is the correct letter by reversing the query.

We have successfully confirmed the first character. Now, we can use this same method by changing the query to the second character placement and repeating this all over again. We’ll be sure to change the placement by entering 2’ AND ASCII(SUBSTR(DATABASE(),2,2))<108#.

By now, you should understand the rationale behind each step. By observing the application's behavior in response to various injected SQL commands, you can effectively identify and comprehend blind SQL injection vulnerabilities.

In the next section, we'll demonstrate how to exploit these vulnerabilities with the help of SQLMap. Keep practicing these techniques in a controlled environment to sharpen your skills and become an expert in detecting and exploiting blind SQL injection attacks.

Example 1: Exploiting Blind SQL Injection

Now that we’ve confirmed the vulnerability, we’ll go through the steps to exploit it using SQLMap. Pay attention to the screen captures at each step for better understanding. Even better, follow along to really cement the process and learning in your mind and grow this skill.

Step 1: Familiarize with SQLMap

Open the SQLMap help page to familiarize yourself with the type of information required for an attack and the command structure of the tool. Specifically, we will see that we can use a URL with the -u flag and the cookie information with the --cookie= flag.

sqlmap -h

Step 2: Retrieve session information

Gather the required cookie and security level from the browser's Developer Panel out of the Storage tab.

Step 3: SQLMap URL command

Execute SQLMap with the -u and --cookie= information. Review the resulting information, which includes the parameters, payload, and location of the output files.

Step 4: Open session file

Now we’ll go to the terminal and navigate to the output file location. First, we’ll use it to see what files we have to work with. Use sqlitebrowser to open the session.sqlite file.

Step 5: DB Browser

In the sqlitebrowser, examine the database structure and browse the data tabs.

Step 6: View target file

Go back to the terminal and use cat target.txt to view the file, which contains the command you used.

Step 7: View log

Use cat log to view the contents of the log. This includes the same parameter and payload information we saw earlier, as well as details about the database and web application technology. All of this information could be useful in any follow on penetration testing we might conduct in later stages.

Step 8: SQLMap URL with database name flag

Now we’ll go back to the terminal and execute the same command in SQLMap, but this time append '--dbs' to discover the database name. We know it’s four characters long from our earlier manual testing, but we want to know more about this database.

Step 9: SQLMap URL with column flag

Next, we want to elicit the user columns with the flags -D dvwa -T users --columns. This will provide you with a lot more information about what’s actually inside the database.

Step 10: SQLMap URL with user dump flag

Now we get to the good part, use -T users --dump to extract data from the user's table. Review the response and note how SQLMap prompts you to crack the hash of the passwords it discovers and then presents the results in a neat, orderly table for you.

Note the neat arrangement of the information in the picture above. In addition to just cracking the passwords and placing them in a tidy table, SQLMap also automatically outputs that information to a .csv file. This can then be fed into other tools for further exploits during a penetration testing case.

Example 2: Exploiting Blind SQL Injection With HTTP Data

Now we'll demonstrate an alternative method of exploiting blind SQL injection using SQLMap and HTTP data gathering from Burp Suite.

Step 1: Intercept traffic with Burp Suite

Open Burp Suite, which you've configured to capture HTTP traffic. Then navigate to the Proxy tab, and locate the query submission in the HTTP history.

Step 2: Send request to repeater

In the Request panel, right-click on the query submission and select 'Send to Repeater'.

Step 3: Copy raw data from Burp Suite

Switch to the Repeater tab, and copy the raw request data from the panel.

Step 4: Create request file

Paste the raw request data into a new file that you'll use with SQLMap. In our example, we named this file request.

Step 5: SQLMap load HTTP request file

Return to the terminal and run the command sqlmap -r request. The -r flag tells SQLMap to parse and use the raw HTTP request from the specified file.

As in the previous method, SQLMap will offer to crack the discovered user password hashes once it has extracted the data.

This method provides an alternative to manually inputting cookie and URL information in the command line, streamlining the process using captured HTTP traffic. As in the previous methods, this information is output to your directory and can be studied or used for future efforts.

Defending Against Blind SQL Injection

By following best practices and guidelines recommended by reputable organizations like OWASP, NIST, W3, and Amazon AWS, you can significantly strengthen your application's defenses against these attacks. StationX also provides valuable information regarding the potential vulnerabilities and corresponding remediations for web applications and other connected systems. 

These organizations provide valuable resources and information that cover a wide range of topics, including secure coding practices, database security, web application defenses, and monitoring and incident response. In this section, we'll explore these best practices in detail, providing you with actionable steps to help safeguard your web application from blind SQL injection vulnerabilities.

Secure coding practices

Implementing secure coding practices is crucial to defending against blind SQL injection attacks. OWASP recommends using prepared statements or parameterized queries to separate user input from SQL code, reducing the risk of injection. Additionally, incorporating input validation techniques, such as whitelisting, helps restrict the types of data that can be entered by users, further enhancing security.

Database security

Database security measures are essential in minimizing the potential impact of an attack. Limiting database user privileges ensures that attackers cannot gain access to sensitive information or perform unauthorized actions. Regularly updating and patching your database management system helps address known vulnerabilities, making it more difficult for attackers to exploit them. You can read more about this in NIST SP 800-44 version 2 (Section 6.4.2 specifically discusses this).

Web application defenses

Implementing web application defenses, such as a web application firewall (WAF), can help detect and block SQL injection attempts. Amazon AWS discusses how a WAF analyzes incoming traffic and filters out malicious requests through database managed rule groups, reducing the likelihood of a successful attack.

Monitoring and incident response

Monitoring and logging application activity is vital for identifying suspicious activity and detecting potential attacks early on. NIST recommends establishing a robust logging and monitoring system, along with a well-defined incident response plan, ensuring quick and effective responses to security incidents.

Conclusion

Throughout this article, we've dug deep into blind SQL injection, exploring its unique characteristics and the techniques used to discover and exploit these vulnerabilities. From setting up a testing environment with DVWA and Kali Linux to conducting manual tests and utilizing tools like SQLMap and Burp Suite, we've armed you with practical guidance and actionable advice to skill up on this complex subject. 

Moreover, we've emphasized the importance of implementing robust security measures such as secure coding practices, database security, web application defenses, and monitoring and incident response to safeguard against blind SQL injection attacks.

As we've demonstrated, blind SQL injection is a formidable challenge in cyber security for web applications, but with the right knowledge and skill set, you can effectively defend against these threats. Continue your learning by taking these courses to bolster your aptitude in web application ethical hacking and defense:

Learn Website Hacking / Penetration Testing From Scratch

4.8

★★★★★

Learn Burp Suite, the Nr. 1 Web Hacking Tool

4.9

★★★★★

Web Hacking: Become a Web Pentester

4.8

★★★★★

Frequently Asked Questions