Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Al igual que vimos en Terminal Services, esto puede ser realizado de manera similar en Citrix, haciendo uso del modificador InitialProgram, tal como vimos en el análisis de parámetros de un fichero ICA.

En este caso, para automatizar esta tarea, Rodol nos programó una aplicación para hacer una demo a la que, en un alarde de originalidad, la llamamos C.A.C.A. (Computer Assitant for Citrix Applications).

La aplicación necesita que se instale el cliente ICA en la máquina, y después, simplemente hay que darle un fichero de conexión ICA a un servidor, un fichero con una lista de aplicaciones a probar, y el número de threads que se quieren ejecutar en paralelo.



Figura 7: Error, el cliente ICA no instalado o no está registrada la key
Para que CACA pueda hacer uso de las librerías es necesario crear una clave de registro, que debemos instalar manualmente.



Figura 8: Regristro de la key
Una vez instalada, se crea un fichero con la lista de aplicaciones a probar en un fichero TXT. Cada aplicación en una ruta, y puede ser representada con el nombre, por si está en el path de las variables de entorno, con rutas absolutas o haciendo uso de variables de entorno como %SysteRoot% o %ProgramFiles%.



Figura 9: Diccionario con aplicaciones a buscar
Cuando la aplicación se ejecuta, realiza la conexión e intenta ejecutar la aplicación, así que se verá la respuesta por pantalla, pero no debes interactuar, CACA irá cerrando todas las aplicaciones y guardando una snapshoot de todas las respuestas, para que puedas ver el resultado.



Figura 10: Snapshots con el resultado de las imágenes
Las imágenes se guardan todas en una carpeta en la ubicación del programa, por si se quieren añadir a un informe de seguridad en proceso de pentesting.

Nosotros ya tenemos CACA lista para el próximo pentest en el que nos encontremos un CITRIX, porque además hemos visto que nos permite explorar un fallo en Citrix, que os contaremos en la siguiente parte de esta serie de artículos.

Saludos Malignos!

PD: Descarga C.A.C.A.

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
**************************************************************************************************

Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

En la primera parte, analizando los mensajes de error vimos cómo se podía saber si había o no una aplicación en un servidor Windows con Terminal Services. Sin embargo, si se analiza el mensaje de error cuando la aplicación no existe en un Windows Server 2008 se puede sacar aún más partido.

Windows Server 2008 te quiere ayudar

Cuando el error se produce al invocar una aplicación que no existe o no permitida por medio de alternateshell a un servidor Windows Server 2008, este muestra un mensaje de error, tal y como vimos en la primera parte de esta serie. Ese mensaje de error, cuando es un servidor Widnows Server 2008, viene con un botón de ayuda, porque él te quiere ayudar.


Figura 5: Ayuda en los mensajes de error en Terminal Services 2008
El problema es que ese botón muestra un panel de ayuda, que se ejecuta en el lado del servidor, lleno de enlaces que abren el navegador de Internet o de cuadros de diálogos de abrir archivos, que permiten ejecutar el explorador de ficheros. Así, cómo veremos en el tercer artículo de Hacking Remote Apps, puede llevar realizar una elevación de los privilegios permitidos por el administrador.

Sin embargo, para esta parte, digamos que, simplemente analizando el mensaje del cuadro de dialogo y viendo la ayuda, se puede saber exactamente la versión de Terminal Services y el servidor con el que se está trabajando.

Aplicaciones Ocultas en Terminal Services 2008 y el TS Web Access

Una de las formas que vimos de reconocer un servidor Terminal Server fue mediante la publicación de aplicaciones en un panel en la web. Esto lo vimos en la tercera parte del primer artículo, y en ella veíamos cómo en el código fuente aparecen los parámetros de configuración de una conexión RDP a Terminal Services 2008.


