Introduction

Qu'est-ce que la Server Side Request Forgery (SSRF) ?

La Server Side Request Forgery se produit lorsque vous pouvez contraindre un serveur à effectuer des requêtes arbitraires en votre nom. Comme les requêtes sont effectuées par le serveur, il peut être possible d'accéder à des ressources internes en raison de la position du serveur dans le réseau. Dans les environnements cloud, la SSRF présente un risque plus important en raison de la présence de points de terminaison de métadonnées pouvant contenir des identifiants ou des secrets sensibles.

SSRF aveugle

Lors de l'exploitation d'une server-side request forgery, nous pouvons souvent nous retrouver dans une situation où la réponse ne peut pas être lue. Dans l'industrie, ce comportement est souvent appelé « SSRF aveugle ». Dans de telles situations, comment prouver l'impact ? C'est une discussion intéressante qui a été lancée par Justin Gardner sur Twitter :

I've been finding a large amount of Blind SSRFs recently. What kind of one-shot RCE's have you guys used as pivots for these in the past? I've got access to some Kafka and a bunch of other things. @nnwakelam @thedawgyg

— Justin Gardner (@Rhynorater) January 13, 2021

Si vous pouvez atteindre des ressources internes, il existe un certain nombre de chaînes d'exploitation potentielles qui peuvent être exécutées pour prouver l'impact. Cet article de blog tente d'approfondir chaque chaîne d'exploitation connue lors de l'utilisation d'une SSRF aveugle, et sera mis à jour à mesure que de nouvelles techniques seront découvertes et partagées.

Si nous avons oublié des techniques, veuillez nous envoyer un tweet ou un DM : @assetnote et nous l'ajouterons à ce blog.

Canaris SSRF

I tend to call them SSRF canaries, when chaining a blind SSRF to another SSRF internally which makes an additional call externally, or by an app-specific open redir or blind XXE. Confluence, Artifactory, Jenkins and JAMF have some that works well.

— Frans Rosén (@fransrosen) January 13, 2021

Afin de valider que vous pouvez interagir avec des services ou applications internes, vous pouvez utiliser des « canaris SSRF ».

Il s'agit de faire une requête vers une URL interne qui effectue une autre SSRF et appelle votre hôte canari. Si vous recevez une requête sur votre hôte canari, cela signifie que vous avez atteint avec succès un service interne capable également d'effectuer des requêtes sortantes.

C'est un moyen efficace de vérifier qu'une vulnérabilité SSRF a accès à des réseaux ou applications internes, et également de vérifier la présence de certains logiciels existant sur le réseau interne. Vous pouvez potentiellement également pivoter vers des parties plus sensibles d'un réseau interne à l'aide d'un canari SSRF, selon l'endroit où il se trouve.

Utilisation des sources de données DNS et d'AltDNS pour trouver des hôtes internes

Avec pour objectif de trouver autant d'hôtes internes que possible, les sources de données DNS peuvent être utilisées pour trouver tous les enregistrements pointant vers des hôtes internes.

Sur les environnements cloud, nous voyons souvent des ELB pointant vers des hôtes à l'intérieur d'un VPC interne. Selon le VPC dans lequel se trouve l'actif que vous ciblez, il peut être possible d'accéder à d'autres hôtes au sein du même VPC.

Par exemple, considérons l'hôte suivant qui a été découvert à partir de sources de données DNS :```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82

Vous pouvez supposer que `es` fait référence à Elasticsearch, puis effectuer d'autres attaques sur cet hôte. Vous pouvez également diffuser toutes ces charges utiles SSRF aveugles sur tous les hôtes « internes » identifiés via cette méthode. Cela est souvent efficace.

Pour trouver plus d'hôtes internes, je recommande de prendre toutes vos données DNS et d'utiliser quelque chose comme [AltDNS](https://github.com/infosec-au/altdns) pour générer des permutations, puis de les résoudre avec un [bruteforceur DNS rapide](https://github.com/blechschmidt/massdns).

Une fois cela fait, identifiez tous les hôtes internes nouvellement découverts et utilisez-les dans votre chaîne SSRF aveugle.

## Fuites par canal auxiliaire

Lors de l'exploitation de vulnérabilités SSRF aveugles, vous pouvez peut-être divulguer certaines informations sur la réponse renvoyée. Par exemple, supposons que vous ayez un SSRF aveugle via une XXE, les messages d'erreur peuvent indiquer si :

- Une réponse a été renvoyée

`Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.`

contre

- L'hôte et le port sont inaccessibles

`Error parsing request: System.Net.WebException: Unable to connect to the remote server`

De même, en dehors des XXE, une application web peut également présenter une fuite par canal auxiliaire qui peut être déterminée en inspectant les différences dans les :

- **Code de statut de la réponse** :

Actif interne en ligne : port répond avec `200 OK` contre actif interne hors ligne : port `500 Internal Server Error`

- **Contenu de la réponse** :

La taille de la réponse en octets est plus petite ou plus grande selon que l'URL que vous essayez de demander est accessible ou non.

- **Temps de réponse** :

Les temps de réponse sont plus lents ou plus rapides selon que l'URL que vous essayez de demander est accessible ou non.

---------------

# Techniques
**Possibles via HTTP(s)**

- [Elasticsearch](#elasticsearch)
- [Weblogic](#weblogic)
- [Hashicorp Consul](#consul)
- [Shellshock](#shellshock)
- [Apache Druid](#druid)
- [Apache Solr](#solr)
- [PeopleSoft](#peoplesoft)
- [Apache Struts](#struts)
- [JBoss](#jboss)
- [Confluence](#confluence)
- [Jira](#jira)
- [Other Atlassian Products](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)

**Possibles via Gopher**

- [Redis](#redis)
- [Memcache](#memcache)
- [Apache Tomcat](#tomcat)
- [FastCGI](#fastcgi)
- [Java RMI](#java-rmi)

**Outils**

- [Gopherus](#gopherus)
- [remote-method-guesser](#remote-method-guesser)
- [SSRF Proxy](#ssrfproxy)

----------------------------------

**Possibles via HTTP(s)**

<div id="elasticsearch"></div>

## Elasticsearch

**Port couramment utilisé : 9200**

Lorsque Elasticsearch est déployé en interne, il ne nécessite généralement pas d'authentification.

Si vous avez un SSRF partiellement aveugle où vous pouvez déterminer le code de statut, vérifiez si les points de terminaison suivants renvoient un 200 :```http
/_cluster/health
/_cat/indices
/_cat/health

Si vous avez une SSRF aveugle où vous pouvez envoyer des requêtes POST, vous pouvez arrêter l'instance Elasticsearch en envoyant une requête POST au chemin suivant :

Remarque : l'API _shutdown a été supprimée à partir de la version 2.x d'Elasticsearch. Cela ne fonctionne que dans Elasticsearch 1.6 et inférieur :```http /_shutdown /_cluster/nodes/_master/_shutdown /_cluster/nodes/_shutdown /_cluster/nodes/_all/_shutdown

<div id="weblogic"></div>

## Weblogic

**Ports généralement liés : 80, 443 (SSL), 7001, 8888**