Server-Side Request Forgery (SSRF) is a vulnerability that let’s an attacker have a server make requests on their behalf. Typically this can allow the attacker to reach internal resources that would otherwise be unavailable. Whilst the typical SSRF is dangerous enough, there’s an even more elusive variant known as Blind SSRF, where the attacker doesn’t directly see the result of the forged request. Similar to attacks such as blind SQLi. This is where Out-of-Band (OOB) techniques come into play, providing a way to detect and verify Blind SSRF vulnerabilities.
Want to know more about typical SSRF attacks? Check out this blog post here, or if you prefer to watch, this video.
What is Blind SSRF?
In a standard SSRF attack, the response of the forged request is immediately visible to the attacker, often reflected in the application’s response. Blind SSRF, on the other hand, doesn’t offer this direct feedback. The server might process the attacker’s request and interact with internal or external services, but the result isn’t returned in the immediate output.
This makes Blind SSRF a little trickier to detect and exploit. But it’s just as dangerous as it can be used to probe internal networks, exfiltrate data, or interact with internal services without immediate detection.
Using Role of Out-of-Band (OOB) Techniques
Because the direct response is not visible in a Blind SSRF attack, we need an alternative method to confirm the vulnerability’s existence and, potentially, to exfiltrate data. This is where OOB techniques come in.
OOB techniques essentially involve inducing the vulnerable server to communicate with a server or endpoint that we control. By monitoring this server, we can confirm whether their payload executed a request. Alternatively, tools like BURP Suite’s collaborator can also be used.
Steps to Detect Blind SSRF using OOB:
1. Set up a listener: Use tools like http://webhook.site, Burp Collaborator or your own server to listen for incoming requests. This server is your OOB channel, awaiting incoming requests from the target server.
2. Craft a payload: For potential SSRF, inject a payload pointing to your OOB listener. For instance, if you suspect an image upload functionality to be vulnerable, you might provide a URL that points to your server.
3. Monitor your listener: If the server is vulnerable and processes your payload, it’ll send a request to your OOB listener. This request is your confirmation that the Blind SSRF exists.
4. Further exploitation: Depending on the nature of the vulnerability and the functionality of the application, you may be able to demonstrate the impact of this vulnerability.
Wrapping up
Blind SSRF vulnerabilities, while subtle, can be exploited often to the same extent as typical SSRF. Whilst it can be tricky to work without direct responses, the use of Out-of-Band techniques offers a way around this limitation.