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.
We want to be absolutely clear on the importance of adhering to applicable laws regarding web application vulnerability scanning and exploitation. Before conducting any form of ethical hacking or penetration testing on a system, ensure that you have obtained explicit permission from the system or network owner.
Unauthorized hacking or scanning may seem trivial, but it can carry severe legal consequences, including fines or imprisonment, depending on your jurisdiction. Do not do it. Some of the laws that govern this activity include:
- The Computer Fraud and Abuse Act (United States)
- Sections 184, 342.1, 380, and 430 of the Criminal Code of Canada (Canada)
- Computer Misuse Act 1990 (England)
- Sec. 202a and 202b of the German Criminal Code (Germany)
- Information Technology Act Sec. 43 and 66 (India)
- The Act on the Prohibition of Unauthorized Computer Access (Japan)
If you doubt whether you’re acting in the clear, consult the agreement or scope of your authorized activities with a specific entity or review the code of conduct or disclosure guidelines with any of the bug bounty programs mentioned at the end of this article.
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.
To start the DVWA application:
- Open the terminal and type the command:
- If you’re not in the root account, you will be prompted to allow.
- The browser should automatically open to DVWA.
- (Alternatively) If it doesn’t open, go to the browser and enter:
http://127.0.0.1:42001in the address bar.
- To stop the DVWA server, go back to the terminal and type the command:
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.
It’s recommended that you only run DVWA or other intentionally vulnerable applications in a virtual environment. In How to Install Kali Linux on VirtualBox & Start Hacking Now you can learn how.
If you need a more in-depth, step-by-step guide check out How to Create a Virtual Hacking Lab: The Ultimate Hacker Setup.
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.
As a note, the exact query structure or commands may vary depending on the DB used. Demonstrated is MySQL.
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.
NOTE: When testing within a form field, you need to place a
# at the end of your query to comment out any text the program might add afterward.
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.
In a regular SQL injection attack, this true condition could return additional information from a table, but that’s not the case in a blind attack. Again, you’re looking for changes in the response.
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.
There are many powerful ways to use SQLMap, and we’ll only cover a few here. You can reference Sqlmap Cheat Sheet: Commands, Options, and Advanced Features for more great commands.
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
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
--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
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
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
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 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.
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:
i like your articles