IIS Short File/Folder Name Disclosure: A vueltas con la enumeración de ficheros

viernes, 30 de enero de 2015

Llevamos más de año y medio investigando y trabajando en Faast y, sorprendentemente, observamos que día a día surgen vulnerabilidades que parecían cosa del pasado. Analizando diferentes técnicas de pentesting, hemos encontrado, en este caso, otras formas de explotar el fallo conocido como IIS Short Name (de 2012). Este problema permite enumerar mediante fuerza bruta los archivos, en función del código de respuesta. Sucede a consecuencia de una implementación de la compatibilidad que ofrece Windows con versiones de MS-DOS. Por lo tanto, un atacante podría enumerar el contenido de directorios y ficheros que un servidor IIS tiene alojados. Microsoft lleva años oyendo hablar de este fallo, que podría considerarse vulnerabilidad, pero no reconoce como tal.

El problema de IIS Short Name solía ser explotado mediante las peticiones por el método GET. En agosto de 2014 se descubrió que utilizando el método OPTIONS, se podía realizar una enumeración similar.


En la imagen se puede ver una pequeña prueba de concepto realizada durante la creación del plugin para Faast

El comportamiento es sencillo: cuando se realiza la petición mediante el método OPTIONS se debe tener en cuenta el código de respuesta que se obtiene. Por ejemplo, si realizamos una petición válida y conseguimos un código de respuesta X, cuando realizamos la petición no válida obtendremos un código de respuesta Y. Con esta pequeña pista del servidor, se puede ir comprobando si existen o no ciertos recursos.

En la siguiente imagen, obtenida de la evidencia que Faast proporciona al usuario cuando encuentra esta debilidad en los servidores corporativos que se están escaneando, se puede visualizar la respuesta positiva: es decir, que un fichero que existe y que ha podido ser obtenido por fuerza bruta.

Evidencia en Faast de que un fichero existe

Por el contrario, cuando un archivo no existe el código de respuesta que se obtiene es distinto. En la imagen se puede ver en redirect (302) que se obtiene cuando un archivo no existe utilizando el método OPTIONS.

Evidencia en Faast de que un fichero no existe

Teniendo en cuenta otro tipo de herramientas similares, hemos comprobado que Faast es la primera y única por ahora, que tiene en cuenta este "truco" para aprovechar el problema durante la fase de pentesting.

Cómo corregirlo

Microsoft no solucionará el problema, tan solo recomienda deshabilitar la compatibilidad hacia atrás y evitar el "soporte" para nombres cortos de ocho caracteres. Esto se consigue en el servidor, modificando el valor de la rama del registro...

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

... y estableciéndolo a 1. También puede ser recomendable deshabilitar todos los métodos que no se usen, como podría ser OPTIONS.

El negocio de las FakeApps y el malware en Google Play (X): Tráfico de Apps entre desarrolladores

lunes, 26 de enero de 2015

Todo se compra y se vende. Obviamente, las apps pueden ser vendidas a usuarios, pero lo que no es tan conocido es el mercado de venta entre desarrolladores. Una vez conseguida una masa sustancial de usuarios, la aplicación gana un valor considerable... para los creadores de adware. La estructura de autenticación de Android facilita esta situación. Veamos cómo.

No es una situación fuera de lo común, ni siquiera fuera del mundo del móvil. Las aplicaciones, programas o cualquier utilidad que funcione y genere cierto número de usuarios, suscita el interés de los que pretenden comerciar de forma más agresiva y quieren una base de usuarios ya nutrida. Pasa con los dominios que se revenden al mejor postor, los programas que se convierten en adware tras la venta de su creador (un caso muy conocido fue esta historia de un creador de extensiones de Chrome)... en la mayoría de los casos, el usuario puede elegir qué hacer, si actualizar a la versión comercial o mantenerse con la original. En Google Play puede que se actualice automáticamente, y esta es la gran diferencia.


Le dieron "cuatro cifras" por una extensión que tardó una hora en crear

Cómo funciona la actualización Google Play

Cuando un desarrollador sube una app a Google Play, la firma con un certificado. Ya hemos hablado de que Google Play acepta certificados autofirmados, por tanto ha desvirtuado por completo el uso de esta herramienta de identidad, y en realidad no se usa para autenticar al desarrollador. La utilidad que le da el market es otra. Para poder actualizar de una app descargada previamente de Google Play, son necesarias tres condiciones:
  • Que mantenga el mismo nombre de paquete.
  • Que se incremente el número de versión (no la cadena, sino el código).
  • Que esté firmada con el mismo certificado.

Dadas estas condiciones, y según configures un terminal, un buen día una app que en su momento fue descargada de Google Play, se actualizará. Si la nueva versión no incrementa los permisos de la anterior, será de forma automática. Si añade algún permiso, la actualización pedirá permiso.

Dado este escenario, ¿qué ocurre si un desarrollador pierde o vende su cuenta, su app y su certificado a un tercero? Este nuevo dueño podrá actualizar a una nueva app a todos los usuarios de forma automática. La app no tiene por qué parecerse a lo que fue. Solo mantener el packagename, incrementar la versión, y firmar. Si añade permisos, al usuario le aparecerá un mensaje. Si no, todo el proceso será transparente. El nuevo dueño podrá cambiar si lo desea el nombre del desarrollador en Google Play.

Y cuando una aplicación se vende, el que compra querrá rentabilizar rápidamente la base de usuarios adquirida para amortizar el gasto. La manera más veloz es inyectar adware sobre la base de usuarios, aunque cualquier escenario es válido.

Errores y problemas

Cuando se vende una app, existen varios detalles que no benefician al usuario final:

  • La URL se mantiene. Cualquier web que hable positivamente de la herramienta y ofrezca un enlace a su descarga, seguirá siendo válido.
  • Si el desarrollador ha vendido también su certificado, el nuevo dueño puede actualizar de forma transparente.
  • La puntuación se mantiene. Sigue teniendo las estrellas "históricas" que ha acumulado durante su andadura con el programador original. Aunque dados los esquemas de puntuación y las técnicas de posicionamiento, esto nunca ha sido un buen indicador.
  • Todas las apps del desarrollador antiguo pueden quedar "comprometidas" puesto que el nuevo dueño puede firmar en su nombre.

