SSRF - Server-Side Request Forgery
PreviousLaboratorio: Divulgación de información en el historial de control de versionesNextLaboratorio: SSRF básico frente a otro sistema back-end
Last updated
Last updated
La falsificación de solicitudes del lado del servidor, es la forma en como nosotros podemos realizar acciones indebidas del lado del servidor de forma que X aplicación actúe de cierta forma o que haga tal acción que nosotros tengamos en mente, ahora bien, uno puede generar un simple ataque tipico del lado del servidor como por ejm: “Hacer que la aplicación acceda a un recurso no autorizado de la misma mediante una solicitud interna del lado del servidor”.
O por ejm con algo un poco más en general de la aplicación: “crear una falsificación del lado del servidor que pueda conectarse a un sitio externo para poder extraer datos, o sitios internos de la aplicación con el fin de poder extraer datos confidenciales, o credenciales de autorización”.
El impacto de un ataque SSRF a menudo puede resultar en poder extraer como mencionaba datos confidenciales, credenciales, y esto puede ser dentro de la misma aplicación vulnerable, el backend de esa aplicación o puede que sea más bien los servicios de terceros los cuales son los vulnerables a los que podemos acceder a los datos no permitidos.
Algo muy importante: El peligro que puede llegar a correr una aplicación vulnerable a SSRF es que un ataque por SSRF puede (dependiendo del contexto) ejecutar comandos arbitrarios.
Y con esto podriamos realizar ataques con comandos que nos permitan acceder a sistemas externos provocando grandes extracciones de datos o perdidas en gran magnitud a la aplicación en cuestión.
A menudos un ataque SSRF puede llegar a explotar el sistema de confianza dentro de la aplicación, me explico, podemos como atacantes poder generar el ataque desde la aplicación como tal siendo la aplicación la que se “auto lesiona” por así decirlo si llegamos a vulnerar cierta parte del servidor de la aplicación.
Ahora bien, puede que no sea la aplicación and That’s fine, podemos ejecutar el SSRF desde un backend vulnerable que este relacionado con la aplicación principal, con ello ese backend puede facilmente ser algun servicio extra externo, o algun 3ero que está presente en la aplicación.
En ese caso teniendo presente esos ataques que está presentes, ahora vamos a tener presente como es cada ataque en especifico.
En un ataque SSRF contra el servidor lo que hacemos es lograr que la aplicación logre hacer una solicitud al servidor de la aplicación a través de su interfaz de red la loopback (127.0.0.1) o localhost, esto por lo general implicaría hacer la solicitud mediante una URL que se mantiene en su estructura de solicitud con el nombre de host de la aplicación (puede ser una IP reservada, o “localhost”127.0.0.1)
Podemos imaginarnos un escenario ejemplar: como una aplicación de compras que nos permite ver la disponibilidad de un producto con “X” tienda, entonces para ello la aplicación tiene que hacer un recurso de API’S REST para acceder a la información de las otras tiendas y mirar para verificar la disponibilidad , esto puede lograrse mediante una URL que accede a un endpoint de la API de esa tienda para mirar la disponibilidad.
Esta solicitud también se ve reflejada a nivel de frontend, cada vez que un usuario verificaría la disponibilidad de un producto en “X” tienda , la solicitud se vería mas o menos así:
Y aqui es donde nosotros podemos venir a efectuar el ataque logrando que en lugar de referenciar una pagina en la IP de la X pagina (tienda) que contiene ese producto, ****podamos hacer una referencia a la loopback del server, así.
Ahi le estamos diciendo que verifique en localhost el subdirectorio /admin y bueno sabemos que este debería tener acceso no autorizado para cualquier tipo de user por lo tanto no cualquier usuario puede acceder solo los autenticados, sin embargo, como hacemos referencia a un sitio legitimos del servidor en este caso la loopback, la solicitud proviene de una ubicación o sitio confiable por ello puede darse acceso las funciones administrativas y en ese caso es como estariamos explotando el sistema de confianza dentro de la misma aplicación como tal de forma “legitima”, SSRF.
Ahora si, con este tema teorico en mente, vamos a repasarlo con la practica en un laboratorio a ver que podemos lograr.
En este caso es lo mismo, la esencia del ataque SSRF se mantiene sin embargo lo que cambia es la victima de ataque, anteriormente nos referiamos a la aplicación en cuestión con su hostname Local considerado como un servicio legitimo que también puede acceder a funciones administrativas como usuarios legalmente autorizados.
Pero en este caso vamos más directamente a aquellos servicios internos de Backend de una aplicación que aunque son de la aplicación, internamente están por separado y los users no pueden acceder directamente, por lo general están en un esquema de Red por a parte (IP privadas) el problema es que por lo general “No siempre” están protegidos por esta topología de red sin embargo esto plantea una seguridad más debil por lo que están separados y por a parte, en terminos de robustez puede que sean más facilmente expuestos a un ataque por la seguridad debil de la topología de red.
Un atacante puede enviar la siguiente solicitud para explotar la vulnerabilidad SSRF y acceder a la interfaz administrativa:
Muchas veces las aplicaciones están alertas contra ataques de falsificaciones del lado del servidor, y por ello a veces no se pueden atacar mediante SSRF porque la app los bloquea, sin embargo hay formas o metodos para poder eludir esa defensa con el fin de poder atacar y obtener resultados.
Sabemos que las listas negras son precisamente las que no nos dejan acceder a recursos como /admin o 127.0.0.1 o .192.168.0.1 , etc. porque ya tienen las medidas defensivas para evitar esos problemas, sin embargo veremos que podemos eludir esas medidas defensivas cambiando las entradas o nuestro ataque. →
Algunas aplicaciones bloquean entradas que contienen nombres de host como 127.0.0.1y localhosto URL confidenciales como /admin. En esta situación, a menudo puedes eludir el filtro utilizando las siguientes técnicas:
Utilice una representación IP alternativa de 127.0.0.1, como: 2130706433, 017700000001, o 127.1
Aquí hay algunas formas alternativas de representar la dirección IP 127.0.0.1:
Decimal:
Notación estándar: 127.0.0.1
Representación alternativa: 2130706433
Octal:
Notación estándar: 127.0.0.1
Representación alternativa: 0177.0.0.1
Hexadecimal:
Notación estándar: 127.0.0.1
Representación alternativa: 0x7F.0.0.1
Registre su propio nombre de dominio que resuelva 127.0.0.1. Puedes utilizar spoofed.burpcollaborator.netpara este propósito.
Ofusque las cadenas bloqueadas mediante codificación de URL o variación de mayúsculas y minúsculas.
Proporcione una URL que usted controle, que redireccione a la URL de destino. Intente utilizar diferentes códigos de redireccionamiento, así como diferentes protocolos para la URL de destino. Por ejemplo, se ha demostrado que cambiar de una URL http:a otra https:durante la redirección evita algunos filtros anti-SSRF.
Vamos a ver un lab, para practicar y estudiar →
Para este contexto hay algunas aplicaciones que usan este metodo para evitar errores o problemas, se trata de validar todo tipo de entradas de la aplicación con valores predeterminados dados por una lista blanca de la aplicación, filtrando la busqueda por valores claves usados al comienzo de las entradas que se den en la aplicación.
Ahora bien, se puede vulnerar este filtro ingresando palabras diferentes, sin embargo toca encontrar las inconsistencias de la URL si la tiene claro por supuesto.
Para este caso, la especificación de URL’s contiene una serie de caracteristicas que probablemente se pueden pasar por alto cuando las URL’s implementan la validación y analisis mediante el Método Ad Hoc:
Con esto sabemos que este es un metodo de analisis y validación muy pobre ya que se hace de forma rapida y no exhaustiva.
Podemos incrustar credenciales antes del nombre del Host, utilizando el “@” por ejm:
https://expected-host:fakepassword@evil-host
Puede utilizar el #carácter para indicar un fragmento de URL. Por ejemplo:
b. https://evil-host#expected-host
Puede aprovechar la jerarquía de nombres DNS para colocar la entrada requerida en un nombre DNS completo que usted controle. Por ejemplo:
c. https://expected-host.evil-host
Puede codificar caracteres en URL para confundir el código de análisis de URL. Esto es particularmente útil si el código que implementa el filtro maneja caracteres codificados en URL de manera diferente que el código que realiza la solicitud HTTP de fondo. También puedes probar con caracteres de doble codificación; algunos servidores decodifican recursivamente la URL de la entrada que reciben, lo que puede generar más discrepancias.
Puedes utilizar combinaciones de estas técnicas juntas.
Vamos a hacer un laboratorio para ver como podemos comprender bien este PoC.
Eso es lo que significa un ataque de redirección abierta, ahora con ello en mente vamos a ver la prueba de concepto y como podemos hacer un ataque por esta vía a una aplicación Web, claro, teniendo en cuenta que podemos eludir las defensas en la URL de una aplicación en concreto.
A veces es posible evitar las defensas que implementa una URL omitiendo los filtros bajo el ataque a la vulnerabilidad de “Redireccionamientos abiertos” (Si la pagina es vulnerable a esa vulnerabilidad por supuesto).
Bajo este escenario podemos suponer que una URL puede estar preparada para ataques de modificación de URL y digamos que lo está, sin embargo si no lo está para redireccionamientos abiertos, nosotros podemos llevar a cabo la redirección de la aplicación a sitios especificos del backend de la aplicación que nosotros como atacantes deseamos.
Esto siempre y cuando la API de la aplicación lleve a cabo las solicitudes HTTP y admita las redirecciones, en ese caso podriamos llevar a cabo nuestra redirección abierta.
Por ejemplo, la aplicación contiene una vulnerabilidad de redirección abierta en la que se muestra la siguiente URL:
devuelve una redirección a:
Podemos aprovechar la vulnerabilidad de redirección abierta para poder omitir el filtro de URL y explotar la vulnerabilidad SSRF de la siguiente manera:
Este Xploit funciona porque la aplicación primero valida que la URL esté bajo el dominio esperado (que es weliketoshop…) y lo está entonces acepta la URL luego viene lo demás de la aplicación que la validación del producto luego de ello pasa a la aplicación que solicita la URL proporcionada, lo que activa la redirección abierta. Sigue la redirección y realiza una solicitud a la URL interna elegida por el atacante.
Veamos un LAB más a fondo para entener la PoC.
Las vulnerabilidades ciegas de SSRF ocurren cuando una aplicación permite que se puedan hacer solicitudes HTTP de backend de la aplicación a una URL en especifico.
Claro, las vulnerabilidades ciegas pueden ser dificiles de explotar y lo son, porque en este caso podemos recibir respuesta del ataque a nivel de backend sin embargo a nivel de frontend no saldría respuesta alguna, aunque es dificil como lo mencionó esta vulnerabilidad puede llegar a permitir la ejecución remota de código en el server u otros componentes de código.
Muchas vulnerabilidades de falsificación de solicitudes del lado del servidor son fáciles de encontrar, porque el tráfico normal de la aplicación involucra parámetros de solicitud que contienen URL completas (Tal vez se refiere al Path). Otros ejemplos de la SSRF son más difíciles de localizar.
A veces las aplicaciones lo que hacen es enviar parcialmente el nombre del host, o parte de una URL en los parametros de la solicitud de la aplicación, sin embargo cuando estos son enviados al servidor son incorporados de forma completa las URLS en el server para terminar la solicitud, Si se reconoce la URL como un host o parte de una URL puede ser muy claro que puede llegar a reflejar una superficie de ataque que podría llegar a ser obvia para un atacante, sin embargo la explotación puede ser limitada porque no se controla toda la URL en su esplendor.
Las aplicaciones también sostienen relaciones con los formatos de datos, las URL’s por lo general antes solían transmitir todo lo que tuvieran de datos en formatos de datos (valga la redundancia) de XML, esto permitía la facil de la inclusión de la URL con los datos, XML ha sido utilizado ampliamente 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 . También podría ser vulnerable a la SSRF a través de XXE. Cubriremos esto con más detalle cuando analicemos las vulnerabilidades de inyección XXE .
Algunas aplicaciones utilizan software de analisis del lado del servidor y en esos analisis detectan las visitas (los visitantes) a menudo que han estado en la pagina, la información obtenida se guarda y por cada user visitante se van tomando un encabezado llamado “Referer”, este encabezado rastrea los enlaces de cada visitante entrante, Ahora bien el software de analisis analiza los encabezados con las URLS que se han obtenido de cada visitante, esto con el fin de analizar el contenido de los sitios de referencia, Como resultado el encabezado “Referer” suele ser una superficie de ataque util para las vulnerabilidades SSRF, las vulnerabilidades en PORTSWIGGER que implementan SSRF con encabezado referer son algunas de las Blind Ssrf.
Con el encabezado referer en resumen podemos decir que es el encabezado el guarda la pagina de la cual se tomo la solicitud para llegar a nuestra pagina actual, entonces en caso tal de que el user le diese al boton regresar tomaría automaticamente la pagina anterior que obtuvo para poder llegar a la pagina actual.
Ejemplo de imagen del encabezado Referer →
Ahora sigamos viendo a profundidad que son las vulnerabilidades SSRF Ciegas:
Testeo de aplicaciones web: https://portswigger.net/burp/application-security-testing
A menudo el impacto que tiene una vulnerabilidad SSRF ciega es un poco menor que el de una SSRF completa ya que la naturaleza misma de una SSRF ciega es unidireccional lo que no permite obtener resultados de datos completamente, solo podemos sacar información a nivel de backend, pero en algunos casos se puede efectuar para obtener ejecución remota de código.
⚠️ Aumentar las pruebas dinámicas con OAST contribuye en gran medida a solucionar este problema.
DAST: Pruebas de caja negra, atacan una boveda sin saber absolutamente nada de la boveda del banco.
SAST: Pruebas de caja blanca, atacamos la boveda teniendo a un profesional que obtuvo los planos de la boveda para encontrar posibles fallos, en este caso analizariamos el codigo de la aplicación en busca de errores.
IAST: Pruebas de caja gris, modifica la aplicación en busca de encontrar errores, esta es la metodología más intrusiva sobre todo para entornos de aplicaciones en produción, se elige OAST por encima por ello se dice que OAST se condira la mejor prueba de seguridad de todas para elegir en una prueba de penetración.
La forma más confiable de detectar vulnerabilidades SSRF ciegas es utilizar técnicas fuera de banda ( OAST ). Esto implica intentar activar una solicitud HTTP a un sistema externo que usted controla y monitorear las interacciones de la red con ese sistema.
La forma más sencilla y eficaz de utilizar técnicas fuera de banda es utilizando Burp Collaborator . Puede utilizar Burp Collaborator para generar nombres de dominio únicos, enviarlos en cargas útiles a la aplicación y monitorear cualquier interacción con esos dominios. Si se observa una solicitud HTTP entrante proveniente de la aplicación, entonces es vulnerable a SSRF.
NotaCuando se prueban vulnerabilidades SSRF, es común observar una búsqueda de DNS para el dominio colaborador proporcionado, pero ninguna solicitud HTTP posterior. Esto suele ocurrir porque la aplicación intentó realizar una solicitud HTTP al dominio, lo que provocó la búsqueda de DNS inicial, pero la solicitud HTTP real fue bloqueada por el filtrado a nivel de red. Es relativamente común que la infraestructura permita el tráfico DNS saliente, ya que es necesario para muchos propósitos, pero bloquee las conexiones HTTP a destinos inesperados.
Vamos a ver un laboratorio de prueba para aprender más de los conceptos que hemos tenido en cuenta.
La simple identificación de una vulnerabilidad SSRF fuera de banda no nos permite explotar la aplicación en si misma, ya que no podemos ver las respuestas directamente del backend para encontrar alguna inconsistencia, sin embargo si podemos aprovechar esa vulnerabilidad para encontrar otros fallos en otras Direcciones IP’s dentro del server de la aplicación o en otros backends del mismo server, ahora bien podemos barrer el espacio de direcciones internas de ese server intentando encontrar huecos o fallos de seguridad conocidos para poder explotarlos, eso con ayuda de las pruebas OAST, claro que encontramos y ejecutamos la vulnerabilidad SSRF fuera de banda.
Es una vuln que permite hacer uso inadecuado de sistemas GNU/Linux que manejan como interprete de comandos en el lenguaje de Script Bash, esta vuln permite la ejecución de comandos de forma remota por una vulnerabilidad o irregularidad en Bash, así que si pensamos un poco los servers corren GNU Linux y a su vez se manejan con bash para todo, así que por ahi podemos generar un vector de ataque.
Los servidores web que usan la interfaz CGI puede dejar una puerta abierta a la vulnerabilidad Shellshock. De hecho, los scripts de CGI pueden llegar a ser muy peligrosos para la seguridad si no son continuamente revisados.
Los usuarios también pueden explotar el bug de seguridad Shellshock a través de OpenSSH, mediante el uso de un comando que modifica la variable ambiente “SSH:ORIGINAL_COMMAND”.
Los clientes DHCP que usan Bash también pueden ser atacados cuando se conectan a una red WiFi o con una IP pública. Los servidores infectados podrían ejecutar un procedimiento o string que infecte al equipo con código malicioso.
En la actualidad hay diversas maneras de saber si se está usando una versión de Bash vulnerable. Para ello es necesario conectarse al servidor por SSH y ejecutar el siguiente comando:
Si no existe vulnerabilidad, no ocurrirá nada, pero en el caso de estar usando una versión de Bash vulnerable, al ejecutar el comando devolverá la palabra “Vulnerable“.
Vamos a ver un lab de practica para entener y ver como podemos explotar este fallo de software en una pagina de laboratorio (Practica):
Eso es todo por este tema de explotación web, nos veremos en proximos temas.
