LinkVortex – Hack The Box [Write Up]

La máquina LinkVortex es una máquina fácil de HTB.

Resumen de conceptos trabajados:

✔ Importancia del reconocimiento (nmap, gobuster, enumeración de CMS). ✔ Cómo explotar una vulnerabilidad de lectura arbitraria de archivos (LFI). ✔ Cómo obtener credenciales sensibles en archivos de configuración. ✔ Cómo escalar privilegios abusando de scripts sudo mal configurados. ✔ Uso avanzado de symlinks para leer archivos de root.

Si es tu primera máquina en Hack The Box y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento cómo introducirte en esta plataforma.

A continuación, para conectarte a la máquina, tendrás que establecer la conexión con la máquina víctima de HTB conectándote a la VPN desde la carpeta donde la tengas descargada, y desde ahí ejecutarás el comando «sudo openvpn NOMBRE_VPN.ovpn».

ENUMERACIÓN -> ESCANEO DE PUERTOS

Para asegurarme de que la máquina víctima está activa y puedo conectarme a ella, lanzo un PING o directamente un nmap, por ejemplo:

ping -c 1 10.10.11.47 -R

Explicación de los comandos:

ping: nos permite verificar la conectividad entre la máquina víctima y la atacante enviando paquetes ICMP (Internet Control Message Protocol) para medir la latencia y comprobar si el host (víctima) está activo.

-c 1: este argumento indica que solo se enviará 1 paquete ICMP en lugar de los envíos continuos predeterminados. Esto es útil para realizar un testeo de la IP rápido.

10.10.11.32: Es la dirección IP del host que se quiere comprobar. Puedes reemplazarlo con cualquier dirección IP o dominio que quieras atacar del laboratorio.

-R: Habilita la opción de registro de rutas (Record Route). Esta opción solicita a los routers en el camino entre tu máquina y el host objetivo que incluyan su dirección IP en la cabecera de los paquetes ICMP. Permite rastrear la ruta completa de ida y vuelta del paquete. No siempre todos los routers admiten esta opción, por lo que en algunos casos podrías no obtener información completa.

*Se transmite un paquete de ida, y se recibe 1 paquete de vuelta. Pasando por el nodo intermediario que deja en el trace route HTB, por lo que sabemos por el TTL 63 que estamos ante una máquina Linux.

Con nmap podemos ver también de primeras si la máquina está activa:

Explicación de los comandos:

-sn (Ping Scan): Realiza un escaneo simple para determinar si el host está activo, pero sin escanear puertos. Esto se conoce como un «Ping Scan».

Una vez comprobado que la máquina está activa, vamos a lanzar un nmap con permisos de root para ver qué puertos están abiertos y exportar el resultado en un fichero llamado «Escaneo» que nos pueda permitir más adelante manipularlo o consultarlo si lo necesitamos:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.10.11.47 -oG Escaneo

Completamos el escaneo y se reportan los 2 principales puertos que nos encontramos en los laboratorios de hacking: puerto ssh de autenticación y http web.

Este es el detalle de cada comando lanzado con nmap:

La idea de este escaneo es detectar puertos abiertos en la dirección IP especificada.

sudo : comando en Linux con privilegios de administrador.

nmap : nmap herramienta para escanear redes. Principalmente para descubrir hosts activos.

-p- : esta opción le indica a nmap que escanee todo el rango de puertos, los 65535.

--open : nmap solo mostrará los puertos que están abiertos. No mostrará ni los puertos closed ni filtered.

-sS : especifica el tipo de escaneo que se va a realizar. En este caso, es un escaneo SYN, también conocido como «escaneo sigiloso» o TCP SYN scan. Este tipo de escaneo no establece una conexión completa con el puerto, solo envía un paquete SYN y espera una respuesta. Si el puerto está abierto, responde con un SYN-ACK; si está cerrado, responde con un RST.

--min-rate 5000 : establece la velocidad mínima del escaneo en 5000 paquetes por segundo, lo que significa que nmap intentará enviar al menos 5000 solicitudes cada segundo. Esto puede hacer que el escaneo sea más rápido, pero también «más ruidoso» aumentando las posibilidades de ser detectado por sistemas de seguridad (en entornos de laboratorio como HTB o THM no es problema).

-vvv : (triple verbose) nivel de información que muestra nmap en consola mientras escanea.

-n : esta opción le indica a nmap que no resuelva nombres de dominio (DNS). Es decir, solo utilizará direcciones IP sin intentar convertirlas en nombres de host.

-Pn : le dice a nmap que no haga un «ping» a la dirección IP antes de escanearla. Con -Pn, nmap asumirá que el host está activo y procederá directamente al escaneo de puertos, útil si el host bloquea pings.

-oG Escaneo : especifica el formato de salida (output) y el nombre del archivo donde se guardarán los resultados del escaneo. Escaneo es el nombre del archivo de salida donde se guardarán los resultados.

ENUMERACIÓN DE SERVICIOS Y VERSIONES PARA ESOS PUERTOS

