SSRF - una de las clasicas

Esta semana ha sido un poco jodido, debido a que realice un update a mi kernel en linux y perdí entre tantas cosas mi acceso a mis virtuales, bueno realmente quería realizar un upgrade total a mis sistemas operativos en dual boot, asi que no hay mejor oportunidad que esta para darle de baja a mis SO, el problema es la cantidad de data que tengo almacenada, que ya van 2 dias en migración a otro disco duro.


Bueno al punto, ¿que es SSRF site server remote forgery?, similar a su primo hermano CSRF, permite mediante la modificación de una funcionalidad, mal configurada, manipular los datos entrantes para servir como una especie de pivoteo hacia todo lo que este dispositivo tenga en su "route table".
Para entender gráficamente:

Que es lo que se logra, mediante un servidor vulnerable, permitir desde barrer (sweep ping) los servidores internos, interactuar con ciertos puertos y hasta lograr ataques con xss, sqli, xxe, xpath, etc, siempre y cuando los servidores expuestos, tenga esta vulnerabilidad, interesante no?
veamos:
voy a simular tener un servidor con la vulnerabilidad SSRF:
ip ssrf:192.168.0.102(ssh:10222,http:80)
dentro de su  red tengo conectado otros servidores, que podrian no estas expuestos en un inicio:
ip expuesto:192.168.0.112.
Bien comenzemos:

servidor que permite proyector una imagen dede un sitio remoto, poniendo la ruta de la imagen.

Proxiamos con burp el request y lo modificamos el puerto por un valor 10222.

Ahora para explicar un poco, el puerto 10222, lo configure en el mismo servidor vulnerable(192.168.0.102), el cual corresponde al servicio SSH, veamos el resultado, dice "SSH-2.0-OpenSSH ...", que quiere decir, que es como si mandaramos un netcat al puerto SSH y ahora ponemos nuestra emogi de "ohhh".

Como ven , se esta permitiendo interactuar con otros puertos, veamos ahora interamos usar este servidor para localizar otros servidores, logicamente, recordemos que es un esquema de laboratorio, asi que tendre otro servidor expuesto, como si fuera un servidor en la DMZ.

Lo que hago aca, es cambiar los ultimos digitos de la red 192.168.11x en un rango del 0 a 9, es decir:

recorrer 192.168.0.110, 192.168.0.111 .... 192.168.0.109, tratando de localizar un ojetivo interno.

Si validamos la respuesta del host "192.168.0.110" , dice claramente "no route to host"

Veamos ahora la respuesta con un host activo:

Se nota la diferencia, como ven la diferencia esta siempre en la respuesta, siempre cuando se fuzzea algun parámetro, es importante validar la respuesta.

Ahora tenemos al host, veamos sus puertos abiertos:

Si notan, ahora recorremos los puertos mas conocidos, para mi ejemplo, 22,23,80,443, veamos la respuesta en el puerto 23, dice "connetion refused", pero ahora veamos que paso con un puerto abierto:

Notan que la respuesta no arroja el mismo mensaje, entonces ya tenemos un puerto abierto, perfecto, ahora hagamos reconocimiento a directorios o archivos  mas conocidos en una app web, empezemos:

Como se nota, estamos recorriendo los siguientes directorios o archivos mas conocidos: admin, manager, cgi-bin, veamos la respuesta: claramente vemos un mensaje de cabecera "404" que indica eso que no encuentra el directorio, veamos que pasa si lo encuentra:

Como ven, ahora sale un mensaje "403", de prohibido, el cual nos permite deducir que si existe el directorio pero por reglas en el apache, no es posible el acceso.

Que posible solución podriamos tener, quizas el uso de CORS que permite tener una politica como "same-origen", el uso de listas blancas podria ser tambien funcional.
Bueno por el momento fin del post.