Web applications are becoming more and more popular, replacing traditional desktop programs at an accelerated rate. With all these new apps out on the web comes a variety of security implications associated with being connected to the internet where anyone can poke and prod at them. One of the simplest, yet most prevalent types of security flaws found in modern web apps is SQL injection.
A typical web app doesn't actually store any information in the app itself, but rather it communicates with a backend database where information is stored. These requests are handled by SQL queries in which the application passes a statement to the database, thus returning the requested data to the application.
SQL injection is a technique used to attack applications utilizing a database by sending malicious code with the intention of accessing or modifying restricted information in the database. There are many reasons why this vulnerability exists including improper input filtering and sanitation.
This type of attack allows one to retrieve sensitive information, modify existing data, or even destroy entire databases. The most common attack vector for SQL injection is through input fields — login forms, search forms, text boxes, and file upload functions are all excellent candidates for exploitation.
In this guide, our target will be Mutillidae, an intentionally vulnerable web app included as part of Metasploitable 2, an intentionally vulnerable Linux virtual machine (VM) designed for testing and practicing purposes. We will be connected to Metasploitable 2 on an isolated network with Kali as the attacking machine.
Burp Suite is a popular tool that can be used to automate testing web apps for vulnerabilities and is conveniently included with Kali. Before we get to that though, we need to set up our target machine.
I will be using Metasploitable 2 in this guide, which you can download from Rapid7's website, but any vulnerable VM will work. If you need help getting it installed, it's just like installing any other VM on your computer, and Null Byte has a few guides that could help you get your virtual lab set up.
One thing to be careful with when using an intentionally vulnerable machine is exposing it to hostile networks. This means that unless you are completely unplugged from the internet, you should be using network address translation (NAT) or host-only mode.
Once everything is set up, log into Metasploitable 2 — both the username and password should be msfadmin — and find its IP address using ifconfig. What you're looking on the eth0 is the "inet" address, which will be your IP address for testing purposes.
After finding Metasploitable 2's IP address, navigate to it in order to connect to the web server. I'm using Firefox in Kali to do this.
Click on "Mutillidae" to enter the web app, then navigate to "OWASP Top 10." Now, select "Injection (SQL)," followed by "Extract Data," then "User Info." You will be greeted with a login screen.
Next, we need to configure the browser to work with Burp Suite since it acts as a proxy to intercept and modify requests. I'm using Firefox here, but most browsers will be similar.
Open up the browser's "Preferences," click on "Advanced," then the "Network" tab. Select "Settings" next to the Connection spot, then make sure it's set to "Manual proxy configuration" and enter 127.0.0.1 as the HTTP Proxy and 8080 as the Port. Next, check "Use this proxy server for all protocols," make sure there is nothing listed under No Proxy for, then click "OK." We're now ready to fire up Burp Suite.
Open up the Burp Suite app in Kali, start a new project, then go to the "Proxy" tab and ensure that "Intercept is on" is pressed. This will allow us to modify the request from the webpage and insert different values to test for SQL injection. Back on the login page, I have entered an arbitrary username and attempted to log in. You can view the raw request as well as parameters, headers, and even hex information.
We're primarily interested in the username field since this is what we will modify to test for SQL injection flaws. Click on the "Action" button, then "Send to Intruder." Alternatively, right-click anywhere in the request area and do the same.
Next, go to the "Intruder" tab, and click on "Positions." Burp Suite automatically configures the positions where payloads are inserted when a request is sent to intruder, but since we are only interested in the username field, we can clear all positions by pressing "Clear" on the right. Highlight the value entered for username, and click the "Add" button. We will use the "Sniper" attack type which will run through a list of values in the payload and try them one at a time.
Now our position is set, and we're ready to configure the payload. SQL queries work by interacting with data in the database through the use of statements. The SELECT statement is used to retrieve data, so a login query would look like:
SELECT username, password FROM users WHERE username='myname' AND password='mypassword';
Let's look at the classic SQL injection command ' or 1=1--. Here is what the SQL statement looks like when entered into the login field:
SELECT username, password FROM users WHERE username='' or 1=1-- AND password='';
The single quote effectively turns the first part into a blank string, and 1=1 always evaluates to true, so the username query will now run as "blank" or "true." The double dashes comment out the rest of the query so the password field is ignored. Since "blank" or "true" is always true, and the password field is ignored, the database will return account data.
Click on the "Payloads" tab, and go to "Payload Options" — we can leave all the default settings for now. Here we can enter our payloads into a simple list by either adding them one by one or loading an existing list. Kali comes with a variety of wordlists including one specifically for testing SQL injection vulnerabilities. Hit "Load," and navigate to /usr/share/wordlists/wfuzz/injection/SQL.txt. Now, we are prepared to launch our attack.
Click the "Start attack" button, and a new window will pop up showing the intruder attack. Here you can view the progress of the requests plus their payload and status. Be patient as this can take quite some time to complete depending on the length of the list.
Once intruder is finished, you can view the details of any request simply by clicking on it.
What we are after here is the response. Every single request that was made returned a status code 200 response, but oftentimes when a payload is successful you will see a different code. Usually another way to tell if a query succeeded is if the length of the response is noticeably different from the others. I have selected the request containing the SQL query of ' or 1=1 or "=' because I had previously tested this injection manually, so I knew it would work.
Burp Suite is useful because you can actually render the webpage that is returned in the response by going to the "Response" tab and clicking "Render." We can see below that our SQL injection was successful and we now have usernames and passwords. If this was an administrative panel or something similar, we could log in with the admin credentials and wreak all kinds of havoc.
Although SQL injection has been known as a serious vulnerability for quite some time, it continues to be one of the most common methods of exploitation today. Part of this is because anyone can just piece together a semi-functioning web app and deploy it out on the internet. Even professional software developers often have a hard time adhering to secure coding principles, so it's no surprise when Jimmy down the street makes an application that's insecure.
In order to become truly effective with SQL injection, it's probably best to actually learn SQL itself. After all, the best way to break something is knowing how it works and using that knowledge for abuse. While conducting your tests, once you've found a vulnerability and a payload that works, you can customize the SQL to execute your own commands. This is useful for figuring out the layout of tables, modifying data, and even discovering other tables within the database. There really is no limit to what you can do once a genuine grasp of SQL is attained.
Until the day comes when proper security is the highest priority, there will continue to be SQL injection flaws in web applications. This means that there will always be plenty of work for all you white hatters, so get out there and hack away.