Sabiendo que estos puertos están abiertos, lo que hacemos a continuación es lanzar una serie de scripts básicos de reconocimiento de nmap para ver qué servicios y versiones corren por esos puertos abiertos:

nmap -sCV -p22,80 10.10.11.47

Descartamos que la versión del puerto ssh no es vulnerable a priori, versión 8.9p1 superior a la versión 7.7. vulnerable y visto en este writeup ,no vulnerable a user enumeration por lo que no estaría aquí el vector de entrada. Tampoco es accesible con las ssh login anonymous.

Vemos un dominio linkvortex.htb donde si lo incluimos en el navegador (ya que el puerto 80 http está abierto), vemos que no devuelve ninguna respuesta. Eso significa que para la misma IP se está asociado también ese dominio por lo que aplicando Virtual Hosting mediante la inclusión de la IP y el dominio en el archivo /etc/hosts/ podemos ahora sí acceder a la página y ver contenido.

CONFIGURACIÓN VIRTUAL HOST

Virtual Hosting es cuando una dirección IP va asociada a varios dominios o subdominios. De esa forma estás vinculando una IP a un dominio/subdominio y poder resolverlos en el navegador sin tener que incluir la IP sino el nombre del domino/subdominio.

En este punto aplicamos Virtual Host y modificando el fichero /etc/hosts/ de nuestra máquina y apuntando la IP víctima a ese dominio, ahora la redirección resuelve con un código 200:

Nos ponemos a investigar un poco la web buscando algo de información relevante que nos pueda ayudar a conseguir usuarios o contraseñas…

Algunas pistas encontradas:

• Usando el buscador de la web, llego hasta un artículo cuyo usuario es «admin» bajo esta ruta http://linkvortex.htb/author/admin/

• El CMS del sitio es «Ghost» en su versión 5.58, que podemos ver mediante la extensión del navegador Wappalyzer o en el código fuente bajo el tag meta name «generator». En el footer de la página lo ves también.

• También vemos en el footer un falso enlace a «Sign up» que apunta a http://linkvortex.htb/vga/#/portal/

• Analizamos si tiene creado un archivo robots.txt , y vemos que hay distintas carpetas bloqueadas a rastreadores. Después de ir revisándolos, veo que el /ghost/ es un panel de login al CMS: http://linkvortex.htb/ghost/#/signin

Sin embargo no tenemos credenciales, salvo un supuesto usuario «admin» y un supuesto correo que podríamos intuir «admin@linkvortex.htb«.

FUZZING WEB

Seguimos analizando la web y pasamos a investigar posibles subdominios usando ffuf en este caso , y nos encontramos con un subdominio «dev»:

ffuf -u http://linkvortex.htb/ -w /usr/share/wordlists/dirb/common.txt -H "Host: FUZZ.linkvortex.htb" -fc 301

Si lo ejecutamos en el navegador (después de haber añadido ese subdominio en el /etc/hosts), vemos la respuesta en el navegador pero no hay nada de información relevante en él más allá de este mensaje:

Por tanto vamos a analizar posibles directorios con ffuf para ese subdominio:

ffuf -u http://dev.linkvortex.htb/FUZZ -w /usr/share/wordlists/dirb/common.txt -fs 0 -t 100

Vemos un listado donde solo devuelve un «200» los directorios: .git/HEAD e index.html .

Nos quedamos con el primero ya que el index apunta a la home en sí del subdominio.

El .git/HEAD nos devuelve un listado alfanumérico que no parece ser ninguna contraseña a priori, sin embargo podemos seguir profundizando mediante el directorio .git:

http://dev.linkvortex.htb/.git/

En este punto, necesitamos encontrar credenciales para poder acceder al CMS y escalar privilegios si no somos root…

Sabemos que el usuario «admin» en el CMS existe porque al probar en el panel de login, me dice que la contraseña no es correcta, y si pruebas con otro mail, te dice que no existe:

Por tanto necesitamos conocer otros posibles o más usuarios y contraseñas.

Nos descargamos en nuestra máquina todos esos recursos dentro del .git para buscar potenciales contraseñas que probar con el usuario admin.

Para ello usamos git-dumper para descargar el repositorio completo:

git-dumper http://dev.linkvortex.htb/.git/ git-dump/

Después de obtener el .git/, lo reconstruimos:

cd git-dump/
git reset --hard

Esto nos permite recuperar todo el código fuente del sitio, incluyendo archivos de configuración y scripts.

Ejecutamos grep para buscar contraseñas o tokens en el código:

grep -Ri "password" .

Lo que encontramos en los archivos

• En authentication.test.js vimos varias contraseñas de prueba (thisissupersafe, 12345678910), pero no eran válidas.
• No encontramos la contraseña en archivos JSON (config.production.json).
• Buscamos en commits anteriores por si la contraseña había sido eliminada. Pero tampoco encontramos la contraseña real aquí.

git log -p | grep -i "password"

