Al explorar la seguridad de los servidores web, es esencial entender cómo las vulnerabilidades pueden convertirse en puertas traseras para ataques cibernéticos. Imagina que tu servidor web es como una casa, y los puntos de entrada o endpoints son ventanas a través de las cuales interactúas con el mundo exterior. Estas “ventanas” están diseñadas para permitir interacciones controladas, como abrirse para recibir datos útiles o cerrarse para bloquear amenazas. Pero, ¿qué sucede si una ventana específicamente mal diseñada permite manipulaciones externas no autorizadas? Aquí es donde entra en juego la vulnerabilidad conocida como SSRF (Server-Side Request Forgery), que podría permitir a un atacante abrir esa ventana mal diseñada y alterar lo que entra o sale, exponiendo el servidor a vistas no autorizadas o incluso a la introducción de elementos dañinos.
En este artículo, te explicamos qué es exactamente SSRF, los diferentes tipos que existen y su impacto en situaciones reales. A través de ejemplos prácticos y casos recientes, entenderás la relevancia de esta vulnerabilidad en el mundo actual y cómo puede afectar a tu infraestructura. Además, compartiremos consejos para que estés protegido ante esta vulnerabilidad.
¿Qué es SSRF (CWE-918)?
En términos generales, la vulnerabilidad de falsificación de solicitudes en el lado del servidor (SSRF), ocurre cuando la aplicación obtiene recursos remotos al no validar de manera adecuada las URLs proporcionadas por el usuario. Lo anterior puede ocasionar la exfiltración y enumeración de información sensible del servidor, incluso cuando estas aplicaciones usan Firewalls, VPNs o ACLs (Lista de Control de Accesos).
Tipos de SSRF
- SSRF Clásico: Se produce cuando un atacante utiliza la aplicación para realizar solicitudes a recursos internos a los que normalmente no debería tener acceso.
- SSRF Blind: Se produce cuando no se recibe directamente en la respuesta información de los recursos internos; sin embargo, se puede inferir la respuesta observando el comportamiento de la aplicación como cambios en los tiempos de respuesta o envío de información a través de una solicitud DNS a un dominio controlado por nosotros.
Ejemplo de la vulnerabilidad SSRF
Podemos imaginar que al interactuar con una aplicación web, existe un apartado donde podemos observar la siguiente URL generada por una solicitud:
Se puede observar que el atributo “href” contiene una URL que está apuntando a un recurso de un subdominio asociado a la aplicación, esta API está instanciada en AWS. Cuando se cambia el valor del atributo “href” por una ruta interna relacionada con los servicios de AWS implementados en la aplicación web, se logra exfiltrar la información almacenada en la metadata de la instancia:
En caso de que se quisiera exfiltrar archivos internos del servidor, se puede usar el protocolo “file:///” como se muestra a continuación:
Código vulnerable
Para los casos anteriores donde se podía obtener información interna del servidor, el ejemplo de código vulnerable se vería de la siguiente manera escrito en ruby:
Código mitigado
El siguiente código establece una lista blanca con la cual compara el valor de la url proporcionada, además se eliminan los fragmentos en la URL (#) que puedan eludir la lista blanca:
Casos impresionantes de la vulnerabilidad SSRF en la actualidad
Hackerone | Server Side Request Forgery (SSRF) via Analytics Reports (2023):
El problema permitía a los atacantes realizar solicitudes internas desde los servidores de aplicaciones aprovechando la falta de desinfección de la salida en un mensaje de error. Mediante la creación de solicitudes maliciosas, un atacante podría haber accedido a los servicios internos de AWS y obtenido credenciales temporales.
Reddit | Blind SSRF to internal services in matrix preview_link API (2023):
El punto final de Matrix Chat en “https://matrix.redditspace.com/_matrix/media/r0/preview_url/?url=*” permitía el SSRF parcialmente ciego a los servicios internos. Los datos que se podían filtrar se limitaban únicamente a los nombres de los servicios y sus IP antes de que se implementara una solución.
GitLab SSRF on project import via the remote_attachment_url on a Note (2020):
El modelo Note tiene un archivo adjunto que es proporcionado por un cargador CarrierWave. Una de las características que proporciona es la posibilidad de descargar y adjuntar un archivo a través de una url. Esto significa que el modelo Note tiene un método “remote_attachment_url=” que puede utilizarse para realizar esta acción. Como este atributo no es eliminado por el AttributeCleaner en la importación del proyecto, se puede establecer en el project.json para una nota y se establecerá cuando se cree la nota, descargando el archivo.
¿Cómo prevenir la vulnerabilidad SSRF?
- Validación de entradas: Validar y filtrar las entradas del usuario que podrían desencadenar un SSRF.
- Listas blancas de direcciones: Especificar explícitamente qué recursos externos están permitidos.
- Open redirect: Deshabilitar las redirecciones HTTP.
- Pruebas de intrusión: Realizar periódicamente pruebas de intrusión para comprobar el estado de la aplicación en términos de ciberseguridad y asegurarse de que no exista o que estén bien implementados los mecanismos para prevenir este tipo de vulnerabilidad.
Conclusiones
La amenaza que representa la vulnerabilidad SSRF en la seguridad de los servidores web no puede ser subestimada. Permitir que un atacante realice peticiones desde el servidor comprometido abre la puerta a diferentes riesgos, entre los que se incluye el acceso no autorizado a sistemas internos y la posible exposición de datos sensibles.
En Hackmetrix, comprendemos profundamente estos riesgos y ofrecemos servicios de hacking ético diseñados para identificar y mitigar vulnerabilidades como SSRF. Nuestro equipo de expertos puede realizar evaluaciones de seguridad exhaustivas para identificar y dar soluciones, fortaleciendo así la postura de seguridad de tu organización.
