Hacknet WriteUp Hack The Box
Introducción
Hacknet es una máquina de Hack The Box de dificultad media. La explotación requiere adentrarse en una red social de hackers, comprender su funcionamiento e introducir un payload en nuestro nombre de usuario para extraer información, como nombres y contraseñas del resto de los usuarios.
Más adelante, se aprende a inyectar código malicioso en la caché del sitio web, lo que permite la ejecución de comandos para obtener acceso como el usuario sandy.
Finalmente, con el acceso del usuario sandy, se crackea su clave GPG para descomprimir los backups de la máquina y, de esta manera, encontrar la clave de administrador.
Reconocimiento
Comenzamos con el habitual escaneo de puertos. En este caso, se encuentra el puerto 22 (SSH), que no se puede atacar inicialmente por falta de credenciales, y el puerto 80 con una página web.
Para acceder al puerto 80, es necesario añadir la IP y el dominio al archivo /etc/hosts. Una vez dentro, se presentan dos botones: uno para iniciar sesión y otro para registrarse.
Dado que no se conocen usuarios, se procede a crear una nueva cuenta para explorar el contenido.
Tras iniciar sesión, se observan varias secciones como “Profile”, “Contacts”, “Messages”, entre otras.
En la sección de “Search” se pueden encontrar a todos los usuarios de la web.
La sección “Explore” muestra publicaciones de los usuarios, con opciones para dar “likes” y añadir comentarios.
Si se intercepta la petición al pulsar el botón de “likes”, se observa que se envía una solicitud a la URL /likes/22.
Al acceder directamente a esa URL, se visualizan los usuarios que han dado “like” a esa publicación. Además, al revisar el código fuente, se exponen todos los nombres de usuario.
Por último, utilizando la extensión de navegador “Wappalyzer”, se descubre que la página web está construida con Django.
Este dato sugiere la posibilidad de probar un payload de plantilla de Django, ya que el sitio web muestra nuestro nombre de usuario.
Explotación
Para que el ataque funcione, se requiere el campo users, un número que indique el usuario y el campo que se desea extraer (en este caso, el correo electrónico).
Tras guardar los cambios y refrescar la página, al final del código fuente se encuentra una parte de la credencial filtrada.
Sabiendo esto, se modifica el payload para mostrar la contraseña del usuario.
Después de una investigación exhaustiva en las cuentas de usuario de esa publicación, no se encontró nada útil, por lo que se probó con la publicación que tenía más “likes” en la plataforma.
Aplicando el mismo payload para extraer correos y probando múltiples veces, se identifica la credencial más interesante.
Con el payload de la contraseña, se extrae el siguiente valor.
Se intenta iniciar sesión con la cuenta de este usuario.
Como se muestra en la imagen, el usuario deepdive tenía una publicación oculta con un solo “like”.
Al revisar sus contactos, se encuentra que solo tiene agregado al usuario backdoor_bandit.
Se verifica que el usuario backdoor_bandit es quien ha dado “like” a la publicación privada.
Interceptando la petición con Burp Suite, se determina que la publicación oculta tiene el número 23.
Se cierra la sesión de deepdive, se intercepta otro “like” de una publicación diferente, se manipula la petición y se cambia el número por 23.
Si el ataque se ha realizado correctamente, al acceder a la URL de la publicación 23, se debe visualizar nuestro propio usuario.
Aplicando el exploit utilizado anteriormente, se obtienen las credenciales de mikey@hacknet.htb. Al intentar iniciar sesión por SSH con este usuario, se consigue el acceso. En su carpeta se encuentra la primera flag.
Realizando un reconocimiento de la máquina para identificar carpetas con permisos de escritura para el usuario mikey, se descubre la ruta inusual /var/tmp/django_cache. Se procede a envenenar la caché antes de que sea eliminada para crear una shell como el usuario sandy.
El elemento principal de este script es la librería pickle para crear objetos maliciosos. Cuando la aplicación Django (ejecutándose con el usuario sandy) deserializa la caché, se creará la shell en el directorio /tmp/.
Se ejecuta el script que genera el payload.
Se puede generar caché simplemente navegando por la web. Una vez que se tiene caché almacenada en la máquina, se utiliza el siguiente comando que permite añadir el payload a todos los archivos y les otorga todos los permisos.
Tras unos 5 segundos, el archivo se genera con los permisos del usuario sandy.
Escalada de privilegios
El último paso es la escalada de privilegios. El usuario sandy tiene backups de la web almacenados en la máquina, los cuales están comprimidos y cifrados con GPG.
Al acceder a su directorio, se encuentra una carpeta oculta: .gnupg.
Dentro de ella está el archivo con la clave necesaria para descifrar los backups.
Si se guarda el contenido de ese archivo y se intenta importar en la máquina atacante, se solicita la clave, que aún no se conoce.
Se intenta crackear la clave utilizando la herramienta gpg2john para extraer un hash que luego pueda ser procesado por la herramienta john (John the Ripper).
Se indica el formato, el diccionario y el archivo hash generado. En poco tiempo, se obtiene la contraseña para descifrar los backups.
Finalmente, solo queda copiar los archivos a la máquina atacante para su descompresión.
Se importa la clave obtenida anteriormente.
Y por último, se descomprime el archivo.
Una vez descomprimido, al buscar por la palabra “password”, se encuentra una conversación donde se filtra la clave de administrador.
De esta forma, se consigue acceder fácilmente al usuario root y se obtiene la última flag de la máquina.
Conclusión
La explotación de Hacknet se ejecutó mediante una cadena de ataque en tres fases: primero, se utilizó una Inyección de Plantilla de Django (SSTI) para extraer credenciales y obtener acceso inicial como el usuario mikey. Segundo, se escaló a sandy mediante el envenenamiento de la caché de Django explotando una vulnerabilidad de deserialización de pickle. Finalmente, se alcanzó el acceso a root al crackear la clave GPG de sandy para descifrar backups que contenían las credenciales de administrador, destacando la necesidad de asegurar tanto el código de la aplicación como la gestión de claves criptográficas.
Espero que os haya gustado esta máquina y nos vemos en la próxima.