shuffle4. Server Side Request Forgery

Server Side Request Forgery (SSRF)

Server Side Request Forgery (SSRF). Es un tipo de vulnerabilidad que permite a un atacante realizar peticiones desde la aplicación hacia una localización involuntaria. En un ataque típico de SSRF, el atacante ocasiona que el servidor realice peticiones a sí mismo, logrando de esa forma realizar peticiones que en un principio están limitadas a ser creadas de forma interna por los mismos servicios de la infraestructura de la organización. En otros casos, son capaces de forzar al servidor a conectarse de forma arbitraria a sistemas externos, lo que potencialmente termine en filtración de información sensible como credenciales de autorización o revelar el comportamiento privado del sitio para su corrupción.

Como funciona un SSRF

En el momento que el servidor realiza un llamada a una URL, como podría ser una API, un atacante pude editar la petición para cambiar la dirección de destino.

  • Ataque SSRF contra el mismo servidor

    • En un ataque SSRF contra el servidor, el atacante modifica el comportamiento del servidor al momento de realizar una petición o llamada a una URL, sustituyendo el URL con su interfaz de red loopback. Lo que regularmente involucra al hostname 127.0.0.1, una dirección IP reservada para el adaptador loopback o el localhost un nombre común para el adaptador.

    • Por ejemplo, imagina una tienda en linea que permite al usuario ver cuantos productos quedan en el inventario de una tienda particular. Para proporcionar la información. la aplicación debe de realizar multiples peticiones a las back-end REST APIs. Lo realiza pasando el URL a una relevante back-end API endpoint por medio de la petición HTTP front-end. Cuando un usuario ve el inventario de un producto, el buscador realiza la siguiente petición: 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 La petición hace que el servidor cree una nueva consulta al URL especificado, retornando el estado del inventario y finalmente redirigiendo el resultado al usuario. En este escenario, un atacante puede modificar la petición para especificar un URL local a el servidor: POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/admin El servidor retorna el contenido del directorio /admin al usuario. Dicho directorio podría ser visible para cualquier usuario, sin garantizar autorización o simplemente estar restringido a servicios locales y al hacer la petición desde el mismo servidor y ya no desde nuestro buscador como usuario, podemos evadir dichas restricciones.

  • Ataque SSRF contra otro sistema back-end

    • En algunos casos, el servidor tiene la habilidad de interactuar con otros sistemas back-end que en un inicio el usuario no es capaz de interactuar directamente. Estos sistemas pueden ofrecen un acceso a direcciones IP no accesibles desde fuera del sistema local.

    • En ocasiones los servidores back-end son protegidos por la misma topología de red al no estar dirigidos a una salida directa a internet, así que ofrecen una postura de seguridad más débil. En varios casos, los sistemas back-end contienen información sensible y funcionalidades sensibles que pueden ser accedidas sin autenticación por cualquiera que pueda interactuar con el sistema.

    • En el ejemplo anterior, suponiendo que exista un panel administrativo en la dirección https://192.168.0.68/admin. Un atacante puede mandar la siguiente petición para explotar la vulnerabilidad SSRF y acceder al panel de administración POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://192.168.0.68/admin

References

https://portswigger.net/web-security/learning-paths/server-side-vulnerabilities-apprentice/ssrf-apprentice/ssrf/what-is-ssrfarrow-up-right

Last updated