Learning CTF with DVWA – SQL Injection

Continuing in my serious of learning CTF using “Dam Vulnerable Web Application”, lets take a look at DVWA sqli. So DVWA (Dam Vulnerable Web Application) is a web application we can use to learn about Linux exploits that we see in use for common CTF challenges. In summary this post I will go through Learning to beat DVWA sql injection via the web GUI.

What is sql injection?

SQL Injection (SQLi) is an injection attack that makes it possible to execute malicious SQL statements. These statements control a database server behind a web application. An SQL Injection vulnerability may affect any website or web application that uses an SQL database such as MySQL, Oracle, SQL Server, or others. Therefore best prevention is to have input validation in place to prevent it from happening.

Types of SQL Injection

Union Based SQLI

This type utilizes the the UNION SQL operator to combine the results of two or more SELECT statements into a single result. This is what we will be using in this blog post.

Blind SQL Injection

This is a type of SQL injection, where we don’t see whether the web application is vulnerable to a injection attack as there is no reply that we can read. However, I wont be covering it in this post. But will in a future post.

Set-up

DVWA SQL Injection

Security Levels

Like the rest of the DVWA challenges, the LFI one comes with 4 security levels.

• Low, very straight forward Injection attack.
• Medium, very similar to the previous one slightly different approach.
• High, Similar to the preceding two, not too challenging.
• Impossible, what is says.

Beating DVWA SQL Injection low

Overview

After logging and confirming the security setting is set to low, go to the “SQL Injection” page. In here you are presented with a page asking for a “User ID”. We can input the number “1”, click “Submit” and view the result.

Information is returned about the user with the “User ID” of 1. In this case its the admin user. So lets take some time to examine the url that we were sent to after inputting the “User ID”

http://192.168.1.163:8082/vulnerabilities/sqli/?id=1&Submit=Submit#

The “User ID” we put in is sent back to the server within the URL as “id=1”. What happens in the back ground is that this id is input into a sql statement and the results are returned to the screen. So in the case of DVWA we can open up the source code of what happens by clicking on the “View Source” button on the bottom of the page.

Code Review

Typically there is no access to the this source code but we can see that the sql “Select” query is just run against the $id variable with no input validation. So in theory we can input anything we like to the end of the “User ID” and sql will try to interpret it.

So what code can we add so to get some useful information? First take a look at the actual SQL code that was sent.

SELECT first_name, last_name FROM users WHERE user_id = '1';

Suppose we want to get a list of all users in the database. We can modify the statement to look like.

SELECT first_name, last_name FROM users WHERE user_id = '1' or 1=1 -- -;

This would return a list of all users. It is telling the SQL engine to return first_name and last_name from the users table when the id is equal to 1 or if 1 is equal to 1. As 1 is always equal to 1 it will return everything.

SQL Injection

It goes into the “User ID” form in the format “1′ or 1=1 — –; “. Where you see “– ” its indicates that there is a comment coming up and everything after it will be ignored. There has to be a space after “–” so we add a third “-” so its clear there is a space.

All the accounts are now visible.

Beating DVWA SQL Injection medium

Overview

Lets try this on harder settings. Change the DVWA Security level to be “Medium”

In this page is different and there is a drop down list where we can select a “User ID” and click a “Submit” button. We have no options to type anything in here.

Code Review

To view more information about whats going on here, right click the page and select “Inspect”. In the inspect window select Network. Then update the “User ID” to be 1 and click submit. In the networks window you will find that this was a POST request and highlighting it opens a new window and in the Request tab, it will have the data that is sent via a POST request to the page. In this case its “id:1″ and Submit:”Submit”.

Firefox offers a way to modify this and resend it. If you right click the POST request you will be presented with a menu. Click on “Edit and Resend”

This presents a new tab called “New Request” and this new request can be modified. In particular we can Modify the Request Body with our SQL Injection code.

SQL Injection

The code for this one doesn’t need any quotes and is “id=1 or 1=1 — -&Submit=Submit”

This will create and highlight a new POST request in the inspect windows. The output doesn’t appear directly in the window and you need to right click the new POST request and open it in a new tab.

And you can see below all the users have been outputted to the window.

Beating DVWA SQL Injection high

Overview

After the security settings are set to high and we browse back to the SQL Injection page we can notice that things have changed again. There is no drop down list this time. Only a Link, that if we click opens a new page.

SQL Injection

Although different it doesn’t make it any harder to inject our commands. So by just typing the same injection as the “low” security one, does the trick.

This outputs all the users.

Wrap-Up

SQLi is one most common Vulnerabilities out there. Further, according to OWASP 94% of all web applications they tested had a Injection Vulnerability and it is always is in the top 3 of their Top 10 security risks to web applications. The knowledge here is provided so you can use this skill against CTF challenges but also you should be aware of how common it is in the real world so you can can work to prevent it.