En esta ocasión, explicaremos qué es la Falsificación de Solicitudes del lado del Servidor (Server-Side Request Forgery), describiremos algunos ejemplos comunes y explicaremos cómo encontrar y explotar varios tipos de vulnerabilidades SSRF.
¿Qué es el ataque Server-Side Request Forgery (SSRF)?
La falsificación de solicitudes del lado del servidor (también conocida como SSRF) es una vulnerabilidad de seguridad web que permite a un atacante inducir a la aplicación del lado del servidor a realizar solicitudes a una ubicación no deseada.
En un ataque SSRF típico, el atacante puede hacer que el servidor establezca una conexión con servicios solo internos dentro de la infraestructura de la organización. En otros casos, pueden obligar al servidor a conectarse a sistemas externos arbitrarios, lo que podría filtrar datos confidenciales, como credenciales de autorización.
¿Cuál es el impacto de los ataques SSRF?
Un ataque SSRF exitoso a menudo puede resultar en acciones no autorizadas o acceso a datos dentro de la organización, ya sea en la propia aplicación vulnerable o en otros sistemas de back-end con los que la aplicación puede comunicarse. En algunas situaciones, la vulnerabilidad SSRF podría permitir que un atacante realice una ejecución de comando arbitraria.
Una explotación de SSRF que provoca conexiones a sistemas externos de terceros puede dar lugar a ataques posteriores maliciosos que parecen originarse en la organización que aloja la aplicación vulnerable.
Ataques SSRF comunes
Los ataques SSRF a menudo aprovechan las relaciones de confianza para escalar un ataque desde la aplicación vulnerable y realizar acciones no autorizadas. Estas relaciones de confianza pueden existir en relación con el propio servidor o con otros sistemas de back-end dentro de la misma organización.
Ataques SSRF contra el propio servidor
En un ataque SSRF contra el propio servidor, el atacante induce a la aplicación a realizar una solicitud HTTP de vuelta al servidor que aloja la aplicación, a través de su interfaz de red loopback. Por lo general, esto implicará proporcionar una URL con un nombre de host como 127.0.0.1 (una dirección IP reservada que apunta al adaptador de bucle invertido) o localhost (un nombre de uso común para el mismo adaptador).
Por ejemplo, considere una aplicación de compras que le permita al usuario ver si un artículo está en stock en una tienda en particular. Para proporcionar la información de existencias, la aplicación debe consultar varias API REST de back-end, según el producto y la tienda en cuestión. La función se implementa al pasar la URL al punto final de la API de back-end relevante a través de una solicitud HTTP de front-end. Entonces, cuando un usuario ve el estado del stock de un artículo, su navegador hace una solicitud como esta:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
Esto hace que el servidor realice una solicitud a la URL especificada, recupere el estado del inventario y se lo devuelva al usuario.
En esta situación, un atacante puede modificar la solicitud para especificar una URL local para el propio servidor. Por ejemplo:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin
Necesita una herramienta que analice vulnerabilidades en tus sitios o aplicaciones web?, ponte en contacto con nosotros para ayudarte, contamos con las mejores herramientas como Burp Suite, Veracode, Fortify, Acunetix, Invicti y mas.
Contacto..
Aquí, el servidor buscará el contenido de la URL /admin y se lo devolverá al usuario.
Ahora, por supuesto, el atacante podría simplemente visitar la URL/admin directamente. Pero la funcionalidad administrativa normalmente solo es accesible para usuarios autenticados adecuados. Entonces, un atacante que simplemente visite la URL directamente no verá nada de interés. Sin embargo, cuando la solicitud a la URL /admin proviene de la propia máquina local, se omiten los controles de acceso normales. La aplicación otorga acceso completo a la funcionalidad administrativa, porque la solicitud parece originarse en una ubicación confiable.
¿Por qué las aplicaciones se comportan de esta manera y confían implícitamente en las solicitudes que provienen de la máquina local? Esto puede surgir por varias razones:
- La verificación de control de acceso podría implementarse en un componente diferente que se encuentra frente al servidor de aplicaciones. Cuando se vuelve a establecer una conexión con el propio servidor, se omite la comprobación.
- Para fines de recuperación ante desastres, la aplicación puede permitir el acceso administrativo sin iniciar sesión a cualquier usuario que provenga de la máquina local. Esto proporciona una forma para que un administrador recupere el sistema en caso de que pierda sus credenciales. La suposición aquí es que solo un usuario de plena confianza vendría directamente del propio servidor.
- La interfaz administrativa puede estar escuchando en un número de puerto diferente al de la aplicación principal y, por lo tanto, es posible que los usuarios no puedan acceder a ella directamente.
Este tipo de relaciones de confianza, donde las solicitudes que se originan en la máquina local se manejan de manera diferente a las solicitudes ordinarias, es a menudo lo que convierte a SSRF en una vulnerabilidad crítica.
Ataques SSRF contra otros sistemas back-end
Otro tipo de relación de confianza que a menudo surge con la falsificación de solicitudes del lado del servidor es cuando el servidor de aplicaciones puede interactuar con otros sistemas de back-end a los que los usuarios no pueden acceder directamente. Estos sistemas a menudo tienen direcciones IP privadas no enrutables. Dado que los sistemas back-end normalmente están protegidos por la topología de la red, a menudo tienen una postura de seguridad más débil. En muchos casos, los sistemas back-end internos contienen funciones confidenciales a las que cualquier persona que pueda interactuar con los sistemas puede acceder sin autenticación.
En el ejemplo anterior, supongamos que hay una interfaz administrativa en la URL de back-end https://192.168.0.68/admin. Aquí, un atacante puede explotar la vulnerabilidad SSRF para acceder a la interfaz administrativa enviando la siguiente solicitud:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin
Eludir las defensas comunes de la SSRF
Es común ver aplicaciones que contienen comportamiento SSRF junto con defensas destinadas a prevenir la explotación maliciosa. A menudo, estas defensas se pueden eludir.
SSRF con filtros de entrada basados en listas negras
Algunas aplicaciones bloquean la entrada que contiene nombres de host como 127.0.0.1 y localhost, o direcciones URL confidenciales como /admin. En esta situación, a menudo puede eludir el filtro utilizando varias técnicas:
- Usar una representación IP alternativa de
127.0.0.1, como2130706433,017700000001o127.1. - Registrando su propio nombre de dominio que se resuelve en
127.0.0.1. Puede utilizarspoofed.burpcollaborator.netpara este propósito. - Ofuscación de cadenas bloqueadas mediante codificación de URL o variación de mayúsculas y minúsculas.
SSRF con filtros de entrada basados en listas blancas
Algunas aplicaciones solo permiten entradas que coincidan, comiencen o contengan una lista blanca de valores permitidos. En esta situación, a veces puede eludir el filtro aprovechando las incoherencias en el análisis de URL.
La especificación de URL contiene una serie de características que pueden pasarse por alto al implementar el análisis ad hoc y la validación de URL:
Puede incrustar credenciales en una URL antes del nombre de host, usando el
@carácter. Por ejemplo:https://expected-host@evil-hostPuede utilizar el
#carácter para indicar un fragmento de URL. Por ejemplo:https://evil-host#expected-hostPuede aprovechar la jerarquía de nombres de DNS para colocar la entrada requerida en un nombre de DNS completamente calificado que usted controla. Por ejemplo:
https://expected-host.evil-host- Puede codificar caracteres de URL para confundir el código de análisis de URL. Esto es particularmente útil si el código que implementa el filtro maneja los caracteres codificados en URL de manera diferente al código que realiza la solicitud HTTP de back-end. Tenga en cuenta que también puede probar la doble codificación de caracteres; algunos servidores decodifican URL recursivamente la entrada que reciben, lo que puede generar más discrepancias.
- Puede usar combinaciones de estas técnicas juntas.
Omitir los filtros SSRF a través de la redirección abierta
A veces es posible eludir cualquier tipo de defensa basada en filtros explotando una vulnerabilidad de redirección abierta.
En el ejemplo anterior de SSRF, suponga que la URL enviada por el usuario está estrictamente validada para evitar la explotación malintencionada del comportamiento de SSRF. Sin embargo, la aplicación cuyas URL están permitidas contiene una vulnerabilidad de redirección abierta. Siempre que la API utilizada para realizar la solicitud HTTP de back-end admita redirecciones, puede construir una URL que satisfaga el filtro y resulte en una solicitud redirigida al objetivo de back-end deseado.
Por ejemplo, supongamos que la aplicación contiene una vulnerabilidad de redirección abierta en la que la siguiente URL:
/product/nextProduct?currentProductId=6&path=http://evil-user.net
devuelve una redirección a:
http://evil-user.net
Puede aprovechar la vulnerabilidad de redirección abierta para omitir el filtro de URL y explotar la vulnerabilidad SSRF de la siguiente manera:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
Este exploit SSRF funciona porque la aplicación primero valida que la URL stockAPI proporcionada está en un dominio permitido, y lo está. Luego, la aplicación solicita la URL proporcionada, lo que activa la redirección abierta. Sigue la redirección y realiza una solicitud a la URL interna que elija el atacante.
Vulnerabilidades ciegas de SSRF
Las vulnerabilidades ciegas de SSRF surgen cuando se puede inducir a una aplicación para que emita una solicitud HTTP de back-end a una URL proporcionada, pero la respuesta de la solicitud de back-end no se devuelve en la respuesta de front-end de la aplicación.
Blind SSRF generalmente es más difícil de explotar, pero a veces puede conducir a la ejecución remota completa del código en el servidor u otros componentes de back-end.
Encontrar una superficie de ataque oculta para las vulnerabilidades de SSRF
Muchas vulnerabilidades de falsificación de solicitudes del lado del servidor son relativamente fáciles de detectar, porque el tráfico normal de la aplicación involucra parámetros de solicitud que contienen URL completas. Otros ejemplos de SSRF son más difíciles de localizar.
URL parciales en solicitudes
A veces, una aplicación coloca solo un nombre de host o parte de una ruta de URL en los parámetros de solicitud. Luego, el valor enviado se incorpora del lado del servidor en una URL completa que se solicita. Si el valor se reconoce fácilmente como un nombre de host o una ruta de URL, entonces la superficie de ataque potencial podría ser obvia. Sin embargo, la capacidad de explotación como SSRF completo puede ser limitada, ya que no controla la URL completa que se solicita.
URL dentro de formatos de datos
Algunas aplicaciones transmiten datos en formatos cuya especificación permite la inclusión de direcciones URL que el analizador de datos podría solicitar para el formato. Un claro ejemplo de esto es el formato de datos XML, que ha sido ampliamente utilizado en aplicaciones web para transmitir datos estructurados del cliente al servidor. Cuando una aplicación acepta datos en formato XML y los analiza, puede ser vulnerable a la inyección XXE y, a su vez, ser vulnerable a SSRF a través de XXE. Cubriremos esto con más detalle cuando veamos las vulnerabilidades de inyección XXE .
SSRF a través del encabezado Referer
Algunas aplicaciones emplean software de análisis del lado del servidor que rastrea a los visitantes. Este software a menudo registra el encabezado Referer en las solicitudes, ya que esto es de particular interés para rastrear enlaces entrantes. A menudo, el software de análisis visitará cualquier URL de terceros que aparezca en el encabezado de referencia. Esto se suele hacer para analizar el contenido de los sitios de referencia, incluido el texto de anclaje que se utiliza en los enlaces entrantes. Como resultado, el encabezado Referer a menudo representa una superficie de ataque fructífera para las vulnerabilidades de SSRF. Consulte Vulnerabilidades ciegas de SSRF para ver ejemplos de vulnerabilidades relacionadas con el encabezado Referer.
Prevención de Ataques Falsificación de Solicitudes del Lado del Servidor (conocida como SSRF)
Las listas negras simples y las expresiones regulares aplicadas a la entrada del usuario son un mal enfoque para mitigar SSRF. En general, las listas negras son un medio deficiente de control de seguridad. Los atacantes siempre encontrarán métodos para eludirlos. En este caso, un atacante puede usar una redirección HTTP, un servicio DNS comodín como xip.io o incluso una codificación IP alternativa .
Listas blancas y resolución de DNS
La forma más sólida de evitar la falsificación de solicitudes del lado del servidor (SSRF) es incluir en la lista blanca el nombre de host (nombre DNS) o la dirección IP a la que su aplicación necesita acceder. Si un enfoque de lista blanca no le conviene y debe confiar en una lista negra, es importante validar la entrada del usuario correctamente. Por ejemplo, no permita solicitudes a puntos finales con direcciones IP privadas (no enrutables) (detallado en RFC 1918 ).
Sin embargo, en el caso de una lista negra, la mitigación correcta a adoptar variará de una aplicación a otra. En otras palabras, no existe una solución universal para SSRF porque depende en gran medida de la funcionalidad de la aplicación y los requisitos comerciales.
Manejo de respuestas
Para evitar que los datos de respuesta se filtren al atacante, debe asegurarse de que la respuesta recibida sea la esperada. Bajo ninguna circunstancia se debe entregar al cliente el cuerpo de respuesta sin procesar de la solicitud enviada por el servidor.
Deshabilitar esquemas de URL no utilizados
Si su aplicación solo usa HTTP o HTTPS para realizar solicitudes, permita solo estos esquemas de URL. Si deshabilita los esquemas de URL no utilizados, el atacante no podrá usar la aplicación web para realizar solicitudes utilizando esquemas potencialmente peligrosos como file:/// , dict:// , ftp:// y gopher:// .
Autenticación en servicios internos
De forma predeterminada, los servicios como Memcached, Redis, Elasticsearch y MongoDB no requieren autenticación. Un atacante puede usar vulnerabilidades de falsificación de solicitudes del lado del servidor para acceder a algunos de estos servicios sin ninguna autenticación. Por lo tanto, para proteger su información confidencial y garantizar la seguridad de las aplicaciones web, es mejor habilitar la autenticación siempre que sea posible, incluso para los servicios en la red local.
NORTH NETWORKS es Distribuidor Oficial y brinda licencias nuevas, renovaciones y servicios profesionales de las herramientas DAST, SAST y PenTest mas importantes.
Pongase en contacto y le ayudaremos a analizar sus requerimientos para poder brindarle la herramienta que mejor se ajuste a sus requerimientos.
Si te ha gustado, ¡compártelo con tus amigos!