Un ejemplo reciente mencionado aquí, da una idea del negocio y de las posibilidades. Gracias a Path5 podemos conocer que el comprador, aunque intenta ocultar su identidad, tiene un histórico "interesante" de apps retiradas del mercado, además de permitir un seguimiento completo de la situación.

Anuncio de venta de una popular app

Conclusiones

Es interesante reflexionar sobre qué se vende exactamente cuando se hace un traspaso de este tipo en el market oficial. ¿La app? ¿La cuenta del desarrollador? ¿La identidad?... Habitualmente debe ser la cuenta para poder mantener el nombre de paquete y por supuesto, el certificado. Si no se vendiera el certificado, el nuevo dueño no "heredaría" los usuarios, sino que tendría que "conseguirlos de nuevo" porque no habría actualización ni notificación. Eso sí, con la imagen "de marca" ya creada.

Como hemos mencionado, esto puede ocurrir en cualquier ámbito. Programas o dominios que tienen éxito y caen en manos menos escrupulosas los habrá siempre. Lo interesante en este caso es ver cómo el mal uso de la criptografía y la forma de funcionar de del mercado facilitan situaciones que dejan desprotegido al usuario frente a instalaciones no deseadas en su sistema, sin la posibilidad de elegir.

El negocio de las "FakeApps" y el malware en Google Play (I): Introducción 
El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"
El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias
El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad
El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática
El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"
El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas
El negocio de las "FakeApps" y el malware en Google Play (VIII): Permisos en las apps
* El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?



Sergio de los Santos
ssantos@11paths.com
@ssantosv

Errores comunes en servidores TLS/SSL

viernes, 23 de enero de 2015

TLS/SSL, como una capa de seguridad imprescindible, se va extendido en los servicios de las organizaciones tales como servidores web, de intercambio de archivos, etcétera… Aunque pensada para reforzar la seguridad, debe ser auditada para que su objetivo se cumpla correctamente. En este artículo, nos proponemos explicar brevemente algunas de las incidencias de seguridad que se pueden encontrar en los certificados X509 y servidores SSL/TLS, porque es la combinación de ambas entidades y su correcta configuración, la que puede asegurar una conexión fiable y segura.

Certificado

Uno de los agentes fundamentales en la comunicación SSL es el certificado. Con él, el servidor (o cliente) se identifican. Es la forma más extendida de saber que se está conectando al servidor que se pretende cuando se negocia la conexión, y no a un impostor redirigido desde una comunicación interceptada. Dados los últimos problemas con la emisión de certificados, se ha optado por casi "estandarizar" una práctica conocida como "certificate pinning", de la que ya hemos hablado, y que se basa en recordar el certificado que debe tener un sitio, y desconfiar si ha sido modificado. Esta capa extra ayuda a evitar las conexiones con terceros que intenten suplantar al servidor. El certificado contiene información de la que se pueden extraer múltiples datos importantes, como nombres de dominios de la organización, nombres de personas físicas o direcciones... Para que un certificado sea "robusto", la configuración y valores elegidos a la hora de crearlo son importantes. Hay que tener en cuenta factores como:

  • El algoritmo de firma digital.
  • La longitud de la clave.
  • Los dominios en los que el certificado es válido.
  • Las fechas de creación y expiración del certificado.
  • La cadena de confianza del certificado.
  • ... 
Los navegadores en este sentido comienzan a rechazar certificados creados de forma poco robusta criptográficamente, sin olvidar, obviamente, la cadena de certificación que obliga a que el navegador o el sistema operativo confíe en las raíces. En caso de que el certificado no cumpla con los requisitos adecuados, el navegador del usuario mostrará una alerta de conexión no confiable. Por ejemplo esta:

Conexión no confiable en Chrome


Esta alerta puede ser generada por distintos motivos: certificados emitidos para otros dominios, falta de confianza, certificados caducados... En el caso de grandes compañías, mantener todos los certificados de centenares de servidores puede resultar complejo. En Faast se han tenido en cuenta estas debilidades que deben ser valoradas y tenidas en cuenta por las organizaciones, porque podrían derivar en un agujero de seguridad.

Evidencia de una recomendación de Faast sobre un servidor SSL

Aunque el certificado se encuentre correctamente configurado y sin problemas de seguridad, la configuración implementada en el servidor TLS/SSL puede dar lugar a que los usuarios no se encuentren correctamente protegidos. Uno de los puntos más importantes es la implementación de protocolos.

Desde hace tiempo SSL2 es considerado inseguro y no se recomienda su uso. En 2014, y desde las vulnerabilidades "Poodle" en SSL3, (CVE-2014-3566/CVE-2014-8730), este se ha unido a la lista de protocolos que se recomienda deshabilitar. La recomendación hoy por hoy es utilizar los protocolos más recientes como TLS 1.2 y habilitar la extensión de TLS_FALLBACK_SCSV para evitar que los atacantes fuercen protocolos más antiguos. Quizás no todos los clientes sean compatibles, pero cada vez representan una minoría más escasa. Los cifrados implementados por el servidor también son clave. Algoritmos considerados obsoletos o con vulnerabilidades de diseño, pueden llegar a permitir que la comunicación sea descifrada. Recientemente, se han encontrado varias vulnerabilidades graves en este sentido.

Finalmente, aunque se encuentre bien configurado, es necesario actualizar el servidor SSL para evitar vulnerabilidades. OpenSSL ha sufrido graves problemas en su código en los últimos tiempos: CVE-2014-0224 más comúnmente conocida como OpenSSL CCS (ChangeCiphersSpec) que afecta a múltiples versiones de OpenSSL y que permitía forzar un cambio de cifrado y permitir así un ataque de tipo Man In The Middle; o la conocida HeartBleed.

Todas estas vulnerabilidades y recomendaciones de seguridad que pueden afectar a la comunicación SSL/TLS, son analizadas por Faast durante un escaneo al activar los plugins relacionados con el análisis de certificados y análisis de servidores SSL. Así, todos los dominios de la organización encontrados durante la fase de descubrimiento que posean un servicio SSL serán analizados de forma automática y se podrá tener un mejor control de los servidores que necesitan mejorar su seguridad.

Oscar Sánchez
oscar.sanchez@11paths.com

Eventos Febrero

jueves, 22 de enero de 2015

Aunque el mes de febrero sólo tiene 28 días, tenemos intención de aprovecharlos bien. Además del trabajo del día a día, participaremos también en varios eventos de seguridad a los que, si no tienes otros compromisos, puedes apuntarte y acercarte a conocernos.

