Vulnerable Machines

Writeups de máquinas vulnerables — pentesting ofensivo · Preparando eJPT

View on GitHub

Road to Olympus

En este writeup resolvemos el laboratorio Road to Olympus de DockerLabs, formado por tres máquinas encadenadas: Hades, Poseidón y Zeus. No todas son accesibles directamente: hay que comprometer cada una para pivotar hacia la siguiente, avanzando por la infraestructura hasta llegar a la última.

El objetivo no es solo tomar cada máquina, sino entender el porqué de cada paso: cómo una pista dejada en el código nos da el primer acceso, cómo montamos túneles con chisel para llegar a redes que no vemos desde fuera, y cómo cada compromiso nos acerca a la siguiente máquina.


Topología del laboratorio

Al descomprimir el laboratorio vemos que se despliegan tres máquinas: Hades, Poseidón y Zeus. Empezaremos por Hades.

El esquema de cómo se conectan las tres máquinas queda así, lo que nos anticipa que tendremos que pivotar de una a otra:


Hades (10.10.10.2) — primera máquina

Escaneo de puertos

Empezamos con un escaneo completo de la primera máquina:

sudo nmap -p- -sS -sC -sV --min-rate 5000 -n -vvv -Pn 10.10.10.2 -oN Escaneo

La versión de SSH es bastante moderna, así que la obviamos y nos centramos en el puerto 80, que corre Werkzeug, el servidor de desarrollo que usa Flask (el framework web de Python).

Análisis del servicio web

Al abrir 10.10.10.2 en el navegador nos aparece lo siguiente:

Y al pulsar en cerrar, esto otro:

Inspeccionando el código fuente, al final encontramos una línea comentada muy reveladora:

<!-- Guardar en KeePass y borrar al verlo. Nueva contraseña para el servicio SSH de cerbero el perro de 3 cabezas JZKECZ2NPJAWOTT2JVTU42SVM5HGU23HJZVFCZ22NJGWOTTNKVTU26SJM5GXUQLHJV5ESZ2NPJEWOTLKIU6Q==== -->

La cadena está codificada, así que la decodificamos y obtenemos la contraseña del servicio SSH del usuario cerbero:

La contraseña es P0seidón2022!.

Acceso por SSH

Con esas credenciales accedemos por SSH a Hades:

Con esto damos por hecha la primera máquina.


Pivoting hacia Poseidón (chisel + socat + proxychains)

Poseidón no es accesible directamente desde nuestra máquina; hay que pasar por Hades. Para ello montaremos un túnel con chisel.

Descargamos la versión más reciente de chisel:

Lo descomprimimos y lo renombramos a chisel para trabajar más cómodos:

También descargamos socat, que necesitaremos más adelante, y lo renombramos a socat:

Ya lo tenemos todo descargado y toca pasarlo a la máquina Hades. Como disponemos de credenciales de SSH, usamos scp para transferir tanto chisel como socat desde nuestra máquina a Hades:

Una vez en la máquina, les damos permisos de ejecución:

Levantamos el servidor de chisel en nuestra Kali por el puerto 1234:

Y en la terminal de cerbero (Hades) lanzamos el cliente de chisel:

Toca editar el archivo /etc/proxychains.conf: comentamos la línea de strict_chain y descomentamos la de dynamic_chain.

Por último, comprobamos que abajo del todo esté descomentada la línea socks5 127.0.0.1 1080, que es el puerto por defecto que usa chisel.

A partir de aquí, todas nuestras acciones contra la red de Poseidón deben ejecutarse a través de proxychains / proxychains4, que usan el archivo de configuración que acabamos de editar.


Poseidón (20.20.20.3) — segunda máquina

Escaneo a través del túnel

Con el túnel montado, escaneamos Poseidón con nmap a través de proxychains para ver sus puertos, servicios y versiones:

proxychains4 -q nmap -sT -Pn -p 22,80 20.20.20.3

Vemos los puertos 22 y 80, así que miraremos el 80 en el navegador. Antes tenemos que configurar FoxyProxy para que el tráfico del navegador pase por el túnel:

Al poner 20.20.20.3 en el navegador vemos lo siguiente:

En la barra de navegación hay tres apartados: Buscar, Ranking y Perfil. Nos interesa Buscar, que lleva a un subdirectorio con un sistema de búsqueda:

Revisamos el código fuente para ver cómo tramita la petición este buscador:

Observamos que envía mediante el método POST una petición al archivo database.php, así que entendemos que pasa el parámetro del campo de búsqueda y con él realiza la consulta a la base de datos.

Inyección SQL (SQLite)

