Solucionario Reto: SecOS-1 (@PaulWebSec) Autor @itsecurityco

Solucionario Reto: SecOS-1 (@PaulWebSec) Autor @itsecurityco 5/25/2014

Descripción del reto

Reto: SecOS-1 (@PaulWebSec), nivel medio #CTF #Web + Premio: Libro Hacking y seguridad en internet SecOS-1 es un nuevo reto (que promete ser consecutivo, así que deben ir guardando las banderas para futuras publicaciones) de seguridad en aplicaciones web, que espero además de ser solucionado en este desafío, también sea utilizado como material académico de laboratorios y reuniones de los diferentes HackLabs. Paul A. (PaulSec) nos comenta que la idea del reto nació cuando desarrollaba algunas herramientas de seguridad. Específicamente CSRFT, que precisamente presentó hace poco en Bsides London. El reto consiste en una aplicación Web vulnerable. En la cual reside el famoso archivo /root/flag.txt Obviamente nuestro objetivo será el de acceder a éste :D. Aunque la máquina está desarrollada para ser ejecutada en Vbox siempre prefiero utilizar VMWare (preferencia personal) Así que está garantizado que funcione en ambas soluciones de virtualización. Tan solo abrir la máquina con VBox (en mi caso crear nueva máquina con características avanzadas para seleccionar el archivo SecOS-1.vmdk y al final decidí convertir a formato moderno). La máquina ya funciona perfecto con DHCP así que de manera automática recibirá una dirección

IP. Utilicé el modo NAT y funcionó perfectamente. Tan solo basta realizar un scan ping en el segmento en que se tenga la configuración NAT y desde allí podremos identificar la nueva máquina en la red. Gracias a la Corporación El HackLab premiaré al mejor solucionario con el libro Hacking y seguridad en internet de García-Morán, Antonio Ramos, entre otros. Premio: Libro Hacking y seguridad en internet. El solucionario ganador será el mejor elaborado de los recibidos. Esto puede implicar aspectos como la solución más creativa, diferentes vulnerabilidades en el mismo sistema, capturas de pantalla, desarrollo de un exploit(???) y por supuesto todo esto de una manera amena y dirigida especialmente a personas que NO tienen conocimientos avanzados en estos temas y desean aprender por medio de la práctica. El reto comienza desde el 23-05-2014 hasta 01-06-2014. Lo clasifico en un nivel medio. Por lo tanto son bienvenidas todas las personas que recién están comenzando y las que llevan ya su tiempo :) Pueden enviarme los solucionarios a 4v4t4r (AT) gmail (DOT) com Descargar SecOS-1 MD5 (SecOS-1.tar.gz) = e8c01ab49b98926a37f79e2ea414cfc5 Fuente: http://www.sec-track.com/reto-secos-1-paulwebsec-nivel-medio-ctf-web-premi o-libro-hacking-y-seguridad-en-internet

Preparación del entorno

El primer proceso que se realizó fue descargar la máquina virtual desde la siguiente URL http://download.vulnhub.com/secos/secos-1.tar.gz y proceder a verificar el resumen criptográfico con el proporcionado en la página del reto (e8c01ab49b98926a37f79e2ea414cfc5). Esto se hizó haciendo uso de la herramienta File Checksum Integrity Verifier: Posteriormente se extrajo el contenido del archivo SecOS-1.tar.gz haciendo uso de la herramienta 7-Zip: Se procedió a iniciar la máquina virtual haciendo uso del software de virtualización VMware Player, seleccionando la opción Open Virtual Machine y luego el archivo SecOS-1.vmdk, sin embargo, se obtuvo el siguiente error:

Investigando en Internet encontré que primero debía crear el archivo SecOS-1.vmx, lo cual se hizo creando una nueva máquina virtual con nombre SecOS-1 y reemplazando el SecOS-1.vmdk de esta por el de la original. Una vez importada la máquina virtual, se configuró el adaptador de red en modo puente: Finalmente la máquina se encontraba lista para comenzar el reto:

Reconocimiento / Escaneo

Debido a que en la página del reto nos dicen que la máquina virtual toma la dirección IP por DHCP, se identificó el segmento de red y dirección IP de la máquina que realizaría el ataque a fin de lanzar un escaneo con Zenmap sobre todos los hosts de ese segmento, excluyendo la máquina atacante. El escaneo con Zenmap se corrió con los parámetros -A (OS detection, version detection, script scanning, and traceroute), -T4 (more aggressive timing), --exclude (Exclude hosts/networks): nmap-a-t4--exclude192.168.1.14192.168.1.1-254

