YoutubeLinkedInConóceme

Server-Side Request Forgery (SSRF)

Definición

Un SSRF (Server-Side Request Forgery) es una vulnerabilidad que permite a un atacante hacer que un servidor realice solicitudes no autorizadas, tanto a recursos internos como externos. Por ejemplo, si una aplicación permite al usuario enviar una URL, un atacante podría manipularla para acceder a servicios internos o recursos protegidos del servidor.

Impacto:

  • Enumeración de puertos: Probar puertos abiertos en servicios internos del servidor o la red (ej. localhost:80, localhost:443, etc.).

  • Acceso a recursos internos: Acceder a servicios internos que no están expuestos externamente, como bases de datos, APIs internas, o servicios administrativos.

  • Escaneo de IPs internas: Realizar escaneos de redes internas (por ejemplo, acceder a direcciones IP privadas de la red local).

  • Acceder a metadatos de la nube: Si el servidor está en la nube, puede permitirle al atacante acceder a los metadatos del servidor, que pueden contener información sensible (como credenciales).

  • Ejecutar comandos maliciosos: En algunos casos, el SSRF puede ser utilizado para inyectar comandos maliciosos y ejecutar acciones no autorizadas en el servidor.

Enumeración de puertos

  • Usandolocalhost

    http://localhost:80
http://localhost:22
https://localhost:443

  • Usando127.0.0.1

    http://127.0.0.1:80
http://127.0.0.1:22
https://127.0.0.1:443

  • Usando0.0.0.0

    http://0.0.0.0:80
http://0.0.0.0:22
https://0.0.0.0:443

Cloud metadata

AWS

Info: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories

GCP

Info: https://cloud.google.com/compute/docs/metadata

Requiere el header "Metadata-Flavor: Google" or "X-Google-Metadata-Request: True"

Azure

Info: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service

Requiere el header "Metadata: true"

Combinación SSRF + XSS

Cuando el SSRF no tiene ningún impacto crítico, la red está segmentada y no se puede acceder a otras máquinas y no permite extraer archivos del servidor, podemos intentar actualizar el SSRF a un XSS, incluyendo un archivo SVG que contenga código Javascript.

Combinación SSRF + LFI

Crear un archivo php:

Levantar un server en php:

Lanzamos un curl donde en el body agregamos la url a nuestro servidor:

HTTP Response:

Luego visitamos la siguiente URL del PDF donde podemos ver a nuestro win.ini:

Otros payloads:

Aquí ya queda sobre nuestra creatividad que archivo queremos leer internamente, como un /etc/passwd o ir por otros archivos.

Wkhtmltopdf - Pentest - Caso Real (SSRF + LFI)

Disclaimer: Los casos y ejemplos mostrados en esta sección del blog forman parte de auditorías y evaluaciones de seguridad realizadas en el contexto de proyectos profesionales con Hackmetrix. No se divulga información sensible, interna o específica de ningún cliente, y se ha tenido especial cuidado en proteger su confidencialidad. Además, cualquier vulnerabilidad mencionada o ilustrada en estos ejemplos ya ha sido corregida de manera responsable, siguiendo los procesos adecuados de remediación y comunicación con los respectivos equipos. Este contenido es compartido únicamente con fines educativos y de mejora continua en prácticas de seguridad.

Wkhtmltopdf es una librería que permite crear archivos HTML a PDF. El problema que esta está discontinua, es decir ya no la dan más soporte por lo que las vulnerabilidades aún siguen presentes.

En su última versión (0.12.6) se mantiene vulnerable a Server-Side Request Forgery (SSRF).

En versiones previas, por ejemplo la 0.12.5 son vulnerables a SSRF y LFI.

Pasemos al caso real, donde nos topamos con la versión 0.12.5:

A través de exiftool analizo el PDF que generaba la plataforma:

exiftool

En la petición donde se generaba el pdf, viajaba un campo HTML, donde podíamos insertar código HTML.

Inyectando iframe

Al descargar el archivo PDF generado vemos el iframe que realizó una solicitud a mi Burp Collaborator confirmando el SSRF:

SSRF en PDF

Luego intentamos obtener información de la metadata de la instancia de AWS:

Por último, nos traemos la información necesaria para autenticarnos a AWS:

Exfiltrando metadata AWS

Finalmente nos autenticamos con awscli. El archivo de configuración se encuentra en `~/.aws/credentials` y debería tener el siguiente formato:

Recordar que es una credencial temporal, y debemos agregar el token de sesión.

De aquí ya empieza la enumeración de AWS que ya es otra historia. Pero la cosa no termina aquí, esta librería también era vulnerable a LFI:

LFI

Recursos

AnteriorCross-Site Request Forgery (CSRF)SiguienteUnrestricted File Upload

Última actualización