Esta es la lista de todos los eventos públicos en los que nuestro compañero Pablo González (@pablogonzalezpe en Twitter), Faast Project Manager de ElevenPaths, estará durante el mes de febrero:

Hackron 2015:


  • Cuándo: 13 y 14 de febrero de 2015
  • Dónde: Santa Cruz de Tenerife
  • Inicio: sábado 14 de febrero a las 10:30h
  • Sobre Hackron: «En el Congreso Hackron 2015 intentaremos despejar la duda de cuánto y cómo de vulnerables somos, la persecución de delitos telemáticos comienza ser clave para el bienestar económico y social»
  • Web oficial del evento: http://www.hackron.com/

  • En Hackron 2015, Pablo impartirá una charla sobre «Osb-rastreator: easy way for looking for bugs in open source». El contenido de la ponencia mostrará la implementación de un conjunto de scripts que permiten detectar funciones inseguras en código escrito en el lenguaje C. La detección de estas funciones no significa inmediatamente la existencia de una vulnerabilidad en el código, pero ayudan a realizar estadísticas del estado o calidad del código disponible en los repositorios utilizados por millones de usuarios. Con este sencillo sistema se pueden encontrar vulnerabilidades en el código introducidas por el uso de funciones no seguras. En muchas ocasiones las vulnerabilidades quedarán expuestas en Internet por una mala calidad en el código y servicios como nuestra tecnología Faast pueden detectarlas.

    URJC Tech Fest 2015


  • Cuándo: 4 y 5 de febrero de 2015
  • Dónde: Móstoles (Madrid)
  • Inicio: miércoles 4 de febrero a las 19:00h
  • Sobre Tech Fest: «Congreso universitario que celebra su 4ª edición, y que este año tiene como temática la Seguridad Informática»
  • Web oficial del evento: http://techfest.uacm.es/2015/

  • En este congreso, Pablo impartirá una charla sobre Identidad digital y los peligros que rodean a ésta. Durante la ponencia se tratarán implementaciones con la solución de seguridad Latch, haciendo ver distintos entornos dónde la solución fortifica el uso de nuestra identidad. Un caso peculiar que será contado es la integración de Latch en herramientas de pentesting.

    Los martes de la Ciberseguridad – IEEE ETSIT-UPM


  • Cuándo: 17 de febrero de 2015
  • Dónde: Escuela Técnica Superior de Ingenieros de Telecomunicación – UPM (Madrid)
  • Inicio: martes 17 de febrero a las 18:00h
  • Sobre IEEE: «Ciclo de conferencias en las que ponentes de índole nacional comentarán temas de interés sobre Seguridad Informática»
  • Web oficial del evento: http://zion.ieeesb.etsit.upm.es/web/new/Los-Martes-de-la-Ciberseguridad-I51.html


  • Pablo participará en el ciclo de conferencias con la charla «Wargames in your Office». Esta charla pretende mostrar exactamente los peligros que hay en el día a día dentro de una organización y de sus redes internas. La seguridad en las empresas se sustenta en normas, procedimientos, procesos, que ayudan a fortificar la seguridad. El pentesting ayuda a descubrir agujeros o fallos en los procedimientos, políticas, directivas. En esta charla se presenta el caso de un soborno a un empleado que, con una visión ligera del entorno interno corporativo, podría acceder a información muy sensible para la empresa.

    Además hará un repaso sobre cómo proteger operaciones en las que nuestra identidad digital es utilizada, gracias al uso de nuestra solución Latch.


    Y como cada martes, Chema Alonso estará en la mañana con Javi Nieves, sigue el programa:

    20: Radio [La Mañana]
    27: Radio [La Mañana]

    ¡Saludos!

    News: ownCloud Latch plugin

    martes, 20 de enero de 2015

    We have uploaded to GitHub our latest plugin for ownCloud. It makes it easier to use Latch technology with this free software similar to widely used Dropbox. You can download it form here. This is a little "how to" so you can check how easy the integration is.

    Admins have to follow the usual steps if they want to protect ownCloud with Latch:


    Steps 1, 2 and 3 are documented on the website of Eleven Paths and step 4 is going to explained in this post.

    ownCloud plugin is a zip file, copy its contents to the apps directory of ownCloud.


    ownCloud apps directory

    After copying the plugin, ownCloud administrator has to access his own account and enabled. To do so, go to the "Apps" section, tap the "+ Apps" button and go to the Latch plugin referenced as “Latch Authentication Plugin”


    Enabling Latch plugin

    After enabling the plugin, the administrator has to enter the "Application ID" and the "Secret" to the section corresponding to "Latch Configuration" under the "Admin” menu.


    Introduce the Application ID and Secret
    Latch is now ready to be used and users are ready to pair their accounts. Users with ownCloud accounts have to set their own accounts going to "Personal - Latch Account”. Type the token generated on the phone into the text box displayed on the web.

    Introduce the token generated by Latch

    A notification will be received on the phone, announcing that the account is already paired.

    Notification received after successful pairing

    Now the user may lock and unlock access to his ownCloud account and a notification on his phone will be received, warning about somebody trying to access the account

    Notification of an unauthorized access attemp

    The database

    When Latch is installed in ownCloud, ownCloud database is set to store the values needed by Latch. Specifically the oc_appconfig table stores the “Application ID” and “Secret”.


    oc_appconfig table with the Application ID and Secret

    The oc_ preferences table indicates which user account has been paired with Latch.

    oc_preferences table with the users that have already paired their accounts




    News: Nuevo plugin de Latch para ownCloud

    El equipo de desarrolladores de Eleven Paths ha creado un nuevo plugin para Latch. En este caso ha sido el de ownCloud. Se trata de una aplicación de software libre para crear un servidor de archivos en la nube, similar a Dropbox.

    Para incluir Latch en la aplicación ownCloud, los desarrolladores solo tienen que seguir los pasos habituales:

    Los pasos 1, 2 y 3 están documentados en la web de Eleven Paths, el 4 es el que se va a mostrar en este post.

    El plugin de ownCloud es un archivo .zip, el administrador de ownCloud debe copiar su contenido en el directorio apps de ownCloud.

    Elementos copiados en el directorio apps de ownCloud

    Tras copiar la carpeta latch_plugin, el administrador deberá acceder a su cuenta de ownCloud y habilitarlo. Para ello tiene que acceder a la sección "Apps" y pulsar el botón "+ Apps" y buscar el plugin de Latch referenciado como "Latch Authentication Plugin".

    Habilitando el plugin de Latch

    Tras habilitar el plugin, deberá introducir el "Application ID" y el "Secret" en el apartado "Latch Configuration" dentro del menú "Admin".


    Introduciendo el Application ID y el Secret
    Latch ya está listo para ser utilizado. Cada usuario, dentro de su cuenta de ownCloud, deberá dirigirse al apartado "Personal" y acceder a la sección "Latch Account". Ahí deberá introducir el código de pareado generado por la aplicación móvil.

    Pantalla donde se debe introducir el código de pareado generado por la aplicación Latch

    En el teléfono se recibirá una notificación indicando que la cuenta ya está pareada.

    Notificación recibida tras el pareado

    A partir de ahora ese usuario podrá bloquear y desbloquear el acceso a su cuenta de ownCloud, recibirá además una notificación en su teléfono en caso de que haya un intento de acceso fraudulento.

    Notificación de un intento de acceso no autorizado

    La base de datos

    Cuando se instala el plugin de ownCloud, se configura la base de datos de ownCloud para que almacene los valores que Latch necesita.

    Concretamente la tabla oc_appconfig almacena el "Application ID" y el "Secret" de la aplicación.

    Tabla oc_appconfig con el Application ID y el Secret

    En la tabla oc_preferences, se indica qué usuario tiene su cuenta pareada con Latch. En el campo configvalue aparece el application id del usuario.

    oc_preferences con el usuario que tiene su cuenta pareada con Latch




    Ejemplo práctico y errores cometidos: malware de macro en 2015

    viernes, 16 de enero de 2015

    El caso presentado no está destinado a describir nada fuera de lo común ni nuevo (no lo es) sino a destripar paso a paso un tipo de ataque que, en teoría y como tantos otros, no debería tener éxito en 2015. Más allá de lo sencillo o no que pueda ser el ataque, veamos uno a uno la cadena de errores, omisiones o aciertos que derivan en que esto sea posible (y rentable para los atacantes) hoy por hoy.

    El correo


    Correo a la izquierda y página oficial a la derecha
    Todo comienza con un correo que a todas luces suena sospechoso para alguien del mundo de la seguridad. Pero para una persona ajena, que se comunique en inglés, puede que no tenga nada de raro. La empresa existe (aunque el correo no, de hecho mirando las cabeceras no hay rastro de su servidor MX). La dirección física de la empresa es la correcta, y adjunta una factura... Probablemente un error, pensará el que lo recibe. ¿Qué daño puede hacer un documento? No oculta extensiones "peligrosas", es un .doc. Teniendo en cuenta el éxito que ha tenido la campaña de Cryptolocker que envía ejecutables directamente, abrir un .doc no tendría por qué "ofrecer demasiada resistencia".

    Errores hasta aquí:

    • La empresa suplantada no toma ninguna precaución contra la posibilidad de que falsifiquen su dominio. No utiliza registros DKIM o SPF en su dominio. Si lo hiciera, quizás no hubieran podido suplantar su dominio o muy probablemente caería en la bandeja de correo basura.

    Extracto de la cabecera del correo donde se ve el SPF y el MTA que envía

    • El filtro antispam del servidor que recibe no ha estado muy acertado (aunque lo está habitualmente, en este caso ha fallado llamativamente). Si la empresa hubiera usado DKIM o SPF, quizás hubiera puntuado más alto y nunca hubiera llegado a la bandeja de entrada, aunque la responsabilidad sigue siendo del filtro antispam y de la habilidad del atacante. El filtro tampoco ha detectado el servidor que envía realmente (219.92.57.145) es un MTA malicioso (no parece comprometido).
    • Los antivirus no detectan demasiado el documento por firma. Obviamente los resultados de VirusTotal pueden variar en el escritorio, pero quizás no tanto. Además, la tecnología de "macro" ya es algo muy conocido por los motores de las principales soluciones antimalware.

    Detección del .doc en VirusTotal en el momento en que fue recibido 

    El documento

    En este caso, un documento Office puede ser peligroso por dos razones.
    • Porque aproveche una vulnerabilidad en Office y al abrirla consiga ejecutar código, o...
    • ...porque contenga macros (como en los 90). Simples scripts que convierten el documento en un ejecutable, a efectos prácticos. Veamos si contiene macros.

    Extraer la macro de un documento

    Por los fragmentos que vamos viendo y sin entrar en mayor análisis, es una macro (programada con una ofuscación infernal) que no puede hacer nada bueno.

    Extracto en el que parece ofuscar y construir una cadena

    Parece que descarga un fichero de una URL a local

    Extracto de código de la macro en el que se observa código ofuscado

    En este punto parece que ejecuta algo

    Guiados por las funciones usadas, y de forma muy general, se observa la descarga y ejecución de un fichero (técnica básica). La codificación de las URL es sencilla:

    Por tanto, no cuesta deducir que intenta descargar el binario en el temporal del usuario y ejecutarlo.

    Errores hasta aquí:

    • El binario descargado es solo detectado en VirusTotal (con las mismas salvedades de antes) por Rising, el antivirus chino por excelencia. Además lo hace de forma genérica, por su empaquetamiento más que por lo que pueda o no hacer.
    • Afortunadamente, las macros están deshabilitadas por defecto... ¿o no? En Word es muy probable que sí, en Excel no tanto. Debido a que no está popularizado el hecho de firmarlas digitalmente, esto sigue siendo un problema tantos años después de que las macros fueran un grave quebradero de cabeza de seguridad generalizado.
    • ¿Por qué se deben ejecutar ficheros en la carpeta temporal? Deshabilitar el permiso de ejecución con NTFS en esa carpeta no es complejo, y puede ahorrar más de un dolor de cabeza.

    El binario

    El binario descargado finalmente instala un Cridex (o Dridex, según la versión... este es un Dridex) en el sistema y esto es muy peligroso. Es un troyano bancario, conocido. Se conecta al C&C en 74.208.11.204 a través del puerto 8080 y a partir de aquí, al infectado que realice operaciones bancarias desde el Windows con el malware, puede que le roben el dinero físicamente de su cuenta. Además de poder controlar el sistema a voluntad del atacante, por supuesto.


    Detección del binario en VirusTotal


    Errores hasta aquí:
    • Al margen de los errores más "típicos" (antivirus, IDS, cortafuegos, etc), existen páginas que recopilan información sobre los C&C conocidos. Este C&C está "documentado" como tal desde el 8 de diciembre de 2014 en sitios especializados. Y toda la subred en sitios no tan especializados, como por ejemplo Spamhaus. ¿No debería ya estar bloqueado por los administradores?  No es sencillo, pero la labor que hacen los investigadores documentando estos servidores no es trivial, por lo que habría que aprovecharla correctamente. Además de poner en marcha herramientas de prevención, los administradores podrían bloquear automáticamente y añadir en los sistemas de seguridad de las redes, las IPs documentadas de forma temprana.

      Descarga del archivo de configuración del Dridex. Curiosamente desde un IIS 8.5
    • ¿Por qué no lo han cerrado los operadores de red? ¿Se puede mantener impunemente en un hosting un C&C y un binario durante tantas semanas? Sí, ocurre. Y no necesariamente en las redes "especializadas" o "bulletproof" rusas. Este es solo un ejemplo, pero es bastante común que los C&C no se cierren en semanas.

    En resumen, un esquema de ataque típico, de finales de los 90 (no el troyano, que es avanzado, pero sí el vector de infección), observado en 2015 y con los errores más o menos de siempre, exceptuando que las macro están deshabilitadas por defecto en Office. La cadena de errores y mejoras planteadas (aunque incompleta) no hace más que evidenciar en cierta forma cuántos actores son necesarios para mejorar la seguridad global, porque no es posible hacerlo aisladamente, con un solo producto, método, proceso o política. Todos están implicados, desde los administradores de servidores hasta los de red, pasando por los responsables de segmentos de red hasta (por supuesto) los usuarios. El esfuerzo se multiplica cuando tantos deben "ponerse de acuerdo", y los resultados no se aprecian como deberían en un tiempo razonable, aunque ya exista una experiencia acumulada y soluciones concretas en muchos de los campos que abarcan este ataque.

    Así que aunque convenga recordarlo, no es sorprendente que este tipo de ataques tenga éxito. Y si estos modelos (relativamente sencillos) siguen funcionando entre una buena proporción de los usuarios y empresas... ¿Qué no se puede llegar a hacer con un mecanismo y planteamiento innovadores y mayores recursos? ¿Cuántos actores deben ponerse de acuerdo cuando el objetivo abarca a más perfiles, si cabe?

    Sergio de los Santos
    ssantos@11paths.com

    Cierre de inscripciones para Latch Plugins Contest

    jueves, 15 de enero de 2015

    Hoy, jueves 15 de enero a las 13:00 horas (hora peninsular española), finalizará el plazo de entrega de candidaturas de plugins para Latch Plugins Contest, el primer concurso de Latch que busca plugins innovadores y de utilidad para el servicio Latch. Cualquier proyecto que se presente fuera de este plazo será inválido y no podrá concursar.

    A partir de ahora, el turno es de nuestro jurado, un jurado de nivel, que estará compuesto por Chema Alonso, CEO de ElevenPaths, José Palazón, Jefe de Desarrollo de Software y Producto, David Barroso, Jefe Técnico y Olvido Nicolás, Jefa de Marketing.

    Como ya os contamos, El jurado de ElevenPaths valorará muy positivamente:


  • La creatividad, ¡esperamos que hayas dado rienda suelta a tu ingenio!
  • La utilidad de la solución, importante desarrollar algo sencillo y muy útil.
  • El esfuerzo, que para eso es una gran virtud.
  • La exhaustividad de la solución, cuánto más completa sea mejor.
  • La claridad de la documentación, y la capacidad para comunicarlo.
  • El cumplimiento de la fecha de entrega de la candidatura.

  • Además, se valorará la aceptación del plugin por la comunidad de usuarios y Desarrolladores Latch.
    Tras la fase de deliberación (y su correspondiente redoble de tambores), podrás saber si has resultado ganador de alguno de nuestros suculentos premios: hasta 10.000 dólares (en bitcoins) y además, si eres estudiante, optar a una beca de trabajo en ElevenPaths.

    ¡Estate atento! Los ganadores serán notificados por correo electrónico durante los 14 días siguientes al cierre del concurso. Después, tendrás un plazo de 10 días para aceptar el premio.
    Sigue todos los detalles en nuestro blog y a través del hashtag #LatchPluginsContest.

    Latch para Windows: Enterprise Edition (y III)

    miércoles, 14 de enero de 2015

    Tras la introducción, y la explicación de cómo configurar e instalar el plugin, pasamos en esta entrada a la configuración de la web de pareado y la sincronización, que dejarán el sistema de Latch para Windows preparado para su uso en redes corporativas.


    Configuración de la web de pareado

    Para realizar esta configuración, en el Administrador de Internet Information Services (IIS) se debe crear un sitio web para la página de pareado del dominio y se debe descomprimir el contenido de LatchForWindowsLoginWebApp.zip (ubicado en la carpeta donde se instaló el plugin) en el directorio del sitio recientemente creado.


    Descomprimir el contenido del fichero en el directorio del sitio creado

    A continuación, se debe crear un grupo de aplicación para este sitio y configurarlo para que utilice la versión 4.0 de .NET CLR. Además se debe definir en el apartado de Modelo de proceso, la identidad con la que se ejecuta. Esta identidad es la del usuario creado anteriormente y que dispone de los privilegios suficientes como para escribir en los registros remotos de los DCs del dominio. Además, el único método de autenticación habilitado en este sitio debe ser Autenticación de Windows.

    Configurar los grupos de aplicaciones

    Se recomienda, también como buena práctica de seguridad, que el rol de servidor web esté alojado en un servidor diferente a los que desempeñan el rol de controlador de dominio. En caso de que esta recomendación se aplique, se debe modificar el fichero Web.config incluido en el sitio web, añadiendo la dirección IP o nombre del PDC.

    Modificación de web.config en caso de que el servidor sea diferente al PDC

    Una vez realizado esto, será posible acceder a la web que se configuró para realizar el proceso de pareado/despareado de las cuentas de usuario. Como ya se ha mencionado anteriormente se aprovechará la Autenticación de Windows para poder acceder a este sitio, por lo que cada usuario de Windows podrá acceder y configurar únicamente su cuenta de usuario.






    Configuración de la sincronización

    Las configuraciones de sincronización, solo son necesarias cuando la infraestructura de la empresa disponga de varios controladores de dominio. Si este es el caso, todas las configuraciones y cambios siempre deberán de llevarse a cabo en el PDC.

    El primer paso de la configuración que debe realizarse es habilitar en todos los DCs el servicio de registro remoto. A continuación, debe descomprimirse el fichero LatchForWindowsLoginSync.zip ubicado en el directorio donde se instaló el plugin de Latch. Tras descomprimir este archivo debe crearse un servicio que apunte al fichero LatchForWindowsLoginSync.exe, contenido en el directorio descomprimido anteriormente. Para poder crear este servicio se debe ejecutar el siguiente comando a través de la consola:

    sc create "nombre_del_servicio" binPath="ubicación_exacta_de_LatchForWindowsLoginSync.exe" start= "auto"



    Crear el servicio que permitirá sincronizar desde los controladores de dominio


    A continuación, se configura el usuario con privilegios para modificar los valores en el registro de los controladores de dominio mencionado en los dos grupos de configuraciones anteriores. De esta forma los cambios que se produzcan tanto en la web de pareado como en el PDC, se van a replicar en los otros controladores de dominio. 



    Configurar el dominio bajo el que correrá el servicio

    Para concluir con la configuración del plugin, solo restaría abrir la aplicación de Latch para Windows en el PDC y pulsar el botón de "Sincronización". Una vez dentro, se deben añadir todos los controladores de dominio existentes. Además se debe marcar si se desea la opción de Monitorizar cambios y sincronizar automáticamente. Activar esta opción hará que se notifique a todos los DCs cualquier cambio que ocurra en el PDC. También es posible utilizar la opción de Sincronizar cada cierto número de minutos y definir un tiempo específico para el proceso de sincronización. Ambas pueden utilizarse simultáneamente si se considera oportuno.


    Configurar el sistema de sincronización desde el PDC

    Latch para Windows: Enterprise Edition (I)
    * Latch para Windows: Enterprise Edition (II)


    Umberto Francesco Shiavo
    umberto.shiavo@11paths.com

    Última llamada: ¡Entrega tus plugins para Latch!

    lunes, 12 de enero de 2015

    Esta semana, concretamente, el jueves 15 de enero a las 13:00 horas (hora peninsular española) finaliza el plazo de entrega de candidaturas de nuestro concurso de plugins para Latch. Es muy importante que lo entregues en el plazo fijado para que tu candidatura en el concurso sea válida.

    Latch Plugins Contest es el primer concurso de Latch que busca desarrollar plugins innovadores y de utilidad para Latch con el que puedes ganar hasta 10.000 dólares (en bitconis) y además, si eres estudiante, optar a una beca de trabajo en ElevenPaths.

    Si quieres saber si has resultado ganador, ¡estate atento! Los ganadores serán notificados por correo electrónico durante los 14 días siguientes al cierre del concurso. Después, tendrás un plazo de 10 días para aceptar el premio.

    Entérate de todo a través de #LatchPluginsContest y en nuestro blog.

    ¡Que la suerte te acompañe!

    En qué consiste y cómo mitigar la última elevación de privilegios en Windows 8.1

    A estas alturas, ya muchos sabréis que Google ha descubierto cómo elevar privilegios en Windows 8.1 y, una vez comunicado el problema a Microsoft, ha esperado 90 días. Tras ese tiempo y sin parche, ha hecho públicos todos los detalles. Veamos los detalles y cómo protegerse.

    El UAC

    Ya se ha hablado bastante de UAC, pero lo repasamos brevemente. Es un concepto "extraño". Microsoft promovía deliberadamente el uso de la cuenta de administrador en versiones pre-Vista. Harto de la situación, quiso que el usuario se acostumbrase a tener que usar una cuenta no privilegiada y "elevar" para las tareas más delicadas. Eso requería dos cuentas en el sistema o un sistema similar a "sudoers", pero pensó que todo eso resultaría demasiado complejo para el usuario común. Así que creó UAC... que era un administrador, que en realidad todo el tiempo se comportaba como usuario. Tenía los dos tokens de seguridad y para usar el de mayor privilegio, debía pedir permiso. En Vista, pedía "demasiadas veces" permiso, así que se quejaron los usuarios. En Windows 7, se introdujo el concepto de "autoelevación" de ciertos programas para reducir el número de "clics" necesarios para realizar tareas. Se estableció por defecto esa opción más "insegura" que en Vista... y así sigue en Windows 8, aunque mejorado.

    El fallo

    En la versión 8.1 existe una llamada de sistema llamada NtApphelpCacheControl en el archivo ahcache.sys. Se trata de cachear datos de compatibilidad de la aplicación para no tener que cargarlos cada vez que se crea un nuevo proceso de ella. Los usuarios pueden leer pero no modificar entradas de caché nuevas. Esto está reservado para los administradores, y se comprueba en la función AhcVerifyAdminContext.

    En ella existe un problema. No comprueba bien si realmente el token del usuario que llama es de administrador, porque lo lee utilizando PsReferenceImpersonationToken y luego comparando el SID del usuario con el SID de SYSTEM del sistema. Al no comprobar bien por quién se hace pasar el token, es posible tomar prestado un token de un proceso que funcione bajo SYSTEM y eludir esta comprobación. Los investigadores de Google han creado una prueba de concepto que utiliza en este caso el servicio BITS (Servicio de transferencia inteligente en segundo plano), que se ejecuta como SYSTEM. Probablemente se puede usar cualquier proceso, así que deshabilitar este servicio, aparte de impedir que funcione Windows Update cuando toque, no servirá de mucho excepto para que esta prueba de concepto en concreto no sea válida.

    La prueba de concepto

    La prueba de concepto publicada utiliza también ComputerDefaults.exe (es una herramienta nativa de Windows para asociar programas por defecto). Podría ser cualquiera que usase la "autoevaluación" de UAC. Como en Windows 7 se introdujeron los programas que autoelevan, también podría ser vulnerable, pero la estrategia quizás debería ser diferente y no lo han comprobado a fondo.

    Para encontrar programas de sistema que utilicen autoElevate, simplemente podríamos hacer:

    findstr "autoElevate" c:\Windows\System32\*.exe

    Buscar programas que "autoelevan" en el sistema
    Y muestra el contenido de su manifiesto. Aunque lo parezca, no es un fallo de UAC, no lo elude. Se basa en UAC para demostrar que su estrategia de autoelevación puede usarse como trampolín "fácil". Después de dejar 90 días a Microsoft para solucionarlo, no lo han hecho, y por tanto han publicado todos los detalles. ¿Es realmente tan complejo de solucionar? Como curiosidad relacionada, UAC por defecto también tiene un problema conocido que permite elevar privilegios en Windows 7, y nunca ha sido resuelto. Está descrito aquí.

    El problema es reproducible fácilmente, y hemos modificado ligeramente la prueba de concepto para que ejecute un cmd.exe como administrador en vez de la calculadora.

    Resultado de la elevación con la prueba de concepto. De un cmd se pasa a un cmd como administrador, sin pasar por UAC

    ¿Cómo protegerse?

    Puesto que no hay parche aún, una forma de mitigar el efecto de la prueba de concepto es la que siempre debió haber sido: aumentar el nivel de seguridad de UAC para que los programas con "autoElevate" no "autoeleven" privilegios. Esto se debería estar haciendo desde los tiempos de Windows 7. Simplemente consiste elevar la palanca de configuración de UAC. Los efectos secundarios serán volver al modo "Windows Vista" y que el sistema "pregunte" más a menudo si se quiere usar el token de administrador. Nada grave.

    Elevar la seguridad de UAC. Imprescindible en Windows 7 y recomendable en Windows 8

    Incluso mejor, no usar UAC, sino usuarios separados: un administrador y un usuario. Este es probablemente el escenario más habitual en entornos corporativos y por lo que esta prueba de concepto quizás no sea tan "eficaz" en ellos.

    Pero cuidado, hemos dicho que esto no es una evasión "pura" de UAC, por tanto elevar la seguridad de UAC sirve para eludir la prueba de concepto pública en 8.1 y para que UAC tenga sentido en Windows 7.

    ¿Y si se utilizan usuarios separados? Pues los descubridores dicen que tienen otra prueba de concepto basada en el mismo fallo, no pública, válida para 8.1 de 32 bits y que permite a cualquier usuario convertirse en SYSTEM independientemente de cómo esté configurado UAC.  De hecho, usaron UAC en la PoC inicial simplemente por demostrar el problema sin invertir mucho más esfuerzo. Esta PoC "avanzada" resultaría mucho más seria pero no la han hecho pública, aunque quizás han dado las pistas necesarias para que un atacante pueda empezar a investigar el asunto. Mientras, para los "atacantes" que se limiten a intentar usar la prueba de concepto ya publicada, con elevar UAC se estará un poco más seguro. Aunque ciertos motores están ya detectando la PoC para bloquearla, igualmente esto solo detendrá a los atacantes menos hábiles. En cualquier caso, parece que Microsoft lo solucionará en cuanto pueda, y de raíz.


    Sergio de los Santos
    ssantos@11paths.com 

    Nuestro criptograma tiene solución y ganador

    viernes, 9 de enero de 2015

    ¿Se os ocurre una mejor manera de empezar el año que repartiendo el premio que escondía nuestro criptograma? Sois muchos los valientes que os habéis atrevido con él, pero sólo uno quién ha logrado descifrarlo y ser más rápido que el resto.

    El criptograma a descifrar era el siguiente:


    Nuestro objetivo con la animación gráfica era únicamente despistar. Muchos pensasteis que ese era el camino para descifrar el criptograma. Sin embargo, la solución era mucho más sencilla. Las respuestas ingeniosas han sido numerosas:
    • Murciélago
    • Divertirse
    • Feliz2015
    • happyxmas
    • Cuidado cuando te Globalices
    • La respuesta es "TELEFONO MOVIL"
    • C1U es un micrófono
    • QT es un sistema operativo
    • MO6 es un teclado
    • GZ es una cámara
    Y también generadas de la creatividad de una noche larga de nochebuena:
    • “Sin usar mis conocimientos de criptografía diría que la respuesta es : TeLeFoNiCa (o publicidad subliminal) P.D.: Disculparme si me equivoco pero estoy combatiendo la resaca con unos churros con chocolate XD”
    Llegados a este punto, vamos a desvelar los pasos que había que seguir para descifrar la solución y el premio que escondía nuestro criptograma:
    • El primer paso a considerar para descifrar el criptograma es su tamaño. Es un criptograma pequeño, por tanto, para facilitar su descifrado el método utilizado debería ser un procedimiento sencillo.
    • En un primer vistazo se observa que no hay caracteres repetidos, lo cual podría suceder si se hubiera realizado una sustitución monoalfabética (sustituir un carácter de texto en claro siempre por el mismo carácter en el criptograma), por ejemplo, utilizando el algoritmo criptográfico César. Esto podría suceder, aun siendo el criptograma pequeño, para caracteres muy frecuentes. Por ejemplo, en español la vocal e.
    • Descartada esa opción, una vía de investigación sería analizar otro tipo de algoritmos de sustitución. Por ejemplo, algoritmos de sustitución polialfabética:



    • Entre los algoritmos de sustitución más famosos destaca el algoritmo de Vigenère.
    • Su funcionamiento es muy sencillo. Generamos un alfabeto con los distintos caracteres que pueden estar presente en el texto en claro. Cada carácter tendrá una posición en ese alfabeto. Parece razonable que en el alfabeto también tenga presencia dígitos numéricos ya que están presentes en el criptograma.
    • El algoritmo de Vigenère utiliza una clave criptográfica que se repetirá tantas veces como sea necesario hasta completar una clave del tamaño del texto que se desea proteger.
    • El procedimiento de cifrado es muy sencillo. Se alinea texto en claro y clave criptográfica, y cogiendo carácter a carácter (un carácter del texto en claro y su carácter de la clave correspondiente) se aplica un desplazamiento en el alfabeto en función de la posición del carácter de la clave criptográfica (obtenida del alfabeto construido). Se suman posiciones al cifrar, se restan al descifrar.
    • Existen diferentes formas de obtener la solución. Veamos una de ellas:

      Construimos el alfabeto (se adjunta en corchetes su posición en el alfabeto) formado por 26 letras (sin la Ñ) y 10 dígitos numéricos. En total, 36 caracteres (posiciones que van de la 0 a la 35)

      A[0] B[1] C[2] D[3] E[4] F[5] G[6] H[7] I[8] J[9] K[10] L[11] M[12] N[13] O[14] P[15] Q[16] R[17] S[18] T[19] U[20] V[21] W[22] X[23] Y[24] Z[25] 0[26] 1[27] 2[28] 3[29] 4[30] 5[31] 6[32] 7[33] 8[34] 9[35]

    • Una vez conocido el criptograma y el alfabeto solo es necesario conocer la clave empleada. En este caso, es posible utilizar un poco la imaginación o mejor aún, hacer una lista de claves candidatas basada en los productos de 11Paths. En esta ocasión, la clave criptográfica era nuestro querido LATCH.

      CRIPTOGRAMA: C 1 U Q T M O 6 G Z
      CLAVE: L A T C H L A T C H
      TEXTO: 1 1 B O M B O N E S

    • Veamos un par de ejemplos de cómo obtener la solución (11BOMBONES):

      La primera letra del criptograma C tiene la posición 2 en el alfabeto. La primera letra en la clave la L tiene la posición 11 en el alfabeto. La primera letra del texto sería la presente en el alfabeto en la posición 2-11=-9 (si el valor es negativo continuamos contando desde el final del alfabeto), es decir el carácter 1 (posición 27 o -9).

      La segunda letra del criptograma 1 (posición 27) y clave A (posición 0) da lugar al carácter en clave 1 (posición 27-0). Y así, sucesivamente.

    Pasaron varios días hasta que recibimos la respuesta ganadora, concretamente el jueves 08 de enero. Como ya anunciamos, sólo podía haber un ganador y ese sería quién además de adivinar la respuesta, fuera el primero en enviárnosla:




    And the winner is…¡Ángel Goitia!¡Enhorabuena! Los 11 bombones son para ti. Nos pondremos en contacto contigo en los próximos días vía email para indicarte cómo recoger tu premio.

    ¡Feliz viernes!

    Latch para Windows: Enterprise Edition (II)

    lunes, 5 de enero de 2015

    Tras la introducción anterior, pasamos ahora a explicar el proceso de instalación y configuración de este plugin. En general es sencillo, sin embargo hay que tener en cuenta, que es necesario llevar a cabo una serie de pasos de pre-configuración del entorno para garantizar la protección de los usuarios del dominio de una organización.

    Estos pasos se pueden dividir en tres grupos de configuraciones:
    • Configuración del dominio.
    • Configuración de la web de pareado.
    • Configuración de la sincronización entre los controladores de dominio (DCs) del dominio principal.
    Para poder realizar cualquiera de estas configuraciones, el desarrollador debe solicitar el plugin desde el apartado de Mi suscripción/Contratar del Área de desarrolladores.

    Solicitar el plugin desde el área de desarrolladores

    Una vez se haya contratado el plugin, solo queda descargarlo e instalarlo en todos los controladores de dominio. Es absolutamente necesario que este plugin sea instalado en todos los controladores de dominio existentes en la organización (en caso de que exista más de uno). Se debe a que todos ellos deben disponer de las librerías que utiliza el plugin.

    Para ello se cuenta con un enlace de descarga dentro de la aplicación creada en el proceso de adquisición de un plugin Premium mencionado anteriormente.

    Descarga del plugin desde el área de desarrolladores

    Una vez instalado el plugin se debe configurar, y para ello hay que utilizar los valores que Latch proporcionó al crear la aplicación (ID de aplicación, Secret, etc.). Aunque el plugin deba instalarse en todos los controladores de dominio, solo será necesario establecer los valores de configuración en el PDC (Primary Domain Controller). Gracias a la configuración de sincronización, estos datos serán propagados al resto. Los equipos deben reiniciarse para que las configuraciones surtan efecto.

    Configuración del PDC que se propagará al resto de controladores

    Configuración del dominio

    Una vez reiniciados los servidores, se procede a realizar el primer grupo de configuraciones. En él se establecen las directivas de grupo necesarias para garantizar su correcto funcionamiento y su aplicación sobre las distintas unidades organizativas del dominio que se desean proteger.

    En nuestro ejemplo se utilizaran dos unidades organizativas (LatchProtected y NonProtected). Como sus nombres lo indican, solo a una de las unidades organizativas en este ejemplo se le aplicarán las políticas que configuraremos a continuación.

    Se recomienda como una buena práctica crear una nueva GPO que contenga únicamente las siguientes directivas:

    • Inicio de sesión interactivo: número de inicios de sesión anteriores que se almacenarán en caché (si el controlador de dominio no está conectado) con un valor asignado de 0 inicios de sesión.
    • Inicio de sesión interactivo: requerir la autenticación del controlador de dominio para desbloquear la sesión de trabajo habilitada.

    Directivas recomendadas

    El objetivo de esta configuración es evitar la posibilidad de que se pueda acceder a la cuenta del usuario sin tener en cuenta previamente su estado de la protección, o sea, sin estar conectado a red y gracias a los datos "cacheados" en local, que no contactan con el controlador de dominio. Evitar el contacto con el servidor, significaría eludir Latch.

    En este ejemplo solo aplicaremos esta GPO que hemos asociado a la unidad organizativa LatchProtected.

    Como último paso de este grupo de configuraciones, recomendamos el crear un usuario con suficientes privilegios como para poder modificar los valores de los registros en todos los controladores de dominio. Este usuario también se utilizará en los otros dos grupos de configuraciones. En caso de no crearse este usuario deberá utilizarse el usuario Administrador del Dominio para poder realizar las funciones de pareado a través de la web y sincronización entre los controladores de dominio.

    Con estas acciones, la principal función del plugin está garantizada (Bloquear los accesos de las cuentas protegidas). Para comprobar esto basta con acceder a la aplicación de Latch para Windows, añadir alguna cuenta de usuario del dominio, parearla, y por ultimo configurar el comportamiento que debe tener dicha cuenta.

    Configuración de un usuario de dominio

    Una vez completado este proceso, al intentar acceder a esta cuenta de usuario desde un equipo del dominio, (mientras el servicio se encuentra bloqueado con Latch), se obtiene el siguiente mensaje.

    Mensaje de bloqueo a un usuario de dominio protegido por Latch

    Latch para Windows: Enterprise Edition (I)
    * Latch para Windows: Enterprise Edition (y III)

    Umberto Francesco Schiavo
    umberto.schiavo@11paths.com