Con los resultados del escaneo se evidenció que el host 192.168.1.18 tiene corriendo dos servicios sobre los puertos 22 y 8081, el servicio SSH y HTTP respectivamente. Adicional a esto, sobre el servicio HTTP corre un aplicación web llamada Secure Web App, desarrollada con el framework para la plataforma de software Node.js, Express. Se concluyó que se había encontrado el objetivo a atacar. Al acceder a la dirección http://192.168.1.18:8081 desde el navegador web, se encontró la aplicación web Secure Web App. La descripción en la página Home indica la misión: Explorar el sitio web en busca vulnerabilidades que de alguna manera nos permitirían conseguir usuario root en el servidor, para finalmente leer la bandera ubicada en la ruta /root/flag.txt.

Prueba de seguridad de la aplicación Secure Web App

Lo primero que se hizo fue descargar y configurar la herramienta Burp Suite a fin de usar su proxy de intercepción para inspeccionar de forma más cómoda el tráfico entre el navegador y la aplicación. En el navegador, se modificó la configuración de conexiones, para que hiciera uso del proxy, en la ruta: Tool > Options > Network > Settings. En Burp Suite, en la pestaña Proxy > Options, se habilitó la opción Intercept Server Responses, para interceptar también las respuestas del servidor y no sólo las peticiones.

Finalmente, se empezó a navegar a través de todas las páginas de la aplicación con el fin de levantar información general sobre el objetivo. Mientras se navegaba por las páginas, sin estar autenticado en la aplicación, en la página Home, en la línea de código número 42, se encontró un comentario que ofrecía una pista:

