SQL injection analysis

It is one thing to be able to execute a simple SQL injection attack; it is another to do a proper investigation of such an attack. Unfortunately, there is not much information on SQL Injection analysis. This article will assist in providing some tools for basic Incident Response. It can be fairly easily translated to apply to command injection analysis as well.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

Asking the right questions

If you work in an Incident Response Team or a Security Operation Centre and are tasked with the analysis of an SQL Injection attack, you will need to ask yourself a few questions to cover every bit of information you can extract. I will list the main question first and cover some (technical) examples later.

• What was the target?

This question will determine what the attempted outcome was of the attacker. It is important to understand whether this was a targeted attack aimed at a specific web server or a fire-and-forget scan on a (random) range of IP addresses. In the first, targeted instance, it is worth investigating a wider scope of logged security events to see what other tricks the attacker tried to perform. In the second instance, where the attack was not targeted, an SQL injection attack might not even be possible on the online services the target is providing.

• What was the attacker?

An important step is to trace the attacker back as far as possible to their origin. Sometimes this will lead to an easily identifiable source, sometimes even an internal host, which can identify a False Positive alert. Most of the time this will point to some TOR exit node or a randomly compromised external host, however. That means in many cases it is not feasible to further investigate the attack source itself.

• What was the attack trying to achieve?

For this step, you will ideally need a packet capture or, at least, the URL GET/POST request. An IDS device and some firewalls will capture the event trigger packet matching the security rule content which should have most information contained in it. Some IDS/IPS devices also provide the option to capture all traffic around the attack, which greatly helps to understand the sequence of traffic events and the outcome.

• What was the result of the attack?

This is probably the most important question to answer, but it requires the most information from logs and packet capture data. If an attacker reached a vulnerable server, what was the outcome? Was any data leaked back to the attacker? Where any accounts created? Was external malware loaded? The answer to this question will decide on the escalation path of the incident and the procedures, such as isolation of the server, to follow.

• What can be done?

This is a broad question, based on the outcome of the investigation. A good investigation includes a recommendation for an action. Some examples can be to patch a vulnerable server, disable unused services or to block a source IP. In the case of repeated false positive alerts, a recommendation can be to "tune" the alerting rule to exclude certain IP addresses or to modify the rule content matching parameters.

Brief SQL injection overview

SQL injection uses a security vulnerability, usually inside or via a web server, to exploit an SQL database. A successful SQL injection attack can lead to data leaking out of the SQL database, data modification in the SQL database, the execution of malicious code or even a full compromise of the targeted server(s).

An SQL Injection attack usually leverages a badly sanitized input field on a web form. Parts of SQL statements are fed into a web form field, which then make their way to the database server where they are processed. An example of an attack like this would be to dump the contents of the database to a publicly accessible file or back to the website output itself.

My fellow author Dhakkan has written an excellent article on the details of SQL injection attacks, combined with some examples here.

Example of an attack

For this example, we use the DVWA site included in Metasploitable. The Metasploitable Virtual machine is publicly available for testing, and there is a large amount of documentation about the installation and usage on the internet.

Note: If you follow these steps, make sure you set the security level to "Low" via the "DVWA Security" link on the left side.

We can then open the "SQL Injection" link on the left sidebar.

Let's start by entering a normal, valid command to get the username for ID 1.

This returns the First name and Surname for the user with ID 1 as expected:

This article is not intended to cover all the secrets of SQL Injection, but if we look at the following SQL SELECT statement this form uses, we can devise an attack method:

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

When we use our input of ID=1, the statement will look like this:

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

The user with ID value 1 is shown, matching the WHERE part of the statement.

What if we jump out of that command with the following input? (Mind the space at the end)

%' or '0'='0

The statement will look like this:

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '%' or '0'='0 '";

This will return all values where user ID is either % (made up non-existent value) OR 0=0 (Which is always true). The statement, if it is not rejected by some form of input validation, will return the details of every ID in the database because everything matches the query!

The analysis

This was a very simple attack. In real life, you will see many more complex attacks, most likely on a daily basis. Please understand however that it is essential to comprehend the concept of an attack before you can perform a proper analysis of it.

Now, let's see what we can find out about this attack from our logs and packet capture data.

When we 'tail' the varlogapache2access.log file on the Metasploitable host, we can see that the normal and the attack query are recorded.

The Attacker IP, in this case, is "192.168.1.13" which was my Kali test client. In a real life scenario, this IP might give you some interesting pointers as to what you are looking for. Remember: Ask the all the right questions.

We can see the GET requests to the server which contain the form field information. This will show you the attack that was attempted and might identify a False Positive alert due to for example a user typo. It can also lead to an insight of what the attacker was trying to accomplish. Did the attacker have a certain application and vulnerability in mind to perform the attack on? How customized or targeted was the attack?

The User Agent String is also a source of valuable information. What client was used for the attack? In this case IceWeasel 31.8.0, which is supplied with Kali 2.0

The last point to note is that the HTTP status code returned was a "200" value. The request was successful.

The log files are limited to showing the request data. To further dig into the attack, packet capture data is required. As mentioned, many firewall and IDS device vendor can either provide the trigger packet or a larger window of captured traffic for further analysis via various interfaces.

In this test setup, we will use Wireshark to capture our data.

First, we will set Wireshark on the Kali Client to listen to the traffic:

The attack is launched again, and Wireshark captures all the traffic to and from the target.

Find the traffic and "Follow the Stream" as below:

We can now see all the previously found Log data again. There is more, though.

This time, we can see the returned server traffic and the results of the query. This will enable the analyst to determine the outcome and impact of the attack on the target server.

We have now performed the basic analysis of an SQL Injection Attack. The next step is to either escalate this attack alert or to look at device rule or SIEM tuning options in case it turns out to be a False Positive alert.

One option for further analysis, if required, is to contact the SQL Database owner to investigate what happened from their perspective. They should have full database access and transaction logs.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

Make sure that as a minimum, you answer all the questions I started with. Not only will this lead to a proper analysis, but it will also teach you about new forms of SQL Injection attacks as well.