Introducción

¿Qué es Server Side Request Forgery (SSRF)?

Server Side Request Forgery ocurre cuando puedes obligar a un servidor a realizar solicitudes arbitrarias en tu nombre. Como las solicitudes las realiza el servidor, es posible acceder a recursos internos debido a la posición del servidor en la red. En entornos de nube, SSRF presenta un riesgo más significativo debido a la presencia de endpoints de metadatos que pueden contener credenciales sensibles o secretos.

Blind SSRF

Al explotar la falsificación de solicitudes del lado del servidor, a menudo podemos encontrarnos en una posición en la que la respuesta no puede leerse. En la industria, este comportamiento se conoce a menudo como "Blind SSRF". En tales situaciones, ¿cómo demostramos el impacto? Esta fue una interesante discusión que Justin Gardner inició en Twitter:

He estado encontrando una gran cantidad de Blind SSRF recientemente. ¿Qué tipo de RCE de un solo disparo han usado como pivotes para estos casos en el pasado? Tengo acceso a algo de Kafka y un montón de otras cosas. @nnwakelam @thedawgyg

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

Si puedes alcanzar recursos internos, hay una serie de cadenas de explotación potenciales que se pueden ejecutar para demostrar el impacto. Esta entrada de blog intenta entrar en detalle sobre cada cadena de explotación conocida al aprovechar blind SSRF, y se actualizará a medida que se descubran y compartan más técnicas.

Si se nos ha escapado alguna técnica, envíanos un tweet o un mensaje directo (DM): @assetnote y la añadiremos a este blog.

Canarios SSRF

Tiendo a llamarlos canarios SSRF, cuando se encadena un blind SSRF con otro SSRF interno que realiza una llamada adicional externamente, o mediante un redireccionamiento abierto específico de la aplicación o un XXE ciego. Confluence, Artifactory, Jenkins y JAMF tienen algunos que funcionan bien.

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

Para validar que puedes interactuar con servicios o aplicaciones internos, puedes utilizar "canarios SSRF".

Esto ocurre cuando podemos solicitar una URL interna que realiza otro SSRF y hace una llamada a tu host canario. Si recibes una solicitud en tu host canario, significa que has alcanzado con éxito un servicio interno que también es capaz de realizar solicitudes salientes.

Esta es una forma eficaz de verificar que una vulnerabilidad SSRF tiene acceso a redes o aplicaciones internas, y también de confirmar la presencia de cierto software existente en la red interna. También es posible pivotar potencialmente hacia partes más sensibles de una red interna usando un canario SSRF, dependiendo de dónde se encuentre.

Uso de fuentes de datos DNS y AltDNS para encontrar hosts internos

Con el objetivo de encontrar tantos hosts internos como sea posible, se pueden utilizar fuentes de datos DNS para encontrar todos los registros que apunten a hosts internos.

En entornos de nube, a menudo vemos ELB que apuntan a hosts dentro de una VPC interna. Dependiendo de en qué VPC se encuentre el activo que estás atacando, puede ser posible acceder a otros hosts dentro de la misma VPC.

Por ejemplo, considera que el siguiente host ha sido descubierto a partir de fuentes de datos DNS:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82

Puedes asumir que `es` significa Elasticsearch y luego realizar más ataques contra este host. También puedes lanzar todos estos payloads de SSRF ciego contra todos los hosts "internos" que hayas identificado mediante este método. Esto suele ser efectivo.

Para encontrar más hosts internos, recomiendo tomar todos tus datos DNS y luego usar algo como [AltDNS](https://github.com/infosec-au/altdns) para generar permutaciones y resolverlas con un [bruteforcer de DNS rápido](https://github.com/blechschmidt/massdns).

Una vez que esto esté completo, identifica todos los hosts internos recién descubiertos y úsalos como parte de tu cadena de SSRF ciego.

## Fugas de canal lateral

Al explotar vulnerabilidades de SSRF ciego, es posible que puedas filtrar algo de información sobre la respuesta que se devuelve. Por ejemplo, supongamos que tienes SSRF ciego a través de un XXE; los mensajes de error pueden indicar si:

- Se devolvió una respuesta  

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

vs.

- El host y el puerto son inalcanzables

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

De manera similar, fuera de los XXEs, una aplicación web también podría tener una fuga de canal lateral que se puede determinar inspeccionando las diferencias en:

- **Código de estado de la respuesta**: 

Activo interno en línea:puerto responde con `200 OK` vs activo interno fuera de línea:puerto `500 Internal Server Error`

- **Contenido de la respuesta**: 

El tamaño de la respuesta en bytes es menor o mayor dependiendo de si la URL que intentas solicitar es alcanzable o no.

- **Tiempo de respuesta**: 

Los tiempos de respuesta son más lentos o más rápidos dependiendo de si la URL que intentas solicitar es alcanzable o no.

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

# Técnicas
**Posible vía 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)
- [Otros productos de Atlassian](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix Dashboard](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)

**Posible vía Gopher**

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

**Herramientas**

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

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

**Posible vía HTTP(s)**

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

## Elasticsearch

**Puerto de escucha habitual: 9200**

Cuando Elasticsearch se despliega internamente, normalmente no requiere autenticación. 

Si tienes un SSRF parcialmente ciego en el que puedes determinar el código de estado, comprueba si los siguientes endpoints devuelven un 200:```http
/_cluster/health
/_cat/indices
/_cat/health

Si tienes un SSRF ciego donde puedes enviar solicitudes POST, puedes apagar la instancia de Elasticsearch enviando una solicitud POST a la siguiente ruta:

Nota: la API _shutdown se ha eliminado de Elasticsearch a partir de la versión 2.x. Esto solo funciona en Elasticsearch 1.6 o inferior:```http /_shutdown /_cluster/nodes/_master/_shutdown /_cluster/nodes/_shutdown /_cluster/nodes/_all/_shutdown

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

## Weblogic

**Puertos comúnmente vinculados: 80, 443 (SSL), 7001, 8888**

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