blind-ssrf-chains - An exhaustive list of all the possible ways you ca

项目说明

Introduction

What is Server Side Request Forgery (SSRF)?

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 en, SSRF poses a more significant risk due to the presence of metadata endpoints that may contain sensiti or secrets.

Blind SSRF

When exploiting ser 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 pro? This was an interesting discussion that was sparked by Justin Gardner on Twitter:

<blockquote class="twitter-tweet" data-theme="dark"><p lang="en" dir="ltr">I&#39;ve been finding a large amount of Blind SSRFs recently. What kind of one-shot RCE&#39;s have you guys used as pivots for these in the past? I&#39;ve got access to some Kafka and a bunch of other things. <a href=" <a href=" Justin Gardner () <a href=" 13, 2021</a></blockquote>

If you can reach internal resources, there are a number of potential exploit chains that can be executed to pro. This blog post attempts to go into detail for each known exploit chain when le blind SSRF, and will be updated as more techniques are discovered and shared.

If we' any techniques, please send us a tweet or a DM: and we'll add it to this blog.

SSRF Canaries

<blockquote class="twitter-tweet" data-con="none" data-theme="dark"><p lang="en" dir="ltr">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.</p>&mdash; Frans Rosén () <a href=" 13, 2021</a></blockquote>

In order to 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 ha hit an internal service that is also capable making outbound requests.

This is an effective way to that an SSRF has access to a internal networks or applications, and to also the presence of certain software existing on the internal network. You can also potentially pivot to more sensiti of an internal network using an SSRF canary, depending on where it sits.

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 en, 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:

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.

Side Channel Leaks

When exploiting blind SSRF , you may be able to leak some information about the response being returned. For example, let's say that you ha 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 internal asset:port 500 Internal Ser

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.

---------------

Techniques

Possible

Tools

----------------------------------

Possible via HTTP(s)

<div id="elasticsearch"></div>

Elasticsearch

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:

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 2.x. and up. This only works in Elasticsearch 1.6 and below:

<div id="weblogic"></div>

Weblogic

Commonly bound ports: 80, 443 (SSL), 7001, 8888

SSRF Canary: UDDI Explorer (C)

This also works via GET:

This endpoint is also to CRLF injection:

Will result in the following request:

SSRF Canary: C

Taken from here.

Linux:

Windows:

<div id="consul"></div>

Hashicorp Consul

Commonly bound ports: 8500, 8501 (SSL)

Writeup can be found here.

<div id="shellshock"></div>

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:

Gist containing paths.

SSRF Canary: Shellshock via User Agent

<div id="druid"></div>

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 super on Apache Druid O:

<div id="solr"></div>

Apache Solr

Commonly bound port: 8983

SSRF Canary: Shards Parameter

<blockquote class="twitter-tweet" data-con="none" data-theme="dark"><p lang="en" dir="ltr">To add to what shubham is saying - scanning for solr is relatively easy. There is a shards= param which allows you to bounce SSRF to SSRF to you are hitting a solr instance blindly.</p>&mdash; Хавиж Наффи 🥕 () <a href=" 13, 2021</a></blockquote>

Taken from here.

SSRF Canary: Solr XXE (2017)

Apache Solr 7.0.1 XXE (Packetstorm)

RCE

Research on RCE

<div id="peoplesoft"></div>

PeopleSoft

Commonly bound ports: 80,443 (SSL)

Taken from this research here.

SSRF Canary: XXE #1

SSRF Canary: XXE #2

<div id="struts"></div>

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:

<div id="jboss"></div>

JBoss

Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)

Taken from here.

SSRF Canary: Deploy WAR from URL

<div id="confluence"></div>

Confluence

Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)

SSRF Canary: Sharelinks (Confluence released from 2016 No and older)

SSRF Canary: iconUriServlet - Confluence < 6.1.3 (C)

Atlassian Security Ticket OAUTH-344

<div id="jira"></div>

Jira

Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)

SSRF Canary: iconUriServlet - Jira < 7.3.5 (C)

Atlassian Security Ticket OAUTH-344

SSRF Canary: makeRequest - Jira < 8.4.0 (C)

Atlassian Security Ticket JRASER

<div id="atlassian-products"></div>

Other Atlassian Products

Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)

SSRF Canary: iconUriServlet (C):

Atlassian Security Ticket OAUTH-344

<div id="opentsdb"></div>

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 - C

<div id="jenkins"></div>

Jenkins

Commonly bound ports: 80,443 (SSL),8080,8888

Great writeup here.

SSRF Canary: C

RCE

Follow the instructions here to achieve RCE via GET: Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!

RCE

<div id="hystrix"></div>

Hystrix Dashboard

Commonly bound ports: 80,443 (SSL),8080

Spring Cloud Netflix, 2.2.x prior to 2.2.4, 2.1.x prior to 2.1.6.

SSRF Canary: C

<div id="w3"></div>

W3 Total Cache

Commonly bound ports: 80,443 (SSL)

W3 Total Cache 0.9.2.6-0.9.3

SSRF Canary: C

This needs to be a PUT request:

SSRF Canary

The ad for this was released here: W3 Total Cache SSRF

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 the presence of Docker's API:

RCE 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 affects Gitlab instances before 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 C. 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 ser via the target parameter:

----------

Possible

<div id="redis"></div>

Redis

Commonly bound port: 6379

Recommended reading:

RCE via Cron - Gopher Attack Surfaces

Gopher:

RCE Upload (PHP) - Redis Getshell Summary

RCE - Redis Getshell Summary

RCE on GitLab via Git protocol

Great writeup from Li 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.

<div id="memcache"></div>

Memcache

Commonly bound port: 11211

<div id="tomcat"></div>

Apache Tomcat

Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)

Effecti Tomcat 6 only:

gopher-tomcat-deployer

CTF writeup using this technique:

From XXE to RCE: Pwn2Win CTF 2018 Writeup

<div id="fastcgi"></div>

FastCGI

Commonly bound ports: 80,443 (SSL)

This was taken from here.

<div id="ja"></div>

Java RMI

Commonly bound ports: 1090,1098,1099,1199,4443-4446,8999-9010,9999

Blind *SSRF* that allow arbitrary bytes (*gopher based*) can be used to perform deserialization or
codebase attacks on the *Java RMI* default components (*RMI Registry*, *Distributed Garbage Collector*, *Acti System*).
A detailed writeup can be found here. The following listing
shows an example for the payload generation:

-------------------

Tools

<div id="gopherus"></div>

Gopherus

This tool generates Gopher payloads for:

<div id="remote-method-guesser"></div>

remote-method-guesser

*remote-method-guesser* is a *Java RMI* scanner that supports attack operations for most common *Java RMI*
. Most of the a operations support the `--ssrf option, to generate an *SSRF* payload for the
requested operation. Together with the --gopher` option, ready to use *gopher* payloads can be generated directly.

<div id="ssrfproxy"></div>

SSRF Proxy

SSRF Proxy is a multi-threaded HTTP proxy ser to tunnel client HTTP traffic through HTTP servers to Ser Request Forgery (SSRF).

---

Credits:

Thank you to the following people that ha to this post:

项目信息

开发语言：未知

Star 数：992

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕An exhaustive list of all the possible ways you can chain your Blind SSRF vulnerability展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。