Cómo funciona la vulnerabilidad SSRF

 

Bienvenidos a un nuevo post en Byte Mind, como ya vimos anteriormente la explicación de la vulnerabilidad Cross-Site Request Forgery (CSRF), es este caso vamos a explicar la vulnerabilidad de Server-Side Request Forgery (SSRF), que consiste en engañar al servidor para que haga peticiones a otro dominio para el cual no fue diseñada en un principio.

Veremos ahora en detalle de qué se trata, cómo funciona, algunos ejemplos, y por supuesto, como es posible evitar la misma. 

 

¿Qué es Server-Side Request Forgery?

El ataque de Server-Side Request Forgery (SSRF) o en español, Falsificación de Solicitudes del Lado del Servidro, es una vulnerabilidad de seguridad web debido a que permite a un atacante inducir, a la aplicación del lado del servidor, a realizar solicitudes HTTP a un dominio arbitrario de la elección del atacante.

Esto permite al atacante realizar conexiones con servicios de la infraestructura interna de la organización, en la cual se aloja el portal web, y ante la posibilidad de conectarse a sistemas externos, lo que podría provocar en robo de información sensible como pueden ser credenciales de autorización.

 

 

Cómo funciona un ataque de SSRF

Cuando una aplicación hace una llamada a una URl, por ejemplo una API, el atacante podría editar la consulta para que la llamada se haga a una dirección diferente para la cual está diseñada.

De esta forma, se podría por ejemplo observar un panel de administración sin autorización, ver archivos sensibles del sistema, o incluso realizar un escaneo de puertos dentro de la red interna de ese servidor.

 

 

Por poner un ejemplo, supongamos que tenemos una aplicación web en aws que consulta si un producto tiene stock de la siguiente forma:

En este caso, un atacante, podría modificar la consulta para que en lugar de pedir los datos de un producto, pida los metadatos de la API para obtener datos de los usuarios

Aunque en un principio, la API, no tenga acceso a consultas externas, la petición se hace desde el propio servidor, por lo que va a responder como si tuviese autorizada la misma.

Y, una vez obtenidos los diferentes roles, puede consultar a un en concreto

El cual le respondería con las credenciales del mismo

De esta forma, dado el ejemplo, el atacante obtendría acceso a las credenciales de AWS y con ello ya podría obtener el control.

 

 

Cuáles son los riesgos

Como ya se a visto en el anterior ejemplo, un ataque exitoso puede provocar que se realicen acciones que no están autorizadas, ya sea en la propia aplicación vulnerable o en otros sistemas de la red interna, en algunas ocasiones sería posible además que un atacante ejecutase un comando arbitrario.

Para recapitular, vamos a ver en un listado los posibles riesgos de este tipo de ataques:

• Robo de datos sensibles de la organización
• Realización de peticiones a servicios internos con el fin de obtener información de los servicios existententes en la red interna
• Ejecución de código arbitrario de forma remota dentro del sistema
• Escalado de privilegios dentro del sistema y la organización

 

 

Tipos de ataques SSRF

Los ataques SSRF, generalmente, aprovechan las relaciones de confianza para poder escalar un ataque desde una aplicación vulnerable y realizar acciones que no están autorizadas.

Estas relaciones de confianza pueden ser de dos tipos: relación con el mismo servidor o en relación con otros sistemas de backend dentro de la misma organización.

 

Ataques contra el propio servidor

En un ataque SSRF contra el propio servidor, el atacante, induce a la aplicación a realizar una solicitud HTTP al servidor que aloja dicha aplicación. Por lo general, esto implicará proporcionar una URL con un nombre de host como 127.0.0.1 o localhost.

Vamos a verlo con un ejemplo, siguiendo con el ejemplo del stock visto anteriormente, imaginemos una aplicación de compras en la cual se permite al usuario comprobar si el artículo dispone de stock en una tienda en particular. Para obtener dicha información, la aplicación deberá realizar varias consultas API REST de backend en función del producto y la tienda en cuestión.

La función se implementará pasando una URL al punto final de la API de backend relevante a través de una solicitud HTTP, por lo que cuando el usuario vea el estado del stock de un artículo su navegador hará una petición similar a la siguiente:

Esto provocará que el servidor haga una solicitud a una URL concreta, recupere el estado de stock y le devuelva los datos al usuario.

En la situación mencionada, un atacante podría modificar la solicitud para indicar una URL local del servidor, por ejemplo:

En este ejemplo, el servidor, buscará el contenido de la url /admin y le devolverá el contenido al usuario

Ahora, si el atacante intenta visitar la url /admin de forma directa, no conseguirá nada, debido a que la dirección de administración suele estar disponible sólo para los usuarios autenticados en el sistema y con los permisos adecuados, pero si lo realiza a través de la máquina local, se omiten los controles de acceso habituales, dando acceso completo a la funcionalidad administrativa, ya que la solicitud ha sido originada desde una ubicación “confiable”.

 

