Introdução

O que é Server Side Request Forgery (SSRF)?

Server Side Request Forgery ocorre quando você pode coagir um servidor a fazer requisições arbitrárias em seu nome. Como as requisições são feitas pelo servidor, pode ser possível acessar recursos internos devido à posição do servidor na rede. Em ambientes de nuvem, o SSRF apresenta um risco mais significativo devido à presença de endpoints de metadados que podem conter credenciais sensíveis ou segredos.

SSRF Cego

Ao explorar server-side request forgery, muitas vezes podemos nos encontrar em uma posição onde a resposta não pode ser lida. Na indústria, esse comportamento é frequentemente chamado de "SSRF Cego". Em tais situações, como provamos o impacto? Esta foi uma discussão interessante que foi provocada por Justin Gardner no Twitter:

Recentemente, tenho encontrado uma grande quantidade de SSRF cegos. Que tipo de RCE de um único disparo vocês já usaram como pivô para esses casos? Tenho acesso a algum Kafka e várias outras coisas. @nnwakelam @thedawgyg

— Justin Gardner (@Rhynorater) 13 de janeiro de 2021

Se você pode alcançar recursos internos, há uma série de cadeias de exploração potenciais que podem ser executadas para provar o impacto. Este post de blog tenta entrar em detalhes para cada cadeia de exploração conhecida ao aproveitar SSRF cego, e será atualizado à medida que mais técnicas forem descobertas e compartilhadas.

Se perdemos alguma técnica, envie-nos um tweet ou uma DM: @assetnote e nós a adicionaremos a este blog.

SSRF Canaries

Costumo chamá-los de SSRF canaries, ao encadear um SSRF cego a outro SSRF internamente que faz uma chamada adicional externamente, ou por um redirecionamento aberto específico do aplicativo ou XXE cego. Confluence, Artifactory, Jenkins e JAMF têm alguns que funcionam bem.

— Frans Rosén (@fransrosen) 13 de janeiro de 2021

Para validar que você pode interagir com serviços ou aplicativos internos, você pode utilizar "SSRF canaries".

Isso ocorre quando podemos solicitar uma URL interna que executa outro SSRF e faz uma chamada para o seu host canário. Se você receber uma requisição em seu host canário, isso significa que você alcançou com sucesso um serviço interno que também é capaz de fazer requisições de saída.

Esta é uma maneira eficaz de verificar se uma vulnerabilidade de SSRF tem acesso a redes ou aplicativos internos, e também para verificar a presença de determinados softwares existentes na rede interna. Você também pode potencialmente pivotar para partes mais sensíveis de uma rede interna usando um SSRF canary, dependendo de onde ele está posicionado.

Usando fontes de dados DNS e AltDNS para encontrar hosts internos

Com o objetivo de encontrar o maior número possível de hosts internos, fontes de dados DNS podem ser utilizadas para encontrar todos os registros que apontam para hosts internos.

Em ambientes de nuvem, vemos frequentemente ELBs que apontam para hosts dentro de uma VPC interna. Dependendo de qual VPC o ativo que você está atacando está localizado, pode ser possível acessar outros hosts dentro da mesma VPC.

Por exemplo, considere que o seguinte host foi descoberto a partir de fontes de dados DNS:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82

Você pode supor que o `es` significa Elasticsearch e então realizar ataques adicionais neste host. Você também pode espalhar todos esses payloads de SSRF cego por todos os hosts "internos" que foram identificados por meio desse método. Isso geralmente é eficaz.

Para encontrar mais hosts internos, recomendo pegar todos os seus dados de DNS e usar algo como [AltDNS](https://github.com/infosec-au/altdns) para gerar permutações e depois resolvê-las com um [bruteforcer de DNS rápido](https://github.com/blechschmidt/massdns).

Quando isso estiver concluído, identifique todos os hosts internos recém-descobertos e use-os como parte da sua cadeia de SSRF cego.

## Vazamentos de Canal Lateral

Ao explorar vulnerabilidades de SSRF cego, você pode vazar algumas informações sobre a resposta que está sendo retornada. Por exemplo, digamos que você tenha SSRF cego via um XXE, as mensagens de erro podem indicar se:

- Uma resposta foi retornada 

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

vs.

- Host e porta estão inacessíveis

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

Da mesma forma, além de XXEs, um aplicativo web também pode ter um vazamento de canal lateral que pode ser constatado ao inspecionar diferenças em:

- **Código de status da resposta**: 

Ativo interno online:porta responde com `200 OK` vs. ativo interno offline:porta `500 Internal Server Error`

- **Conteúdo da resposta**: 

O tamanho da resposta em bytes é menor ou maior dependendo de se a URL que você está tentando solicitar está acessível ou não.

- **Tempo de resposta**: 

Os tempos de resposta são mais lentos ou mais rápidos dependendo de se a URL que você está tentando solicitar está acessível ou não.

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

# Técnicas
**Possíveis 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)
- [Outros Produtos Atlassian](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)

**Possíveis via Gopher**

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

**Ferramentas**

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

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

**Possíveis via HTTP(s)**

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

## Elasticsearch

**Porta comumente associada: 9200**

Quando o Elasticsearch é implantado internamente, geralmente não requer autenticação. 

Se você tiver um SSRF cego parcial em que possa determinar o código de status, verifique se os seguintes endpoints retornam um 200:```http
/_cluster/health
/_cat/indices
/_cat/health

Se você tiver um SSRF cego em que possa enviar requisições POST, você pode derrubar a instância do Elasticsearch enviando uma requisição POST para o seguinte caminho:

Nota: a API _shutdown foi removida do Elasticsearch a partir da versão 2.x. Isso só funciona no Elasticsearch 1.6 e anteriores:```http /_shutdown /_cluster/nodes/_master/_shutdown /_cluster/nodes/_shutdown /_cluster/nodes/_all/_shutdown

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

## Weblogic

**Portas comumente associadas: 80, 443 (SSL), 7001, 8888**

**Canário SSRF: 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