Introduzione

Cos'è la Server Side Request Forgery (SSRF)?

La Server Side Request Forgery si verifica quando è possibile indurre un server a effettuare richieste arbitrarie per conto tuo. Poiché le richieste vengono effettuate dal server, potrebbe essere possibile accedere a risorse interne grazie alla posizione del server nella rete. Negli ambienti cloud, la SSRF comporta un rischio più significativo a causa della presenza di endpoint di metadati che possono contenere credenziali o segreti sensibili.

Blind SSRF

Quando si sfrutta la server-side request forgery, spesso ci si può trovare in una situazione in cui la risposta non può essere letta. Nel settore, questo comportamento viene spesso definito "Blind SSRF". In tali situazioni, come si dimostra l'impatto? Questa è stata una discussione interessante avviata da Justin Gardner su 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

Se riesci a raggiungere risorse interne, ci sono diverse potenziali catene di exploit che possono essere eseguite per dimostrare l'impatto. Questo post del blog tenta di entrare nel dettaglio di ogni catena di exploit nota quando si utilizza la blind SSRF, e verrà aggiornato man mano che verranno scoperte e condivise altre tecniche.

Se ci siamo persi qualche tecnica, inviaci un tweet o un messaggio diretto: @assetnote e la aggiungeremo a questo blog.

Canarie 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

Per convalidare di poter interagire con servizi o applicazioni interni, puoi utilizzare le "canarie SSRF".

Questo accade quando possiamo richiedere un URL interno che esegue un'altra SSRF e chiama il tuo host canary. Se ricevi una richiesta sul tuo host canary, significa che hai raggiunto con successo un servizio interno in grado di effettuare richieste in uscita.

Questo è un modo efficace per verificare che una vulnerabilità SSRF abbia accesso a reti o applicazioni interne, e anche per verificare la presenza di determinati software sulla rete interna. Inoltre, a seconda di dove si trova, puoi potenzialmente spostarti verso parti più sensibili di una rete interna utilizzando una canary SSRF.

Utilizzare le fonti DNS e AltDNS per trovare host interni

Con l'obiettivo di trovare il maggior numero possibile di host interni, le fonti DNS possono essere utilizzate per trovare tutti i record che puntano a host interni.

Negli ambienti cloud, vediamo spesso ELB che puntano a host all'interno di una VPC interna. A seconda della VPC in cui si trova l'asset che stai prendendo di mira, potrebbe essere possibile accedere ad altri host all'interno della stessa VPC.

Ad esempio, considera che il seguente host sia stato scoperto dalle fonti DNS:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82

Puoi presumere che `es` stia per Elasticsearch, e poi eseguire ulteriori attacchi su questo host. Puoi anche inviare tutti questi payload SSRF ciechi su tutti gli host "interni" identificati tramite questo metodo. Questo è spesso efficace.

Per trovare più host interni, consiglio di prendere tutti i tuoi dati DNS e poi usare qualcosa come [AltDNS](https://github.com/infosec-au/altdns) per generare permutazioni e poi risolverle con un [DNS bruteforcer veloce](https://github.com/blechschmidt/massdns).

Una volta completato, identifica tutti gli host interni appena scoperti e usali come parte della tua catena SSRF cieca.

## Side Channel Leaks

Quando sfrutti vulnerabilità SSRF cieche, potresti essere in grado di divulgare alcune informazioni sulla risposta restituita. Ad esempio, supponiamo di avere una SSRF cieca tramite XXE, i messaggi di errore potrebbero indicare se:

- Una risposta è stata restituita 

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

vs.

- Host e porta non sono raggiungibili

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

Allo stesso modo, al di fuori delle XXE, un'applicazione web potrebbe anche avere una perdita di canale laterale che può essere individuata ispezionando le differenze nei:

- **Codice di stato della risposta**: 

Asset interno online:porta risponde con `200 OK` vs asset interno offline:porta `500 Internal Server Error`

- **Contenuto della risposta**: 

La dimensione della risposta in byte è più piccola o più grande a seconda che l'URL che stai cercando di richiedere sia raggiungibile o meno.

- **Timing della risposta**: 

I tempi di risposta sono più lenti o più veloci a seconda che l'URL che stai cercando di richiedere sia raggiungibile o meno.

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

# Tecniche
**Possibili 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)
- [Altri prodotti Atlassian](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)

**Possibili via Gopher**

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

**Strumenti**

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

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

**Possibili via HTTP(s)**

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

## Elasticsearch

**Porta comunemente associata: 9200**

Quando Elasticsearch è distribuito internamente, di solito non richiede autenticazione. 

Se hai una SSRF parzialmente cieca in cui puoi determinare il codice di stato, controlla se i seguenti endpoint restituiscono un 200:```http
/_cluster/health
/_cat/indices
/_cat/health

Se hai un SSRF cieco con cui puoi inviare richieste POST, puoi spegnere l'istanza Elasticsearch inviando una richiesta POST al seguente percorso:

Nota: l'API _shutdown è stata rimossa da Elasticsearch versione 2.x in poi. Questo funziona solo in Elasticsearch 1.6 e versioni precedenti:```http /_shutdown /_cluster/nodes/_master/_shutdown /_cluster/nodes/_shutdown /_cluster/nodes/_all/_shutdown

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

## Weblogic

**Porte comunemente associate: 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