Figura 6: Aplicaciones publicadas en TS Web Access
Este entorno permite descubrir las aplicaciones que están publicadas en un servidor, e incluso pueden aparecer en la caché de buscadores que hayan indexado ese código. Sin embargo, los administradores pueden quitar las aplicaciones del menú de TS Web Access mediante una sencilla opción de esconder, tal y como se ve en la imagen siguiente.


Figura 7: Ocultar una aplicación en TS Web Access... pero no la bloquea
Lo que sucede es que eso solo oculta la aplicación en el menú, y no la elimina de la publicación. En muchos entornos es común que los administradores estén haciendo pruebas o que publique aplicación temporalmente para alguien y después, simplemente, la oculten. Sin embargo, la aplicación sigue estando publicada y cualquiera que conozca el nombre, o que haga un ataque de diccionario podría encontrarla y ejecutarla.

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
**************************************************************************************************

Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

En la primera serie de esto artículos la temática se centró en reconocer los servidores que estaban publicando servicios de aplicaciones remotas con Citrix o Terminal Services. En esta serie nos centraremos en, una vez descubierto que un equipo está ofreciendo esta posibilidad, descubrir todas las aplicaciones que se encuentran instaladas en la máquina y a las que se tiene acceso.

Fingerprinting de aplicaciones, exploiting dirigido y Evilgrade

Conocer las aplicaciones que puede tener instalado un equipo, un terminal o un servidor puede significar el que un ataque dirigido tenga éxito o no. Este hecho fue gran responsable del éxito de la FOCA al poder hacer un fingerprinting de máquinas simplemente mirando los metadatos, o un problema para los dispositivos iOS de Apple (iPhone, iPod Touch o iPad) ya que mediante el sistema de regalo de aplicaciones en iTunes se podría hacer un fingerprinting remoto de software.

Conocer el software de un servidor permite, además de hacer un ataque mediante una vulnerabilidad conocida de algún programa, hacer uso por ejemplo de ataques como Evilgrade, que pueden hacer que el equipo mismo instale una puerta trasera por medio de una actualización de software insegura. Puedes leer un ejemplo de este ataque escrito por el propio Francisco Amato, creador del framework de Evilgrade, sobre cómo hacer este ataque en un Mac OS X. Además, las aplicaciones vulnerables en una red se pueden descubrir también por medio de la técnica de DNS Cache Snooping.

Terminal Services: El fichero RDP y la ejecución de aplicaciones

Cuando se realiza una conexión a un servidor de Terminal Services, esta conexión puede realizarse para obtener un escritorio completo o solo el interfaz de una aplicación. Según la configuración del servidor y la elección del cliente, se podrá elegir la manera de realizar esta conexión.

En sistemas Windows Server 2000 o 2003, la publicación de aplicaciones de modo independiente, es decir, sin que se publique el escritorio completo del servidor no se puede realizar. Es por eso que lo que se hace es mostrar un fondo como si no hubiera desktop, pero está por debajo. Con la aparición del protocolo RDP 6.0 (y así sucede en las versiones posteriores), este comportamiento sí que está permitido, por lo que puede publicarse sólo el interfaz de la aplicación.

En cualquier caso, el cliente debe elegir el modo en que desea establecer la conexión mediante el uso del atributo remoteapplicationmode:i:0, que tomará el valor 0 si se quiere acceder al escritorio completo o 1 si solo se desea acceder a la aplicación.

En el caso de que el servidor sea un Windows Server 2000 o 2003, si el administrador ha permitido la ejecución de aplicaciones al inicio, el parámetro que hay que modificar para invocar un programa es alternate shell:s:cmd.exe, indicándole qué programa se quiere ejecutar (en este caso el cmd.exe).


Figura 1: Configuración de alternateshell
Este modificador sólo es válido cuando la conexión se esté realizando contra un Terminal Services 2000 o 2003, ya que en en caso de que se esté ejecutando una conexión contra un Terminal Services 2008 se utiliza RemoteAPP, parte de RDP 6.0 y superior.


