Issuu on Google+

Soluci贸n reto SEC-OS 1 por @dantemc hellobsang24@gmail.com


Obtención de información Primeramente se descarga la máquina del link proporcionado por 4v4t4r: http://www.sec-track.com/reto-secos-1-paulwebsec-nivel-medio-ctf-web-premio-libro-hacking-yseguridad-en-internet La monto en virtualbox, configurando la red como solo red interna, al bootear solo se observa esto:

Primera impresión de la MV

Lo cual no es de mucha información, previamente sé que la IP asignada está entre 192.168.56.100 y 192.168.56.254 ( por mi configuración de Vbox), así que lanzo un nmap en busca de alguna máquina en el segmento 100 a 110. (primero un ping y luego un scan normal)

Se encuentra un host activo


Puertos abiertos del host activo

Se observa la IP 192.168.56.101 y los puertos 22 y 8081 abiertos. Procedo a entrar mediante Firefox por el puerto 8081 se observa una aplicación en la cual es posible crear un usuario, iniciar sesión, leer y enviar mensajes, se observan los usuarios ( spiderman es el admin), y una opción para cambiar la contraseña. Al hacer uso de la opción para cambio de contraseña se observa que no es necesario conocer la contraseña actual y que además no se envía ningún token para la validación de la petición.

Datos enviados por post al efectuar el cambio de contraseña

Cross Site Request Forgery El Cross Site Request Forgery (CSRF) es una vulnerabilidad que permite suplantar peticiones legales hacia la aplicación, haciendo que el servidor crea que quien realiza la petición es el usuario legítimo. Esto se realiza haciendo que un usuario inocente entre a sitios con contenido malicioso.


Figura tomada de la presentación de Paul_Sec en Bsides London 2014 sobre la herramienta CSRFT

Averiguando sobre el “hint” dado por 4v4t4r encontré las slides del creador de la herramienta CSRFT ( Cross Site Request Forgery Tool) y aunque el exploit es fácil de realizar a mano, me propuse aprender a usar la herramienta. El entendimiento del montaje y configuración depende de cada uno. Haciendo uso de esta herramienta, más la opción de enviar mensajes disponible en la aplicación 192.168.56.101:8081, realizo la configuración adecuada ( no fue fácil, más fácil a mano...), y me dispongo a cambiar el password del administrador.


Realizando el ataque:

Acceso de 192.168.56.101 al servidor atacante, haciendo uso de CSRFT

Veo que hay una víctima de CSRFT, me dispongo a entrar con el usuario spiderman y funcionó. Veo que las opciones en la aplicación parecen ser las mismas, sin embargo en la parte de mensajes se puede observar lo siguiente:

El usuario pirate ya conoce el password de Spiderman (no de la aplicación) y se lo hace saber sin vergüenza.


Así que pruebo estas credenciales (spiderman:CrazyPassword!) mediante SSH ¡y ya estamos adentro!

Acceso a la consola SSH mediante las credenciales obtenidas en la aplicación web

Sin embargo vemos que no tenemos muchos privilegios, además de ser un sistema relativamente actualizado, sin exploits públicos hasta hoy. Luego de mucho indagar los procesos veo un proceso que me llama la atención:

resultado parcial del comando “ps aux | grep root”

Alguien realizó un sudo sobre un archivo que puedo acceder, concretamente internalServer.js, me dispongo a leer el archivo y encuentro lo siguiente:


Una de las funciones del archivo internalServer.js

La aplicación ejecuta un ping. Esto conlleva otra vulnerabilidad...

Ejecución de comandos y elevación de privilegios. El código de la imagen anterior es vulnerable puesto que no hay una validación del comando, es decir: En una consola normal es posible ejecutar dos comandos o más haciendo uso de los pipes (|), un ejemplo de esto es cuando realizamos un cat seguido de un pipe y grep.

Realización de un cat pipe grep, para obtener las líneas que contengan palabras que inicien por l

Así, si realizamos un ping 1 | whoami, ejecutariamos el comando whoami luego de que el comando ping 1 se ejecute (correcta o incorrectamente) Al final del código del archivo InternalServer.js nos dice que el servidor corre en el puerto 9000, esto lo comprobamos con netcat ( viejito pero bueno):


Confirmación del servidor en el puerto 9000

El siguiente paso es lograr acceso a la aplicación, esto lo realizaremos haciendo uso de w3m. W3m es un navegador web por consola, al entrar a la dirección http://127.0.0.1:9000 esto es lo que observamos:

Acceso a la aplicación mediante w3m

Ponemos en práctica la teoría de la ejecución de comandos (ping 1 | woami):

Aplicación corriendo a través del sudo, como root.

Probada la teoría procedemos a realizar un cat sobre el archivo /root/flag.txt


et voilĂ , tenemos acceso a la flag.


Anexos: •

Código del archivo form.json:

{ "audit": { "name": "CSRF", "scenario": [ { "attack": [ { "method": "POST", "type_attack": "special_value", "form": "../exploits/form.html" } ] } ] } }

Código del archivo form.html:

<html> <title>CSRF By dantemc</title> <body> <form class="form-signin" action="http://127.0.0.1:8081/change-password" method="POST"> <input type="text" name="username" value="pirate"> <input type="password" name="password" value="dantemc"> </form> </body> </html>


Agradecimientos: A los organizadores de la actividad, a los creadores de la herramienta y a todos en general por brindar estos espacios lúdicos. A @killr00t que tras tanto insistir me hizo participar en una de estas cosas (y me gustó :P). Bibliografía:

Cross Site Request Forgery https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

Slides bsides 2014 london http://paulsec.github.io/bsides-london-2014/#/4

CSRFT https://github.com/PaulSec/CSRFT

Ejecución de comandos http://www.securitygeeks.net/2013/05/command-execution-tutorial-dvwa-low.html


Solucionario Reto SecOS 1 por @dantemc