SQL Injection: OAST techniques

Last updated on October 3, 2020

Today I bring you a very interesting type of SQL Injection, and that is not very well known. It’s a variation of Blind SQL Injection.if you’re still not very familiar with SQL injections, I recommend you visit this post first. You should also take a look at noSQL injections from non-relational databases.

In Blind SQL Injection, we can get information from the database if the server returns different responses depending on whether the injected payload (Boolean Blind SQL) is true or false. In case it always returns the same answer, we can get the database information from the server response times (Time Blind SQL).

However, it may be the case of an application that is vulnerable to SQL Injection but sends the answers asynchronously. In that case, if we inject a payload to try to cause a delay of 10 seconds in the response, the server receives the request and processes it in the original thread, but uses another thread to execute the query, we will not realize that the injection has worked because the process that will suffer the delay is different from the one that returns the response.

In these cases, the only solution is to try a Blind SQL using out-of-band techniques (OAST). That is, to make the server interact with another system under our control through another protocol. Normally the DNS protocol is used. This is due to the fact that the server is probably forbidden to communicate with the outside world with most protocols, but it is usual that it is allowed to perform DNS queries, since they need it to resolve domains in their usual operation. Let’s see an example.

Blind SQL Injection Out of Band with DNS interaction

The first thing you need is a server capable of receiving requests. The easiest way to do this is to open a Burp instance of the Burp Collaborator client.

If the victim server is vulnerable and we can inject code into the SQL query, you can inject a command that makes the victim server connect to yours to make a DNS lookup.

Depending on the database being used, the command is different. I usually use pentestmonkey cheatsheets:

Oracle – MSSQL – MySQL – PostgreSQL – Ingres – DB2 – Informix

The portswigger cheatsheet is also pretty good.

In this example the victim runs an Oracle database. After a couple of attempts I got it to run by injecting the following payload, which performs a dns lookup to our server (in my case the Burp Collaborator Client server I launched previously has the name “569xdp89rrergcdn1060o459m0srgg.burpcollaborator.net” assigned to it):

The way to check if it has worked is to go to the Burp Collaborator client and click on “Poll now”. If we receive a DNS request from the victim, then he has executed the query:

Now let’s see if we can get information from the database.

Exfiltering database information with Out of Band techniques

Once you have verified that the victim server makes the request to your server, you can execute the queries and the server will send you the results of them as a dns lookup request of a subdomain. For example, next I’m going to make it give me back the password of the managed user:

I press Poll now again on my Burp Collaborator client (which has now become ob3gi8dswajalvi66jbjtnasrjxfl4.burpcollaborator.net) and the password appears as a subdomain: