SSRF Vulnerability
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio “SSRF with whitelist-based with input filter” de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
ANÁLISIS DE RIESGO
CWE-918 | Server-Side Request Forgery (SSRF) |
IMPACTO | CRÍTICO |
CVSS BASE SCORE | 8.6 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H |
COMPONENTES AFECTADOS | https://LAB-ID.web-security-academy.net/product?productId=number |
EXPLICACIÓN | La vulnerabilidad SSRF en la aplicación web permite que un atacante pueda eludir la lista blanca de seguridad y ejecutar tareas de forma remota, como por ejemplo eliminar usuarios del sistema.. |
RECOMENDACIONES
1) Validar datos de entradas: Se recomienda establecer una correcta validación en los inputs con respecto a los protocolos, redes privadas y resolución dnslookup como se muestra a continuación:
function validUrl (url) { return url && /^(http|https):\/\//.test(url) && !someIpChecker.isPrivate(url) && !someIpChecker.isPrivate(dnsLookup(url)) } |
2) Usar una Whitelist para dominios aceptados: De esta forma se busca evitar que un atacante acceda a una URL, la cual se resuelve en una IP no privada, luego esa solicitud resulta en una redirección a otra IP (o host que se resuelve en una IP) que sea privada.
3) Deshabilitar redirecciones: En caso de ser necesario se recomienda deshabilitar redirecciones para prevenir posibles ataques SSRF.
4) Establecer autenticación en los servicios internos: Un atacante podría utilizar la SSRF para acceder a servicios sin autenticación, por ejemplo servicios en caché y base de datos NoSQL. Por lo tanto, para proteger información sensible y aplicaciones web seguras, es fundamental permitir la autenticación para todos los servicios dentro de su red local.
5) Establecer reglas de IDS: Estas pueden ser de suricata o snort (las cuales son compatibles) para la detección de intrusos en la red. Por ejemplo:
Para alertar sobre consultas DNS:
alert dns any any -> any any (msg:«Consulta DNS a localhost»; dns_query; content:«localhost»; nocase; classtype:policy–violation; sid:1000004; rev:1; )
Para alertar sobre consultas HTTP:
alert tcp any any -> any any (msg:«Intento de Conexión HTTP»; classtype:policy–violation; app–layer–protocol:http; sid:1000005; rev:1; )
6) Bloquear tráfico por cantidad de conexiones: La idea aquí sería desarrollar una regla, mediante iptables, que bloquee cualquier intento de DOS. Por ejemplo, si un host en Internet establece 85 conexiones contra el puerto 80 de nuestro servidor web, seguramente sea un tipo de ataque y podemos bloquearlo con la siguiente regla:
iptables -A INPUT -p tcp -m connlimit –connlimit-above 85 -j REJECT –reject-with tcp-reset |
7) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
8) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se procedió a estudiar la forma en la que se transmiten los datos cuando un usuario ingresa a un artículo.
El botón “Check stock” permite conocer la cantidad de productos disponibles en dicha ciudad. Por tanto, se procedió a utilizar la herramienta Burpsuit para estudiar más a fondo esta transmisión de datos.
Se puede observar que los datos se envían a través del parámetro stockApi cuyo contenido se refiere a una URL y ruta en cuestión. Por tanto, se procedió a realizar un URL-Decode para analizar su contenido y petición.
Teniendo esto en cuenta, se procedió a cambiar la URL agregando el dominio “google.es” dentro de la URL para verificar si existe posibilidad de “Open Redirect”.
Al realizar dicha acción se obtiene un código de estado 500 por parte del servidor. Por tanto se procedió a cambiar el dominio stock.weliketoshop.net por una dirección local (localhost) 127.0.0.1 para verificar una posible falsificación de peticiones del lado del servidor (SSRF Vulnerability).
De esta forma, a través del mensaje de error recibido en Response, se puede observar que la ruta stock.weliketoshop.net debe estar incluida dentro del parámetro stockApi para cualquier petición que se haga desde la misma.
Teniendo esto en cuenta, se procedió a colocar el campo “username” junto con el caracter ‘@’ como delimitador de la siguiente manera:
En este caso, el servidor responde con un código de estado 500, cuyo mensaje refiere a un error en la conexión externa a dicho parámetro. No obstante, se procedió a colocar el caracter ‘#’ (el cual se suele utilizar para separar la URI de un objeto de un identificador de fragmento).
Entonces agregando dicho caracter el mensaje por parte del servidor cambia.
Teniendo esta información, se procedió a agregar la dirección de acceso local 127.0.0.1 y el caracter # con un doble encode %2523 para evitar problemas con el servidor y lograr un bypass contra el filtro SSRF. De modo que la URL quedaría de la siguiente manera:
stockApi=http://127.0.0.1%2523@stock.weliketoshop.net/ |
De esta manera el código de estado por parte del Response es 200 y, a su vez, se pudo eludir la Whitelist comprobando que la aplicación es vulnerable a una falsificación de peticiones del lado del servidor (SSRF Vulnerability).
Por lo tanto, sabiendo que se pueden listar recursos desde dicha URL, se procedió a verificar si es posible acceder al panel de administración mediante la ruta /admin. Cabe mencionar que la existencia de la misma se establece en la introducción de dicho laboratorio.
Entonces se procedió a colocar dicha URL con el respectivo parámetro:
stockApi=http://127.0.0.1%2523@stock.weliketoshop.net/admin |
De esta forma, se puede demostrar que se obtuvo acceso vía «SSRF Vulnerability» al panel de directorio del usuario admin.
Sumado a esto, y como se muestra en la captura anterior, se pudo observar que existe la posibilidad de eliminar usuarios. Un atacante podría llevar a cabo dicha acción a través de las siguientes rutas:
De modo que la sintaxis que usaría sería la siguiente:
stockApi=http://127.0.0.1%2523@stock.weliketoshop.net/admin/delete?username=user |
De esta forma se puede generar un acceso indebido al panel del usuario administrador vía SSRF Vulnerability.
Cabe mencionar que este tipo de ataques también permite que un atacante tenga acceso a otros servicios, y de esta forma, enviar una gran cantidad de solicitudes para ocupar todo su ancho de banda, haciendo que el servicio objetivo no pueda con toda esa carga y termine negando el acceso a usuarios legítimos. Este ataque se conoce como Denegación de Servicio (DoS).
