🥂Laboratorio: SSRF básico contra el servidor local
Falsificación de solicitudes del lado del servidor (SSRF)Las vulnerabilidades SSRF permiten a un atacante desencadenar solicitudes maliciosas de servidor a servidor a URL no deseadas. Como es probable que el servidor que emite la solicitud tenga una sólida relación de confianza con otros sistemas de la red, el atacante puede abusar de este comportamiento para acceder a datos, funciones y servicios que no deben estar expuestos a usuarios externos.
Ataques SSRF contra el servidor
En un ataque SSRF contra el servidor, el atacante hace que la aplicación realice una solicitud HTTP al servidor que aloja la aplicación, a través de su interfaz de red loopback. Por lo general, esto implica 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, imagine una aplicación de compras que permite al usuario ver si un artículo está disponible en una tienda en particular. Para proporcionar información sobre las acciones, la aplicación debe consultar varias API REST de back-end. Para ello, pasa la URL al punto final API de back-end correspondiente a través de una solicitud HTTP de front-end. Cuando un usuario ve el estado del stock de un artículo, su navegador realiza la siguiente solicitud:
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 stock y lo devuelva al usuario.
En este ejemplo, un atacante puede modificar la solicitud para especificar una URL local al servidor:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/admin
El servidor recupera el contenido de la /adminURL y se lo devuelve al usuario.
Un atacante puede visitar la /adminURL, pero normalmente solo los usuarios autenticados pueden acceder a la funcionalidad administrativa. Esto significa que un atacante no verá nada de interés. Sin embargo, si la solicitud a la /adminURL proviene de la 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.
Ataques SSRF contra el servidor - Continuación
¿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 servidor, se omite la verificació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 manera para que un administrador recupere el sistema si pierde sus credenciales. Esto supone que sólo un usuario de plena confianza procedería directamente del servidor.
La interfaz administrativa puede escuchar en un número de puerto diferente al de la aplicación principal y 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, a menudo convierten a SSRF en una vulnerabilidad crítica.
Laboratorio: SSRF básico contra el servidor local
APRENDIZ
LABORATORIONo resuelto
Este laboratorio tiene una función de verificación de existencias que obtiene datos de un sistema interno.
Para resolver el laboratorio, cambie la URL de verificación de existencias para acceder a la interfaz de administración http://localhost/adminy elimine el usuario carlos.