Introducción
Hola a todos, en esta publicación compartiré mi artículo sobre CTF Mantis, que es una máquina de directorio activo de Windows realmente antigua, comenzando con la máquina, había un servidor IIS ejecutándose en el puerto 1337 en el que la búsqueda de archivos revela el directorio donde tenía un archivo de texto que contenía algunas credenciales y el nombre del archivo que en realidad era una contraseña para el servicio MSSQL, al iniciar sesión en mssql como admin, podemos encontrar la contraseña para el usuario james, a partir del cual utilizando impacket-goldenPac realizaremos la elevación de privilegios.
Enumeración
El primer paso como siempre, escaneo de los servicios disponibles en la máquina objetivo.
Vemos algunos servicios interesantes, kerberos, smb, rpc, ldap, http, mssql.
Ejecutamos enum4linux para verificar autenticaciones nulas en smb, ldap y rpc por si fuese posible enumerar nombres de usuarios.
Pero no podemos acceder a nada interesante.
Smbmap y smbclient tampoco devuelve nada interesante.
En los resultados del escaneo de NMAP, había un servicio HTTP corriendo en un puerto raro (1337). Vamos a abrirlo en el navegador.
Es una página predeterminada de un servidor IIS 7.
Vamos a buscar directorios interesantes utilizando la herramienta dirsearch.
Hacemos el mismo procedimiento con el otro puerto HTTP (8080).
Vamos a ver en el navegador la url http://10.10.10.52:1337/secure_notes/
Secure_notes es un directorio de archivos listados. Web.config no contiene ninguna información de interés, pero dev_notes…
Debemos tener en cuenta dos cosas:
- El nombre del archivo
- La longitud de la barra de desplazamiento que nos indica que todavía puede contener más información a lo largo del archivo.
Vamos a comenzar por el punto 1. El nombre del archivo parece sospechoso, dos extensiones y un nombre que parece escrito de forma aleatoria, aunque también puede ser un hash. Utilizando esta web, detectamos el tipo de hash. Obtenemos que es Base64. Vamos a decodificarlo de la siguiente manera:
El resultado de la decodificación parece un hash en hexadecimal.
Ya tenemos la que parece una password para una base de datos MSSQL. m$$ql_S@_P@ssW0rd!
Vamos a descifrar también lo que parece una password cifrada en binario.
Vamos intentar conectarnos a la base de datos utilizando la password anterior, el usuario admin y la base de datos orcharddb que se indicaba en el archivo dev_notes. Para ello, vamos a utilizar la aplicación DBeaver.
Ahora la base de datos muestra cuatro bases de datos:
Dentro de la base de datos orcharddb que se nos indicaba en la documentación, tras realizar una búsqueda entre todas las tablas existentes, encontramo una tabla con el nombre blog_Orchard_Users_UserPartRecord que la podemos encontrar en orcharddb/Schemas/dbo/Tables.:
Dentro localizamos dos nombres de usuario con sus respectivas contraseñas. Vamos a utilizar el par usuario:contraseña de james que se encuentra en texto plano.
Como usuario james, podemos volcar la lista completa de usuarios vulnerables a ASP-REP, pero no existe ningún usuario.
Por otro lado, vamos a intentar logearnos con el usuario admin en el cms, por si pudiese contener puntos de entrada vulnerables. La url es http://10.10.10.52:8080/Users/Account/AccessDenied?ReturnUrl=%2Fadmin
Y podemos conectarnos con estas credenciales, admin:@dm!n_P@ssW0rd!
Pero tras realizar una búsqueda de posibles puntos de entrada, esto parece un rabbithole.
Explotación
Con las credenciales encontradas (james:J@m3s_P@ssW0rd!) en el archivo orcharddb de MSSQL, vamos a tratar de explotar Kerberos:
Vamos a añadir el host a nuestro /etc/hosts.
Ahora ejecutamos GoldenPac, script que pertenece a la suite Impacket.
Ahora buscamos la carpeta del usuario administrador, dentro de este directorio en la carpeta Desktop, encontraremos la flag root.txt.
Ya tenemos la flag root.txt.
Si, vamos a buscar user.txt, que en este writeup lo hemos dejado hasta el final. Para ello, nos dirigimos al directorio del usuario james, y en Desktop debemos encontrar la flag.
Y ya tendriamos la máquina resuelta.
No responses yet