Al ingresar a la página Wanna help? (http://192.168.1.18:8081/hint), en las líneas de código 57-59, se encontraron las siguientes tres pistas: 1. the admin visits the website (really) frequently. 2. He runs it locally, on 127.0.0.1. 3. CSRF and /(http:\/\/[-\/\.\w:0-9\?&]+)/gi, I think that s enough. Resumiendo se concluye que: La aplicación es vulnerable a Cross-site Request Forgery. Se debe explotar la vulnerabilidad en la cuenta del administrador de la aplicación. Para que el ataque funcione, se debe tener presente que la URL del exploit no será la dirección IP del atacante sino la dirección IP de la interfaz de red loopback (127.0.0.1). La URL del exploit debe coincidir con la expresión regular suministrada ya que seguramente será un script quien acceda a la URL. El siguiente paso fue crear un usuario en la aplicación, a través del formulario de registro, para conocer las funcionalidades que ofrece y verificar si son vulnerables.

Una vez logueado con el usuario, se tiene acceso a cuatro rutas que no se encontraban en la página antes de iniciar sesión. Las rutas son: /users /messages /send-message /change-password En la ruta users se logró identificar que spiderman es el usuario administrador, así como la existencia de otros 2 usuarios no administradores: pirate y test. En la ruta messages se probó si era vulnerable a Cross-site Scripting sin éxito:

En la ruta send-messages se corroboró que se pueden enviar mensajes a los usuarios de la aplicación: Y por último la ruta change-password permite cambiar la contraseña del usuario:

Analizando el código fuente de esta última (change-password), se verificó que no tiene implementado el token secreto aleatorio que mitiga el ataque, lo cual concluye que el primer objetivo es robar la cuenta del administrador: En un entorno real, el flujo del ataque sería de la siguiente manera: Alojar en una URL, una página (exploit) que al ser accedida por la victima, envíe una petición POST a la ruta http://127.0.0.1:8081/change-password con un parametro password que contenga la nueva contraseña. Enviar un mensaje a la víctima en el cual, a través de ingeniería social, se obligue a visitar la URL que contiene el exploit. Esto debido a que la aplicación no es vulnerable a Cross-site Scripting, lo cual haría el ataque mucho más sencillo al no requerir intervención por parte del usuario para explotarlo. Iniciar sesión en la aplicación, con el usuario de la víctima, a fin de buscar información en la bandeja de entrada de mensajes o vulnerabilidades adicionales en nuevos menús administrativos, que permitan ganar acceso al servidor. Un ejemplo de exploit para explotar el Cross-site Request Forgery podría ser el siguiente:

Sin embargo, se optó por probar la herramienta recomendada en la descripción del reto y desarrollada por el autor del mismo, @PaulWebSec: Cross Site Request Forgeries (Exploitation) Toolkit. La descripción y guía de instalación se encuentra la página GitHub de Paul: https://github.com/paulsec/csrft. Para usar la herramienta CSRFT se crearon los archivos: secos1_change_password.html y secos1_change_password.json. El archivo secos1_change_password.html contiene el exploit. El archivo secos1_change_password.json contiene la configuración de la herramienta CSRFT.

Finalmente, para lanzar el servidor web local que aloja el exploit se pasaron los siguientes parámetros a la herramienta CSRFT: nodeserver.jsc:\csrft\conf\secos1_change_password.json Lo siguiente a realizar entonces es engañar a Spidey a través de ingeniería social para que visite el sitio web con el exploit: http://192.168.1.14:8080/. Esta es la parte divertida : D.

Se esperan unos cuantos segundos y el exploit es accedido por el usuario:

Adicionalmente se creó un archivo index personalizado para la página de inicio de la herramienta CSRFT. El servidor por defecto escucha en el puerto 8080 y desde el navegador se ve cómo finalmente se desplegó la URL con el exploit para ownear a spiderman : D

Spiderman Owned!

Ya con la cuenta de spiderman bajo control, se procedió a iniciar sesión en la aplicación como administrador: Se validó que la cuenta administrador no desplegará menús adicionales, con lo cual se concluyó que se debían leer los mensajes recibidos: Al acceder a la ruta messages, se encontraron 3 mensajes, uno fue el mensaje que nosotros enviamos, y dos más del usuario pirate, en estos últimos se encontró la clave real del usuario spiderman.

Al no haber más páginas en la aplicación vulnerable, sólo quedó por probar las credenciales de spiderman en el servicio SSH.

Prueba de seguridad de la infraestructura

Las credenciales del usuario spiderman funcionaron, con lo que se ganó shell en el servidor, posterior a esto se probó si el usuario spiderman tenía acceso a la utilidad sudo para ejecutar programas con privilegios de seguridad más altos de otro usuario (generalmente root) lo cual nos permitiría leer el archivo /root/flag.txt o también leer el archivo /etc/shadow y descifrar el resumen criptográfico de la contraseña del usuario root. El resultado fue el siguiente: spiderman is not in the sudoers file. This incident will be reported. Luego de explorar los ficheros y carpetas accesibles para el usuario spiderman sin encontrar nada que pudiera ser de utilidad, se buscó por otros usuarios locales del sistema que pudieran tener más privilegios que los que tenía el usuario spiderman, leyendo el archivo /etc/passwd el cual contiene la entrada de los usuarios locales del sistema y filtrando por la palabra clave admin. Se encontraron dos usuarios: gnats, el cual es de una utilidad para administrar el reporte de fallas de seguridad, sin embargo, no tiene inicio de sesión en el sistema, y por último el usuario secosadmin el cual tiene establecida shell. Se procedió entonces a verificar que en realidad el usuario secosadmin sea un administrador, mirando a cuáles grupos del sistema pertenece. Se encontró que pertenece al grupo de usuarios sudo:

Posteriormente se intentó adivinar la clave del usuario secosadmin a través de un ataque de diccionario, haciendo uso de la herramienta Hydra y el archivo /dicos/passwords.txt que viene incluido en la herramienta CSRFT. El ataque de diccionario con Hydra se realizó con los parámetros -l (login with LOGIN name), -P (load several passwords from FILE), -f (exit when a login/pass pair is found), -e (try "n" null password, "s" login as pass and/or "r" reversed login), -t (run TASKS number of connects in parallel), -V (show login+pass for each attempt): hydra -l secosadmin -P /tmp/wordlists.txt -f -e rns -t 5 -V ssh://192.168.1.18 El ataque fue exitoso, Hydrá encontró la clave del usuario secosadmin en el doceavo intento. Se hizo uso del comando su para cambiar al usuario secosadmin y validar que efectivamente las credenciales que identificó Hydra sean correctas:

Finalmente, con el control sobre la cuenta secosadmin, se hizo uso del comando sudo su para cambiar al usuario root y leer la bandera ubicada en /root/passwd: sudosu id cat/root/flag.txt Con la lectura del archivo /root/flag.txt se dió por finalizado el reto y se procedió a enviar este soluciario a @4v4t4r para participar por el libro: Hacking y seguridad en internet, Garcia Moran.

Herramientas usadas

En el desarrollo del reto se hizo uso de las siguientes herramientas: File Checksum Integrity Verifier 7-Zip VMware Player Nmap Zenmap Burp Suite Free Edition Cross Site Request Forgeries (Exploitation) Toolkit Hydra Mozilla Firefox Sublime Text