Intentamos usar sqlmap para volcar la base de datos, pero no funcionó. Tras varios intentos por averiguar qué motor se usaba, deducimos que es SQLite, ya que este motor emplea una tabla interna con el esquema de la base de datos llamada sqlite_master.

Para leer esa información introducimos en el campo de búsqueda la consulta:

select name from sqlite_master

Aparecen tablas que nos interesan, como las de usuarios y contraseñas, así que las consultamos:

Obtenemos los usuarios poseidon y megalodon, con contraseñas que parecen codificadas:

$sha1$oceanos$QqFgxFPmqRex1ZKFCZ2ONJKWOTTNKFTU46SBM5ZKFCZ2ONJKWOTTNKFTU4GQPdkh3nQSWp3I=
$sha1$hahahaha$JZKFCZ2ONJKWOTTNKFTU46SBM5HG2TLHJV5ECZ2NPJEWOTL2IFTU26SFM5GXU23HJVVEKPI=

Las decodificamos:

Una de ellas corresponde a megalodon → Templ02019!.

Acceso por SSH y escalada a root

Una de las contraseñas no funciona, pero la otra sí, así que entramos por SSH a Poseidón:

Con esto ya estamos dentro de la segunda máquina.

Una vez conectados, vemos que tenemos permisos en sudoers para ejecutar cualquier cosa, así que con un sudo bash nos convertimos en root:


Pivoting hacia Zeus (segundo salto)

Poseidón tiene conexión con la última máquina, Zeus, así que repetimos una idea parecida a la del primer salto.

Pasamos chisel a Poseidón:

Arrancamos socat para que reenvíe el puerto 1111 hacia nuestro chisel server en Kali:

Lanzamos chisel dentro de Poseidón:

Y reconfiguramos el archivo /etc/proxychains.conf, comentando la entrada anterior y añadiendo la nueva:

Con el nuevo túnel, escaneamos a ver qué hay:

Comprobamos si llegamos a Zeus con curl:

proxychains4 -q curl -s -m 8 http://30.30.30.3/ -o /dev/null -w "HTTP: %{http_code}\n"

Nos devuelve HTTP 200, así que la conexión está OK:


Zeus (30.30.30.3) — tercera máquina

Enumeración SMB con enum4linux

Vemos que Zeus tiene abiertos los puertos 21, 22, 80, 139 y 445. En los puertos 139 y 445 corre SAMBA, así que usamos enum4linux para obtener información, en concreto para enumerar los usuarios:

Descubrimos dos usuarios: rayito y hercules.

Fuerza bruta FTP con Hydra

Con los usuarios en mano, podemos intentar un ataque de fuerza bruta contra el puerto 21 (FTP). Antes creamos un archivo con los usuarios:

Para la fuerza bruta usamos una versión reducida de rockyou, ya que el ataque a través del túnel es lento:

head -5000 /usr/share/wordlists/rockyou.txt > minirock
proxychains4 -q hydra -L users -P minirock ftp://30.30.30.3

Después de un rato largo, Hydra nos da la contraseña de hercules:

Acceso FTP y contraseña de rayito

Con esa contraseña accedemos por FTP:

Dentro vemos un archivo, así que entramos a verlo. En su contenido encontramos una cadena que, al decodificarla, nos da la contraseña del usuario rayito:

Acceso por SSH como rayito

Solo nos queda acceder por SSH con esas credenciales:

Con esto completamos la tercera y última máquina.


Conclusión

Road to Olympus se resuelve encadenando tres máquinas y dos saltos de pivoting. En Hades, una pista dejada en un comentario del código HTML nos entrega, tras decodificarla, la contraseña SSH de cerbero. Desde ahí montamos un túnel con chisel, socat y proxychains para alcanzar Poseidón, donde una inyección SQL sobre SQLite nos expone los usuarios y sus contraseñas codificadas; con las de megalodon entramos por SSH y, gracias a un sudoers permisivo, escalamos a root. Un segundo salto de pivoting nos lleva a Zeus, donde enumeramos usuarios por SMB con enum4linux, obtenemos la contraseña de hercules por fuerza bruta en FTP y, dentro del FTP, recuperamos la contraseña de rayito para el acceso final por SSH.

El laboratorio refuerza varias ideas clave: nunca dejar secretos en comentarios del código, no almacenar contraseñas en formatos fácilmente reversibles, evitar configuraciones de sudo que permitan ejecutar cualquier cosa, y entender el pivoting como herramienta para alcanzar redes que no son visibles directamente desde el exterior.

⚠️ Realizado con fines educativos y en un entorno controlado.