Usually, whenever we are auditing a web application with a poorly programmed backend, we might find SQL Injection vulnerabilities. We will mainly encounter Blind, Error-based or -if we get lucky- Union-based injections. However, it is not quite usual to find an SQLi out-of-band vulnerability.
These do not only rely on a vulnerable application, but also on being able to exfiltrate information from a different band than the website.
The fact that the results are sent through a completely different way, along with the variety of shapes that these may take; makes it quite difficult to use automated tools to exploit these kinds of vulnerabilities. Even so, in situations where the server responses are not stable or are too unreliable, it might be worth trying to exfiltrate information this way.
As an example, lets take a look at an injection found in an audit I performed recently.
This time, the vulnerability was quite weird, as the name of the parameter was sql*** –which shouted injection from miles away- but the website itself wasn’t either returning any errors nor being affected by time-based techniques. Yet, our best friend Burp active scan seemed convinced that an SQLi was going on at that specific parameter.
Examining it calmly, we discover that the application can be compromised using an old Oracle vulnerability, dated in 2014! . This vulnerability comes from an error in the security measures applied when parsing XML on Oracle, which prevent the inclusion of external entities, but do not filter the request to obtain them. In short, it is a, authenticated pseudo-XXE vulnerability, midly difficult to exploit in a common situation, but an interesting exfiltration method for opportunistic auditors like us.
The vulnerability uses the following payload:
This will force a connection to http://IP/test from the database in order to obtain XML Entity, but, we can also modify the requested URL to concatenate queries to the database and exfiltrate the results just like this:
Causing our server to recieve a request like this one:
The only downsides to this exfiltration technique are that we will only be able to return one cell at a time, forcing us to be very specific in our queries; and that we need a server accesible from the internet. All of this might be a problem if we exploited the vulnerability manually each time we found it, but, who likes to do things manually, right?
Automating
To automate the exploitation process, I made a small script that generates the payloads, sends them and initializes the web server to recieve the results.
For the time being, the script only supports GET requests with customizable headers and URL. It also allows not launching the web server, in case we want to recieve the responses on a different one. It has 4 output levels(or logging, for the connoisseurs): Info, Ok, Warning y Error.
The output looks like this:
It also uses an external payload file, payloads.lst by default, which we can modify to our liking, or even choose a file for ourselves.
Conclusion
As always, keep your systems updated, including your database. It can make the difference!
Check out the source code of the script here
(Post outputs are simplified to hide sensitive information)
Bibliography:
