Entendiendo y Mitigando el Server-Side Request Forgery (SSRF): Una Vulnerabilidad Crítica en la Web

En 2019, Capital One (uno de los bancos mas grandes de USA) sufrió una violación de datos masiva que expuso la información personal de más de 100 millones de clientes. El ataque, que resultó en el robo de solicitudes de tarjetas de crédito, números de seguridad social y cuentas bancarias, fue posible gracias a una vulnerabilidad de Server-Side Request Forgery (SSRF). Este incidente destaca las graves consecuencias del SSRF y subraya la importancia de entender y mitigar esta crítica falla de seguridad web. Es por esto que SSRF es el segundo problema mas grave del OWASP top 10.

Server-Side Request Forgery es una vulnerabilidad de seguridad web que permite a un atacante inducir a una aplicación del lado del servidor a realizar solicitudes HTTP a un dominio arbitrario elegido por el atacante. En esta lección, exploraremos el concepto de SSRF, su impacto y cómo prevenir este tipo de fallas de seguridad devastadoras.

Un Ejemplo Técnico Específico de SSRF

Veamos un ejemplo concreto de una vulnerabilidad SSRF en una aplicación web. Considera el siguiente escenario que involucra una funcionalidad defectuosa de procesamiento de imágenes:

Imagina una aplicación web que permite a los usuarios enviar una URL de una imagen, que el servidor luego recupera, procesa y muestra de nuevo al usuario. El proceso funciona de la siguiente manera:

1. El usuario envía una URL a través de un formulario en el sitio web.
2. El servidor recibe la URL y realiza una solicitud para recuperar la imagen.
3. El servidor procesa la imagen (por ejemplo, redimensiona o aplica filtros).
4. La imagen procesada se muestra de nuevo al usuario.

1from flask import Flask, request, Response
2import requests
3
4app = Flask(__name__)
5
6@app.route('/fetch_image', methods=['POST'])
7def fetch_image():
8    image_url = request.form.get('image_url')
9    if image_url:
10        # Recupera la imagen desde la URL proporcionada por el usuario
11        response = requests.get(image_url)
12        image = response.content
13
14        # Procesar la imagen (ej., redimensionar o aplicar filtros)
15        # Por simplicidad, solo mostraremos la imagen sin procesarla
16        return Response(image, content_type='image/jpeg')
17
18if __name__ == '__main__':
19    app.run()

1const express = require('express');
2const axios = require('axios');
3const app = express();
4
5app.use(express.urlencoded({ extended: true }));
6
7app.post('/fetch_image', async (req, res) => {
8    const imageUrl = req.body.image_url;
9    if (imageUrl) {
10        try {
11            // Recupera la imagen desde la URL proporcionada por el usuario
12            const response = await axios.get(imageUrl, { responseType: 'arraybuffer' });
13            const image = response.data;
14
15            // Procesar la imagen (ej., redimensionar o aplicar filtros)
16            // Por simplicidad, solo mostraremos la imagen sin procesarla
17            res.contentType('image/jpeg');
18            res.send(image);
19        } catch (error) {
20            res.status(500).send('Error al recuperar la imagen');
21        }
22    } else {
23        res.status(400).send('No se proporcionó una URL de imagen');
24    }
25});
26
27const PORT = 3000;
28app.listen(PORT, () => {
29    console.log(`Servidor corriendo en el puerto ${PORT}`);
30});

Como puedes ver, se recibe image_url y se usa para recuperar una supuesta imagen de internet. El problema aquí es que confiamos en que esta image_url sea una imagen válida y no algún punto interno. Nuestro servidor está haciendo una solicitud a esta image_url y devolviendo la respuesta. Estamos permitiendo que los hackers proporcionen una URL que estamos recuperando. 🫣 ¿Qué pasa si proporcionan una URL a nuestra intranet?

Aunque este código parece simple, es vulnerable a SSRF. Un atacante podría explotar esta funcionalidad enviando una URL maliciosa que apunte a servicios o puntos internos, obteniendo acceso no autorizado a datos sensibles o realizando acciones que el servidor tiene permitido hacer en su red.

Por ejemplo, el atacante podría enviar la siguiente URL:

1http://localhost/admin/internal/secret

Si el servidor que ejecuta este código tiene acceso a la interfaz interna localhost, intentará recuperar el recurso, posiblemente filtrando información interna sensible.

Impacto del SSRF

El daño potencial causado por un ataque SSRF depende de los permisos y el acceso a la red del servidor vulnerable. Aquí algunos de los riesgos:

• Acceso a servicios internos: SSRF puede permitir a los atacantes acceder a servicios que de otro modo serían inaccesibles desde internet, como bases de datos internas, puntos de metadata en la nube o interfaces de administración.
• Exfiltración de datos: Datos sensibles almacenados en servidores internos pueden ser filtrados al atacante.
• Ejecución remota de código: En algunos casos, SSRF puede llevar a ataques adicionales como la ejecución remota de código (RCE) si el atacante puede explotar otras vulnerabilidades en la red interna.

