View
229
Download
1
Category
Preview:
DESCRIPTION
Solucionario Reto SecOS 1 por @itsecurityco http://www.sec-track.com/reto-secos-1-paulwebsec-nivel-medio-ctf-web-premio-libro-hacking-y-seguridad-en-internet
Citation preview
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
Recommended