Server-side request forgery (SSRF)

Descripción

El Server-side Request Forgery o falsificación de solicitudes del lado del servidor en español (SSRF) es una vulnerabilidad de seguridad web que permite a un atacante inducir a la aplicación del lado del servidor a realizar solicitudes a una ubicación no deseada.

En un ataque SSRF típico, el atacante podría hacer que el servidor establezca una conexión con servicios exclusivamente internos dentro de la infraestructura de la organización. En otros casos, pueden obligar al servidor a conectarse a sistemas externos arbitrarios, lo que podría filtrar datos confidenciales, como credenciales de autorización.

Impacto

Un ataque SSRF exitoso a menudo puede resultar en acciones no autorizadas o acceso a datos dentro de la organización, ya sea en la propia aplicación vulnerable o en otros sistemas de back-end con los que la aplicación puede comunicarse. En algunas situaciones, la vulnerabilidad SSRF podría permitir a un atacante realizar la ejecución de comandos arbitrarios.

Un exploit SSRF que provoca conexiones a sistemas externos de terceros podría dar lugar a ataques maliciosos que parecen originarse en la organización que aloja la aplicación vulnerable.

Diferencias entre SSRF y CSRF

Una de las diferencias clave entre el SSRF y el CSRF es que el SSRF se ejecuta en el servidor web en lugar del navegador del usuario. El atacante no necesita engañar a un usuario legítimo para hacer clic en un enlace malicioso, ya que puede enviar la solicitud HTTP directamente al servidor web desde una fuente externa.

Mitigación

Para prevenir los ataques de SSRF, es importante que los desarrolladores de aplicaciones web validen y filtren adecuadamente la entrada del usuario y limiten el acceso del servidor web a los recursos de la red interna. Además, los servidores web deben ser configurados para limitar el acceso a los recursos sensibles y restringir el acceso de los usuarios no autorizados.

PoC - SSRF

Supongamos que tenemos el siguiente diagrama:

Tenemos por un lado al atacante que logra enumerar un sitio web en el servidor víctima que está trabajando en el puerto 80 (Producción). Por otro lado, tenemos que la vícitma puede visualizar un aplicativo web alojado en el puerto 4646 (Pre-Producción) sin embargo, este no está disponible en producción y el atacante no lo puede visualizar desde internet.

A continuación tenemos el aplicativo web que se encuentra en pre-producción trabajando en el puerto 4646, este no es accesible desde internet, por lo que, el atacante no puede acceder de forma directa.

Por otro lado, tenemos al aplicativo web trabajando en el puerto 80, este se encuentra en producción y el atacante lo puede visualizar de forma directa.

Sin embargo, para ventaja nuestra como atacantes, notamos que existe un aplicativo que contiene una vulnerabilidad de SSRF, por lo cual es posible enumerar aplicativos y puertos que se encuentren funcionando de forma interna al servidor. Veamos el siguiente ejemplo.

Podemos notar que en aplicativo llamado ‘utility.php’ al indicar el parámetro ‘url’, es posible listar el contenido del localhost (127.0.0.1) y dentro de esto se encuentra el aplicativo de pre-producción llamado ‘login.html’.

Primero realizaremos Fuzzing para identificar que puertos se estan utilizando de forma interna.

Utilizaremos wfuzz de la siguiente forma:

wfuzz -c -t 200 -hl=3 -z range,1-65535 "http://172.17.0.2/utility.php?url=http://127.0.0.1:FUZZ"

Flag	Descripción
-c	Imprimimos el outpout a color
-t 200	Se está indicando que se trabajará con 200 hilos.
-hl=3	Indicamos que oculte todo lo que tenga por salida 3 lineas.
-z range,1-65535	Con esto utilizamos un payload de rango, cuyo valor será desde 1 a 65535.

Al realizar nuestro Fuzzing, tenemos lo siguiente:

Se han encontrado dos puertos abiertos, puerto 80 y 4646.

Al ingresar desde el aplicativo vulnerable indicando el puerto 4646, podemos ver lo siguiente:

Tenemos el aplicativo de pre-producción, sin embargo, para acceder a el de forma correcta, este debe ser cargado directamente desde el parámetro ‘url’ vulnerable.

Ahora podemos visualizar el sitio de pre producción explotando la vulnerabilidad de SSRF.