Figura 2: Configuracion de la publicación de una aplicación en Terminal Services 2008
En este caso, el administrador publica una lista de aplicaciones para ser utilizadas en RemoteApp, y a continuación, a cada aplicación le pone un nombre y un alias, por los que podrán ser invocadas en el modificador remoteapplicationprogram:s:||EXCEL. El valor Alternate Shell existe solo para los clientes con RDP inferior a la versión 6.0, pero no tiene impacto ya que, cuando llegue al servidor Terminal Services 2008 se obtendrá un error.

Extracción de la lista de aplicaciones en Terminal Services

Para poder sacar la lista de las aplicaciones que hay un servidor Terminal Server, no importa si es en versión 2000, 2003 o 2008, basta con hacer uso de alternateshell. Si tenemos una lista de aplicaciones, podremos ir solicitando una de ellas en cada conexión y obtener tres posibles resultados:

- Ejecución de la aplicación: El servidor ejecuta Terminal Services en versión 2000 o 2003, la aplicación existe y además se puede ejecutar.

- La aplicación no existe: No se ha podido encontrar la aplicación en la ruta del servidor.


Figura 3: La aplicación no está instalada en el servidor
- No tiene permiso de ejecución: La aplicación existe, pero no se puede ejecutar.


Figura 4: La aplicación sí está instalada en el servidor
Simplemente, evaluando los mensajes de error se puede hacer una lista de las aplicaciones del servidor.