Ataques contra otros servidores de backend

Otro tipo de relación de confianza que surge a menudo con SSRF es cuando el servidor de aplicaciones es capaz de interactuar con otros sistemas a los que los usuarios no pueden acceder directamente. Estos disponen de direcciones IP privadas no enrutables normalmente. Además, debido a que suelen estar protegidos por la topología de red, a menudo tienen una postura de seguridad más débil, por lo que también los hace más inseguros ante este tipo de ataques.

Por ejemplo, supongamos que en el anterior ejemplo la aplicación dispone de una interfaz de administración en la url http://192.168.4.62/admin, aqui el atacante podría aprovechar la vulnerabilidad SSRF para aceder a la interfaz administrativo enviando la siguiente solicitud:

 

Cómo eludir las defensas 

Es bastante común ver aplicaciones que contienen comportamientos SSRF junto con defensas destinadas a prevenir la explotación de las mismas, aunque, a menudo, estas defensas pueden eludirse por medio de diferentes técnicas.

 

SSRF con filtros de entrada basados en blacklists

Algunas aplicaciones bloquean el uso de los nombres de host localhost o 127.0.0.1, o el acceso a urls sensibles como /admin. En estas situaciones es posible, en algunas ocasiones, eludir el filtro utilizando varias técnicas:

• El uso de representaciones ofuscadas de 127.0.0.1 como puede ser 2130706433 o 0x7f000001
• Registrar su propio nombre de dominio que resuelta la dirección de 127.0.0.1
• Ofuscar strings bloqueados mediante la codificación de la URL o la variación del uso de mayúsculas y minúsculas

 

SSRF con filtros de entrada basados en whitelists

Algunas aplicaciones sólo permitirán entradas que coincidan con las reglas definidas. En estas situaciones, a veces, es posible eludir el filtro aprovechando inconsistencias en el análsis de la URL.

La especición de URL contiene una serie de características que pueden pasarse por alto al hacer el análisis y validación:

• Es posible incrustar credenciales en una url antes del nombre del host mediante el carácter @, por ejemplo http://expected-host@evil-host
• Uso del carácter # para indicar un fragmento de url, por ejemplo http://evil-host#expected-host
• Aprovechar la jerarquía de nombres DNS para colocar la entrada requerida en un nombre de DNS que controla, por ejemplo http://expected-host.evil-host
• Codificación de caracteres de url para confundir el código de análisis. Esto es útil si el código que implementa el filtro maneja los caracteres codificados de forma distinta al código que realizar la solicitud HTTP de backend

Además de las opciones descritas, en ocasiones es posible saltar los filtros mediante el uso de varias de las técnicas indicadas.

 

Bypass filtros SSRF con redirecciones abiertas

En otras ocasiones es posible eludir las defensas basadas enfiltros aprovechando una vulnerabilidad de redirección abierta. 

Si observamos el ejemplo descrito antes, supongamos que la url está validada de forma muy estricta para evitar cualquier posible explotación de esta vulnerabilidad. Sin embargo, la aplicación contiene una vulnerabilidad de redirección abierta, en la que realiza una redirección al terminar de realizar una solicitud.

Supongamos que tenemos la siguiente petición:

En este caso el exploit funcionaría porque la aplicación validará la primera url que sea correcta y, una vez verificada, la app solicitará la URL proporcionada que activará la redirección abierta, consiguiendo con ello que el atacante se salte el filtro y acceda a la ip interna y con ello al panel de administrador.

 

 

Cómo protegerse ante ataques SSRF

Hemos visto qué es, como funciona y diferentes formas de llevar a cabo de forma satisfactoria la explotación de esta vulnerabilidad, pero como podemos protegernos de la misma.

Para ello se deberían de llevar a cabo ciertas tareas como:

• Realizar una verificación del control de acceso en un componente distinto al servidor de aplicaciones, evitando que se omita la comprobación al establecer la conexión.
• No permitir el acceso administrativo sin iniciar sesión o sin verificar los permisos del usuario
• Modificar el acceso a datos sensibles para que escuche por ejemplo en otro puerto, o sólo sea accesible desde ciertas ubicaciones concretas para limitar el área de acción
• Deshabilitar el uso de redirecciones
• Utilizar una whitelist con los dominios y direcciones permitidas

Bueno y, además de las protecciones indicadas, nunca está de más realizar una auditoría, la que entre otras cosas, podría ayudar a identificar este tipo de problemas antes de que ocurra el desastre.

 

 

Y esto es todo por ahora, espero que les haya sido de utilidad y como siempre, si tienen alguna duda, aportación o simplemente quieren dar su opinión pueden hacerlo desde la sección de comentarios.