La violación de Capital One es un ejemplo perfecto de cómo una vulnerabilidad SSRF puede ser utilizada para acceder a metadata interna de AWS, lo que resultó en el robo de datos sensibles de los clientes.

Prevención de Ataques SSRF

Para mitigar el riesgo de vulnerabilidades SSRF, considera las siguientes mejores prácticas:

1. Validación de entradas y listas blancas: Solo permite solicitudes a dominios de confianza implementando listas blancas estrictas. Evita permitir a los usuarios enviar URLs arbitrarias.
2. Segmentación de la red: Asegúrate de que los servicios internos no sean accesibles directamente desde la aplicación web. Limita la capacidad del servidor para realizar solicitudes salientes a redes internas.
3. Deshabilitar protocolos innecesarios: Prevén el uso de protocolos como file://, gopher:// u otros que puedan introducir riesgos adicionales.
4. Usar un firewall o proxy: Rutea las solicitudes salientes a través de un firewall o proxy para bloquear intentos de acceso a recursos internos.
5. Protección de metadata en la nube: Si utilizas servicios en la nube como AWS, asegúrate de que los puntos de metadata estén correctamente restringidos para prevenir accesos no autorizados.

Al adoptar estas medidas, las organizaciones pueden reducir significativamente el riesgo de ataques SSRF y proteger los datos sensibles de actores malintencionados.

Herramientas para Detectar SSRF

Detectar vulnerabilidades SSRF puede ser desafiante, pero existen varias herramientas y técnicas que pueden ayudar a identificar y mitigar estos riesgos:

1. Burp Suite: Burp Suite es un escáner de vulnerabilidades web popular que incluye funciones para detectar SSRF. Para usar Burp Suite en la detección de SSRF:

   • Configura Burp Suite como proxy y configura tu navegador para usarlo.
   • Intercepta y analiza las solicitudes HTTP realizadas por la aplicación.
   • Busca solicitudes que incluyan URLs proporcionadas por el usuario o parámetros que puedan ser manipulados.
   • Usa la herramienta Intruder de Burp Suite para probar varios payloads y observar la respuesta del servidor.

2. OWASP ZAP: El OWASP Zed Attack Proxy (ZAP) es un escáner de seguridad de aplicaciones web de código abierto. Para usar OWASP ZAP en la detección de SSRF:

   • Configura ZAP como proxy y configura tu navegador para usarlo.
   • Rastrea la aplicación para descubrir todos los puntos finales.
   • Usa la función de Escaneo Activo para probar vulnerabilidades SSRF inyectando payloads en los parámetros de URL.
   • Revisa los resultados del escaneo para detectar posibles vulnerabilidades SSRF.

3. Nmap: Nmap es una herramienta de escaneo de redes que puede ser usada para descubrir puertos abiertos y servicios en una red. Para usar Nmap en la detección de SSRF:

   • Ejecuta Nmap para escanear la red interna y detectar puertos y servicios abiertos.
   • Usa la información recopilada para identificar servicios internos potenciales que podrían ser objetivos de ataques SSRF.
   • Prueba la aplicación intentando acceder a estos servicios internos a través de URLs proporcionadas por el usuario.

4. SSRFmap: SSRFmap es una herramienta especializada diseñada para automatizar la detección y explotación de vulnerabilidades SSRF. Para usar SSRFmap:

   • Instala SSRFmap y configúralo con la URL de destino y los parámetros.
   • Ejecuta SSRFmap para escanear vulnerabilidades SSRF y probar varios payloads.
   • Revisa los resultados para identificar posibles explotaciones exitosas de SSRF.

5. Amass: Amass es una herramienta para el mapeo de redes y descubrimiento de superficies de ataque. Para usar Amass en la detección de SSRF:

   • Ejecuta Amass para mapear la red y descubrir servicios y puntos finales internos.
   • Usa la información recopilada para identificar posibles objetivos de ataques SSRF.
   • Prueba la aplicación intentando acceder a estos servicios internos a través de URLs proporcionadas por el usuario.

6. Scripts Personalizados: Los profesionales de la seguridad también pueden escribir scripts personalizados

para probar vulnerabilidades SSRF. Para usar scripts personalizados:

• Identifica los parámetros de URL proporcionados por el usuario en la aplicación.
• Escribe scripts para inyectar varios payloads en estos parámetros y observa la respuesta del servidor.
• Analiza las respuestas para determinar si la aplicación es vulnerable a SSRF.

Al utilizar estas herramientas y técnicas, las organizaciones pueden identificar proactivamente y abordar vulnerabilidades SSRF, reduciendo el riesgo de explotación por actores malintencionados.