**************************************************************************************************
- Hacking Remote Apps: Descubriendo aplicaciones (1 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (2 de 3)
- Hacking Remote Apps: Descubriendo aplicaciones (3 de 3)
**************************************************************************************************

Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Remote Desktop Protocol

Es un protocolo propietario de Microsoft, gracias al cual se puede proveer a un usuario de un escritorio remoto. La primera versión de este protocolo, se gestó gracias a las negociaciones que realizaron en su día Microsoft y Citrix, para que este último, autorizase a Microsoft a incluir librerías de Citrix, para la publicación de escritorio en servidores basados en NT. A día de hoy, el protocolo se encuentra en su versión 7.0, y se incluyen algunas novedades, como son las siguientes:

• Publicación de aplicaciones (RemoteAPP)
• Cifrado en las comunicaciones
• Publicación a través de puerto 443 (HTTS Redirect)
• Publicación de servicios virtualizados

Por defecto, el puerto principal por el que opera Terminal Server, a la hora de ofertar servicios de publicación de aplicaciones y escritorio remoto, es el 3389, por lo que puede ser utilizado para descubrirlo con un escaneo nmap en la red, tal y como se vio en la parte anterior.

Para conectarse a un servidor de Terminal Services, el cliente utiliza un fichero en formato RDP en el que se configuran los parámetros de la conexión. Este fichero puede ser descubierto por su extensión utilizando Google, al igual que hacíamos con ICA.


Figura 13: Descubrimiento de ficheros RDP en Google
Utilizando BING se puede hacer algo similar, pero para este buscador es tomado como un fichero de texto, por lo que tenemos que utilizar como ancla algún parámetro dentro del fichero RDP. Si nos fijamos en el contenido del mismo, se pueden ver algunos bastante interesantes.


Figura 14: Ejemplo de fichero RDP
Remoteapplicationprogram, remoteapplicationmode, remoteapplicationname o remoteapplicationcmdline son parámetros en los que se configura, de manera distinta, el programa que se tiene que ejecutar una vez que el usuario se autentique correctamente en el servidor, y puede ser utilizado para descubrir los ficheros en BING y para descubrir algunas aplicaciones en el mismo.


Figura 15: Descubrimiento de ficheros RDP con BING
Algunos de ellos vienen ya configurados con el usuario y la contraseña, cifrada con las funciones CryptProtectData y CryptUnProtectData de crypt32.dll. Esto hace que la contraseña solo pueda ser descifrada desde el servidor, y no en el cliente, ya que la clave de cifrado y descifrado está en el servidor de Terminal Services y no en la máquina del cliente. Esto está muy bien explicado un artículo de Remko Weijnen, que además ha hecho una pequeña tool para que compruebes cómo genera los hashes con este mecanismo tu propio equipo. Probado en dos equipos distintos, los hashes son distintos.


Figura 16: RDP Password Hassher
Aunque no es posible crackear la contraseña, sí que es posible conseguir acceso con un sesión de ese usuario en el equipo remoto, para que se ejecute alguna de las aplicaciones configuradas en los parámetros vistos antes. En Internet, es posible descubrir muchos de ellos con la password cifrada configurada en el fichero.


Figura 17: Ficheros RDP con passwords en BING
Los servicios de Terminal Services pueden ser embebidos en aplicaciones web que, una vez autenticado, permiten ver la configuración de la conexión que se va a realizar, o la lista de aplicaciones disponibles, tal y como se puede ver en esta página web publicando el TSGateway.


Figura 18: Configúración de TSGateway embebida en código HTML
Por supuesto, estas búsquedas para encontrar servidores web que publican aplicaciones por Términal Services también se pueden realizar utilizando Shodan o Google. Búsquedas sencillas como pueden ser las siguientes:

• “RemoteAPP”
• “RDWEB”
• “inurl:"RDWeb/pages/" ext:aspx”

Con los ejemplos vistos en este artículo, es bastante sencillo descubrir si una organización está haciendo uso de una de estas tecnologías para publicar aplicaciones o escritorios remotos utilizando Terminal Services o Citrix, que nosotros incorporamos en FOCA 2.7. En el siguiente artículo de esta serie veremos cómo hacer fingerprinting de las aplicaciones internas de un servidor, cómo saltarse políticas de seguridad y cómo hacer elevación de privilegios.

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
**************************************************************************************************

FOCA 2.7 Preview Parte 2

Además de las funciones nuevas que ya os conté en el artículo de FOCA 2.7 Preview Parte 1, también trae nuevas estas características.

Búsqueda de puertos de squid Proxy

Hemos añadido el puerto 3128 para la búsqueda de servidores proxy en los equipos de los dominios, ya que es el que habitualmente utiliza el servidor Squid Proxy, así que en las opciones de búsqueda de servidores Proxy ya se puede seleccionar.


Figura 1: Opciones para Squid Proxy
Uso de NetRange para descubir servidores

Ahora, por cada dirección IP que se encuentra, se realiza la pregunta a los registradores de IP, como ya habíamos anunciado, para obtener el tamaño del NetRange.


Figura 2: NetRange de la dirección IP
Por defecto, FOCA añadirá todas las direcciones IP del NetRange si este es menor de 255, y realizará las búsquedas de todos los servicios en esas direcciones, pero si se quiere hacer con un dominio más grande, se puede seleccionar el las opciones hacerlo para todos.


Figura 3: Scanneo solo de rangos de menos de 255 direcciones IP
Soporte para ficheros ICA y RDP

Cómo os puse ayer, Juanito y yo vamos a hablar en la Defcon de Terminal Services y Citrix, y por eso se ha añadido un módulo que aprovecha la información relativa a usuarios y servidores automáticamente en FOCA. Añadiremos una opción más elaborada para hacer el fingerprinting del software que os pondremos con el siguiente artículo de Terminal Services y Citrix.


Figura 4: Análisis de ficheros RDP e ICA
Saludos Malignos!

Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Publicación web de aplicaciones Citrix

Tanto Citrix como Terminal Server, pueden publicar aplicaciones vía Web mediante un portal de conexión. Centrándonos en servidores Citrix, este portal es el que utilizarán los usuarios para conectarse a las aplicaciones corporativas de la empresa, como por ejemplo MetaframeXP, que vimos en la anterior parte de este artículo.


Figura 7: Aplicaciones publicadas en Citrix
Por regla general, el cliente Citrix, cuando necesita conocer qué aplicaciones se encuentran publicadas, utiliza un mecanismo basado en conexiones TCP para la enumeración de las mismas.

La instalación por defecto de servidores Citrix, sin embargo, habilita una funcionalidad que a día de hoy se encuentra en desuso, llamada Master Browser, utilizada por compatibilidad hacia atrás. Este servicio, que opera bajo el puerto UDP 1604, es utilizado para listar las aplicaciones publicadas.

El principal problema radica en que este servicio es accesible por parte de un usuario sin necesidad de autenticarse en el servidor, pudiendo, en la mayoría de casos, descubrir las aplicaciones que se encuentran publicadas en el servidor. Para ello, Ian Vitek, ya avisó de esto allá por el año 2002, y realizó una serie de scripts en Perl para el correcto aprovechamiento de este fallo.


Figura 8: Enumeración de aplicaciones en Citrix
Si este servicio se encuentra desactivado en el servidor, siempre se puede intentar enumerar las aplicaciones vía web, consultando los ficheros de configuración accesibles por HTTP, siempre y cuando las ACL lo permitan.

Para ello, uno de los ficheros a los que se puede acceder es el siguiente:

• Config.xml: Fichero en donde se encuentra información sobre servidores internos, sistema de autenticación, redirección de elementos, etc… En la mayoría de casos, podremos enumerar los servidores internos de la organización, gracias a este fichero.


Figura 9: Fichero Config.xml descargado por GET


Figura 10: Servidores internos en fichero config.xml
Publicación vía Kaviza

En sistemas de publicación basados en Kaviza, empresa que compró Citrix cuyo principal nicho de negocio es la publicación de escritorios en sistemas VDI para pequeñas y medianas empresas, si se configuran erróneamente las ACL de listado de aplicaciones, se permite la enumeración de aplicaciones vía HTTP. Para ello, hay que solicitar por GET la URL /dt/hdx/enum.


Figura 11: Publicación de aplicaciones bajo el sistema Kaviza
Una vez realizado el descubrimiento de aplicaciones publicadas, se puede intentar descargar el fichero de conexión ICA, invocando /dt/hdx/launch


Figura 12: Fichero ICA descubierto
**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
**************************************************************************************************

Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Búsqueda de portales Citrix

Los servicios de Citrix también pueden ser ofertados vía Web mediante la creación de portales que publican las aplicaciones o el escritorio completo. Esta característica de publicación vía web se de principalmente a evitar los problemas de puertos en conexiones remotas, haciendo que sea más fácil para todos los usuarios conectarse, o a integrar las aplicaciones dentro de un portal corporativo que oferte otro tipo de servicios.

A la hora de instalar este tipo de servicios en aplicaciones, se suelen crear unos sitios web especiales con rutas específicas que pueden ser utilizadas para descubrir los servicios de Citrix. Algunas búsquedas interesantes, utilizando el buscador de Google, son las siguientes:

- inurl:"NFuse16/login.asp"
- inurl:"NFuse17/login.asp"
- inrul:"Citrix/MetaframeXP/default/login.asp"


Figura 4: Búsqueda de portales Citrix
Estas búsquedas, se pueden realizar también utilizando Shodan como scanner para encontrar estos servicios. Por ejemplo, en el caso de los portales MetaframeXP, se utiliza un fichero llamado Nfuse.htm que redirige a la ubicación de publicacion del mismo. Basta con buscar ese fichero para encontrar el camino al servidor Citrix:


Figura 5: Búsqueda de portales Citrix en Shodan
Búsqueda de servidores Citrix por puertos con nmap

Una primera aproximación al descubrimiento de este tipo de servicios es la inclusión de escaneos específicos para intentar detectar si los servicios asociados a Terminal Server y/o Citrix se encuentran ofertando algún servicio al exterior, o para descubrirlos en una Intranet. Citrix opera de forma nativa por el puerto 1494, mientras que los servidores de Terminal Server, a la hora de ofertar servicios de publicación de aplicaciones y escritorio remoto, utilizan el puerto 3389.

Gracias a que en nmap se pueden incluir scripts personalizados, estos se pueden diseñar de forma sencilla para que guarden información sobre las direcciones IP de los servidores que tengan estos servicios publicados. Un script sencillo que realice esta función para detectar servidores Citrix y Terminal Server al mismo tiempo podría ser el siguiente:

description = [[
Script que realiza consultas a Terminal server o Citrix mediante una conexión al puerto por defecto.
]]
author = "Silverhack"
license = "Same as Nmap--See http://nmap.org/book/man-legal.html"
categories = {"discovery", "safe"}
--Requerimos ShortPort para crear el constructor
require "shortport"
--Creamos la regla de conexión con los puertos de Terminal Server y Citrix
portrule = shortport.port_or_service({1494,3389},{"citrix-ica","ms-term-serv"})
action = function(host,port)
--Abrimos un fichero de escritura
file = io.open ("ServersFound.txt","a+")
--Si el puerto al que conecta es de Citrix, escribe en un fichero la dirección IP
     if port.number == 1494 and port.service == "citrix-ica" then
     file:write ("El Host ")
     file:write (host.ip.." Tiene el puerto 1494 activo!\n")
     file:flush()
     return "Puerto ICA Abierto. Se ha introducido en el fichero."
     end
     if port.number == 3389 and port.service == "ms-term-serv" then
--Si el puerto al que conecta es de Terminal Server, escribe en un fichero la dirección IP
     file:write ("El Host ")
     file:write (host.ip.." Tiene el puerto 3389 activo!\n")
     file:flush()
     return "Puerto RDP abierto. Se ha introducido en el fichero."
     end
--Cierra el fichero
    file:close()
    end

El resultado de aplicar dicho script a una sentencia con nmap es que, al encontrarse estos puertos en un estado OPEN, guarda la dirección IP más el puerto en un fichero.


Figura 6: Búsqueda de portales Citrix y Términal Services con nmap
**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
**************************************************************************************************

Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Hoy en día, los trabajadores en su mesa de trabajo con su equipo personal asociado a una roseta o un único equipo portátil están pasando a la historia. Los sistemas tienen a estar centralizados, lo que permite un mayor control por parte de los administradores, mayor movilidad para los usuarios y un ahorro de costes.

Debido a esto, los sistemas en la nube y la publicación de aplicaciones cada día tienen más impacto en las organizaciones, que están adoptando soluciones que van desde el uso de Servicios de Virtualización de Escritorio hasta la Virtualización de Aplicaciones, pasando, como no, por la publicación de las aplicaciones a través de Internet.

La adopción de este tipo de tecnologías, existe desde tiempo ha. En el pasado, y todavía siendo funcional en muchos entornos, se pueden publicar aplicaciones gráficas en sistemas X-Windows, que securizan la conexión tunelizando el tráfico través de conexiones SSH, por ejemplo. Otras soluciones para conectarse a clientes remotos con sistemas como VNC o escritorio remoto se han utilizado durante años por los técnicos para administrar sistemas y dar soporte.

Sin embargo, las soluciones de uso remoto de aplicaciones y sistemas hoy en día son parte de la línea base de aplicaciones de negocio de las empresas que tienen necesidades de:

• Publicar aplicaciones corporativas al exterior
• Ahorrar el coste de licencias para ciertas aplicaciones
• Dar soporte a partners y colaboraciones puntuales
• Ofertar servicios B2C a clientes externos
• Eliminar problemas de movilidad

Las dos principales soluciones empleadas para este tipo de servicios son las basadas en los Terminal Services de Microsoft y Citrix XenAPP o Metaframe. Cada una de ellas se basa en protocolos propietarios que ofrecen características, en algunos casos similares y en otros disitintos, a la hora de publicar algún tipo de aplicación o escritorio.

En esta serie de artículos, abordaremos los problemas de seguridad que se pueden encontrar con ellas, que van desde cómo utilizar los sistemas en las fases de footprinting y fingerprinting, cómo elevar privilegios en un sistema a través de aplicaciones inseguras publicadas y cómo ejecutar comandos en los sistemas a través de fallos de seguridad en la configuración de aplicaciones.
 
Citrix y el protocolo ICA

Idependent Computing Architecture (ICA) es propietario de Citrix y está diseñado principalmente para ser usado en servidores de aplicaciones heterogéneos que publican las mismas aplicaciones al mismo tiempo. Gracias a esta característica, soportada por ambos servicios hoy en día, logran eliminar el problema de la plataforma utilizada y hacerlos muy atractivos para las empresas.

La publicación de aplicaciones, en ambos productos, se puede realizar de distintas maneras, entre las que destacan las siguientes:

• Publicación de ficheros de conexión con los datos de la conexión
• Publicación a través de un Panel Web
• Publicación a través de ejecutables MSI

Ficheros de conexión a Citrix

Para la correcta conexión a una aplicación publicada a través de Citrix, se suele utilizar un fichero de conexión, en donde se encuentra toda la información necesaria para acceder a la aplicación publicada. Son ficheros en formato de texto plano y, en su interior, se puede encontrar información útil para un proceso de auditoría, como son usuarios, contraseñas, direcciones IP - algunas veces internas -, puertos de conexión, rutas de aplicaciones y protocolos de conexión.


Figura 1: Fichero de configuración ICA
En los ficheros de configuración de Citrix, que tiene extensión .ICA, destacan entre otros los siguientes campos:

- HttpBrowserAddress: Es la dirección del servidor Citrix. Se usa para el descubrimiento de aplicaciones que se publican vía HTTP. En este campo puede haber varios, si hay algún balanceador de carga por ejemplo.

- Address: Almacena la dirección IP o el nombre DNS del servidor de aplicaciones. Si se ha cambiado el puerto por defecto, que es el 1494, también irá configurado.

- InitialProgram: Es la aplicación publicada. La cadena de ejecución empieza con un carácter #

- AutologonAllowed: Indica si se permite el autologon. Es muy útil para ficheros de configuración en los que aparecen valores de User y Password en la cadena de conexión.

- SSLEnable: Habilitar SSL.

- EncryptionLevelSession: Nivel de cifrado a usar.

- Username: Usuario que se va a utilizar para identificarse en el servidor de aplicaciones.

- Password: La contraseña del usuario.

- Domain: Si existe algún dominio de autenticación irá configurado en este campo.

- PersistentCachePath: Especifica dónde se va a crear la caché persistente. Si existe este parámetro, se puede descubrir el usuario por defecto de la instalación de Citrix analizando esta ruta: Documents and settings\administrator, por ejemplo.

Con el ejemplo de la Figura 1, de un solo fichero ICA se puede obtener información de las direcciones IP, los puertos de publicación, que es un sistema Windows, con una versión de Oracle, el usuario del servidor web y el usuario y password de la conexión a Oracle.

Descubrimiento de ficheros ICA con BING y Google

Estos ficheros son fácilmente descubribles a partir de Google o Bing, utilizando sencillos dorks:


Figura 2: Búsqueda de ficheros con Goolge
Como se puede ver en la Figura 2, en Google se puede sacar partido del comando ext para buscar ficheros publicados con esa extensión, y luego filtrar por cualquier parámetro de interés.

En el caso de Bing, como ya vimos en artículo de Bing Hacking, no existe el modificador ext, pero este fichero es de tipo texto plano, así que se puede filtrar por tipo de fichero TXT y luego filtrar por los parámetros del fichero. La Figura 3 muestra un ejemplo con BING que detecta un gran número de ficheros ICA publicados.


Figura 3: Búsqueda de ficheros ICA descubiertos con BING
A partir de este momento, es fácil descubrir ficheros con datos específicos configurados en ellos.

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
**************************************************************************************************