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 --exclude 192.168.1.14 192.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:

node server.js C:\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:

spidermanisnotinthesudoersfile.Thisincidentwillbe

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-lsecosadmin-P/tmp/wordlists.txt-f-erns-t5-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:

sudo su

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