Blind SSRF Chains
Using DNS datasources and AltDNS to find internal hosts
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.82You 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.
Side Channel Leaks
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:
A response was returned
Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.
vs.
Host and port are unreachable
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:
Response status code:
Online internal asset:port responds with 200 OK vs offline internal asset:port 500 Internal Server Error
Response contents:
The response size in bytes is smaller or bigger depending on whether or not the URL you are trying to request is reachable.
Response timing:
The response times are slower or faster depending on whether or not the URL you are trying to request is reachable.
Techniques
Possible via HTTP(s)
Possible via Gopher
Tools
Possible via HTTP(s)
Apache mod_proxy
Commonly bound port: 80,443
SSRF Canary: Apache mod_proxy SSRF (CVE-2021-40438)
Affects Apache <= 2.4.48.
A reference for this bug can be found here: https://firzen.de/building-a-poc-for-cve-2021-40438.
Weblogic
Commonly bound ports: 80, 443 (SSL), 7001, 8888
SSRF Canary: UDDI Explorer (CVE-2014-4210)
This also works via GET:
This endpoint is also vulnerable to CRLF injection:
Will result in the following request:
SSRF Canary: CVE-2020-14883
Taken from here.
Linux:
Windows:
Hashicorp Consul
Commonly bound ports: 8500, 8501 (SSL)
Writeup can be found here.
Shellshock
Commonly bound ports: 80, 443 (SSL), 8080
In order to effectively test for Shellshock, you may need to add a header containing the payload. The following CGI paths are worth trying:
Short list of CGI paths to test:
SSRF Canary: Shellshock via User Agent
Apache Druid
Commonly bound ports: 80, 8080, 8888, 8082
See the API reference for Apache Druid here.
If you can view the status code, check the following paths to see if they return a 200 status code:
Shutdown tasks, requires you to guess task IDs or the datasource name:
Shutdown supervisors on Apache Druid Overlords:
Apache Solr
Commonly bound port: 8983
SSRF Canary: Shards Parameter
Taken from here.
SSRF Canary: Solr XXE (2017)
Apache Solr 7.0.1 XXE (Packetstorm)
RCE via dataImportHandler
Research on RCE via dataImportHandler
PeopleSoft
Commonly bound ports: 80,443 (SSL)
Taken from this research here.
SSRF Canary: XXE #1
SSRF Canary: XXE #2
Apache Struts
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
Taken from here.
SSRF Canary: Struts2-016:
Append this to the end of every internal endpoint/URL you know of:
JBoss
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
Taken from here.
SSRF Canary: Deploy WAR from URL
Confluence
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
RCE via OGNL Injection (CVE-2021-26084)
SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)
SSRF Canary: iconUriServlet - Confluence < 6.1.3 (CVE-2017-9506)
Atlassian Security Ticket OAUTH-344
Jira
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
SSRF Canary: iconUriServlet - Jira < 7.3.5 (CVE-2017-9506)
Atlassian Security Ticket OAUTH-344
SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)
Atlassian Security Ticket JRASERVER-69793
Other Atlassian Products
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
SSRF Canary: iconUriServlet (CVE-2017-9506):
Bamboo < 6.0.0
Bitbucket < 4.14.4
Crowd < 2.11.2
Crucible < 4.3.2
Fisheye < 4.3.2
Atlassian Security Ticket OAUTH-344
OpenTSDB
Commonly bound port: 4242
OpenTSDB Remote Code Execution
SSRF Canary: curl via RCE
OpenTSDB 2.4.0 Remote Code Execution
SSRF Canary: curl via RCE - CVE-2020-35476
Jenkins
Commonly bound ports: 80,443 (SSL),8080,8888
Great writeup here.
SSRF Canary: CVE-2018-1000600
RCE
Follow the instructions here to achieve RCE via GET: Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!
RCE via Groovy
Hystrix Dashboard
Commonly bound ports: 80,443 (SSL),8080
Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1.6.
SSRF Canary: CVE-2020-5412
W3 Total Cache
Commonly bound ports: 80,443 (SSL)
W3 Total Cache 0.9.2.6-0.9.3
SSRF Canary: CVE-2019-6715
This needs to be a PUT request:
SSRF Canary
The advisory for this vulnerability was released here: W3 Total Cache SSRF vulnerability
This PHP code will generate a payload for your SSRF Canary host (replace url with your canary host):
Docker
Commonly bound ports: 2375, 2376 (SSL)
If you have a partially blind SSRF, you can use the following paths to verify the presence of Docker’s API:
RCE via running an arbitrary docker image
Replace alpine with an arbitrary image you would like the docker container to run.
Gitlab Prometheus Redis Exporter
Commonly bound ports: 9121
This vulnerability affects Gitlab instances before version 13.1.1. According to the Gitlab documentation Prometheus and its exporters are on by default, starting with GitLab 9.0.
These exporters provide an excellent method for an attacker to pivot and attack other services using CVE-2020-13379. One of the exporters which is easily exploited is the Redis Exporter.
The following endpoint will allow an attacker to dump all the keys in the redis server provided via the target parameter:
Possible via Gopher
Redis
Commonly bound port: 6379
Recommended reading:
RCE via Cron - Gopher Attack Surfaces
Gopher:
RCE via Shell Upload (PHP) - Redis Getshell Summary
RCE via authorized_keys - Redis Getshell Summary
RCE on GitLab via Git protocol
Great writeup from Liveoverflow here.
While this required authenticated access to GitLab to exploit, I am including the payload here as the git protocol may work on the target you are hacking. This payload is for reference.
Memcache
Commonly bound port: 11211
Apache Tomcat
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
Effective against Tomcat 6 only:
CTF writeup using this technique:
From XXE to RCE: Pwn2Win CTF 2018 Writeup
FastCGI
Commonly bound ports: 80,443 (SSL)
This was taken from here.
Tools
Gopherus
This tool generates Gopher payloads for:
MySQL
PostgreSQL
FastCGI
Redis
Zabbix
Memcache
SSRF Proxy
SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP traffic through HTTP servers vulnerable to Server-Side Request Forgery (SSRF
Last updated