La contraseña no apareció en los archivos que analizamos directamente, pero vimos que estaba en pruebas de regresión del CMS Ghost.

Una vez dentro, tratamos de buscar información sensible sobre la versión del CMS que nos ayude a encontrar algún exploit. Versión 5.58, que nos confirma lo que ya vimos en el código fuente.

ACCESO COMO USUARIO

Si buscamos en internet por vulnerabilidades de la versión 5.58 del CMS Ghost, encontramos un github que referencia a un script que lee archivos arbitrarios desde el servidor reportado en el CVE-2023-40028.

Me descargo ese fichero .sh y modifico la GHOST_URL para que apunte a linkvortex.htb en lugar de la IP por defecto que pone.

Con el .sh descargado en nuestra máquina, damos permisos de ejecución al sh con chmod, y así podemos ejecutarlo, y vemos que accedemos al repositorio de ficheros:

Explotado correctamente el CVE-2023-40028 para leer archivos arbitrarios y confirmado que podemos ver /etc/passwd. Esto significa que podemos leer archivos sensibles en el sistema.

Ahora, el siguiente paso es obtener credenciales de usuario o acceder a user.txt y root.txt.

Como tenemos lectura arbitraria de archivos, intentamos leer config.production.json, que puede contener credenciales de la base de datos Ghost:

Usuario:bob@linkvortex.htb ; Contraseña: fibber-talented-worth

Nos conectamos por ssh que estaba abierto con estas credenciales:

ssh bob@10.10.11.47

haciendo un ls encontramos la primera flag de user.txt

ESCALADA DE PRIVILEGIOS

Ahora para escalar a root, vamos a ver si este usuario bob tiene permisos especiales para ejecutar comandos como root mediante el «sudo -l».

Bob puede ejecutar dos comandos como root sin necesidad de contraseña:

• /usr/bin/bash (esto nos daría acceso root directo)
• /opt/ghost/clean_symlink.sh *.png (posible vector de explotación si fuera necesario)

Vemos que bob no tiene permisos de root, por lo que seguimos explotando la otra opción.

Lo haremos utilizando enlaces simbólicos (symlinks) y manipulando la variable CHECK_CONTENT.

Resumen de la vulnerabilidad:

• El script mueve enlaces simbólicos a /var/quarantined/.
• Si CHECK_CONTENT=true, muestra el contenido del archivo movido.
• Podemos crear un symlink que apunte a /root/root.txt y engañar al script.

Paso 1: Crear un enlace simbólico a root.txt

Primero, creamos un enlace simbólico (symlink) que apunte al archivo /root/root.txt:

ln -s /root/root.txt hyh.txt

¿Qué estamos haciendo aquí?

• ln -s /root/root.txt hyh.txt → Creamos un enlace simbólico llamado hyh.txt que apunta a /root/root.txt.

Paso 2: Crear un segundo symlink para engañar al script

El script requiere que el archivo tenga la extensión .png, así que creamos otro symlink:

ln -s /home/bob/hyh.txt hyh.png

¿Qué hicimos aquí?

• ln -s /home/bob/hyh.txt hyh.png → Creamos un segundo symlink (hyh.png) que apunta a hyh.txt, el cual a su vez apunta a root.txt.

Paso 3: Ejecutar el script con CHECK_CONTENT=true

Ejecutamos el script forzando que muestre el contenido del archivo:

sudo CHECK_CONTENT=true /usr/bin/bash /opt/ghost/clean_symlink.sh /home/bob/hyh.png

¿Qué pasa aquí?

• CHECK_CONTENT=true → Hace que el script muestre el contenido del archivo después de moverlo a /var/quarantined/.
• /opt/ghost/clean_symlink.sh /home/bob/hyh.png → El script moverá el symlink y leerá su contenido.

Y el contenido nos daría la flag de root.txt

RESUMEN Realizamos un escaneo de puertos con nmap y descubrimos los puertos abiertos 22 ssh y 80 web. Vimos por la cabecera de la respuesta del p80 que había una redirección al dominio http://linkvortex.htb, por lo que aplicamos VHosting. Accedimos y vimos que utilizaba el CMS Ghost v5.58. Investigamos y encontramos una vulnerabilidad conocida (CVE-2023-40028 – Arbitrary File Read), que nos permitió leer archivos del sistema, incluyendo /var/lib/ghost/config.production.json, donde hallamos credenciales de un usuario (bob@linkvortex.htb con contraseña fibber-talented-worth). Usamos estas credenciales para conectarnos al servidor mediante SSH, obteniendo acceso como el usuario bob, lo que nos permitió leer user.txt. Para escalar privilegios a root, ejecutamos sudo -l y descubrimos un script (clean_symlink.sh) que podía mover archivos y leer su contenido si se configuraba la variable CHECK_CONTENT=true. Aprovechamos esta función creando un enlace simbólico (symlink) que apuntaba a root.txt, engañando al script para que lo moviera y mostrara su contenido. Finalmente, ejecutamos el script con sudo, logrando así leer la flag de root.txt y completar la máquina.