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
Usando
localhost
Usando
127.0.0.1
Usando
0.0.0.0
Cloud metadata
AWS
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)
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:
En la petición donde se generaba el pdf, viajaba un campo HTML, donde podíamos insertar código HTML.
Al descargar el archivo PDF generado vemos el iframe que realizó una solicitud a mi Burp Collaborator confirmando el SSRF:
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:
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:
Recursos
Última actualización