Nueva herramienta ProxyMe y ataques de cache poisoning (I)

miércoles, 30 de julio de 2014

ProxyMe es una aplicación proxy desarrollada por nuestro compañero Manuel Fernández de Eleven Paths. Será presentada durante el evento Arsenal del congreso de seguridad Black Hat, que se celebrará entre los días 2 y 7 de agosto del 2014 en Las Vegas. Veamos, en dos entradas, cómo funciona la herramienta y un uso concreto de ProxyMe. Estará disponible para su descarga una vez celebrado el congreso.

ProxyMe es un proxy HTTP/S con una arquitectura modular que permite un desarrollo ágil y rápido de plugins. Estos modifican el comportamiento de las conexiones HTTP/S que pasan a través de él y (al tratarse de un proyecto de código abierto) permite a la comunidad el desarrollo de nuevas características. La finalidad es disponer de un pequeño framework que aporte cierta flexibilidad a la hora de analizar y modificar conexiones de red HTTP/S, así como de una herramienta auxiliar para tareas de pentesting. ProxyMe cuenta ya con un repertorio de plugins que permiten realizar diferentes tipos de ataques, como por ejemplo el conocido "cache poisoning" o "SSLStrip".

Visión global y configuración clásica

Entre los métodos de conexión soportados por ProxyMe a la hora de actuar como un servidor proxy, se encuentran los siguientes (habituales entre los proxies):
  • Modo clásico: Este es el modelo de conexión proxy más conocido. Nos encontramos con este entorno cuando el cliente configura su sistema y/o navegador para que las peticiones HTTP/S pasen a través de un servidor proxy.

Arquitectura de una conexión a través de un servidor proxy

  • Modo transparente: El modo de conexión transparente a través de un servidor proxy es similar al modo clásico, pero en ete el cliente no tiene que configurar su sistema y/o navegador con la dirección del proxy. Será la puerta de enlace la que hará la función de proxy (en la mayoría de los casos).
  • Modo inverso: Este modelo de arquitectura podemos encontrarlo cuando el servidor proxy se sitúa delante de una serie de servidores web. De éste modo, los clientes están forzados a realizar las peticiones HTTP directamente contra el servidor proxy. Este decidirá, en base a determinadas reglas, a cuál de los servidores web debe reenviar la petición HTTP. Se utiliza esta arquitectura comúnmente como firewall, balanceo de carga en granjas de servidores o para cachear contenido estático.

Arquitectura de red de un proxy inverso

Estructura y configuración de ProxyMe

Una vez entendidos estos conceptos de las distintas arquitecturas que podemos encontrar al montar un proxy, será necesario configurar ProxyMe para que actúe en el modo que se desee. La configuración se encuentra localizada en el fichero "/config/configuration.xml".

La configuración de ProxyMe es simple, pero no lo suficiente como para tratarla por completo en este artículo. Por ello, nos limitamos aquí a ver cómo configurar el servidor proxy en el modo clásico y posteriormente configuraremos el plugin "CachePoison.dll" como ejemplo de ejecución de un plugin.

Para establecer el modo de conexión clásico se debe habilitar el flag "openproxy" como se muestra a continuación, e ignorar la configuración de "forwards" que solo aplica cuando se quiere que el proxy funcione en modo inverso."Openproxy" indica que un cliente podrá realizar peticiones web a cualquier servidor web a través del proxy. También es importante configurar el valor "port" que indica en qué puerto TCP estará escuchando el servicio.

Parte del fichero de configuración

Posteriormente, en las últimas líneas del fichero de configuración es posible indicar la lista de plugins que deben ser cargados al iniciar el servicio. En este ejemplo vemos que el único plugin cargado es ‘CachePoison.dll’.

Configuración de plugins

Cada uno de los plugins cargados es ejecutado en dos ocasiones. La primera ejecución se realiza sobre la petición inicial que realiza el cliente (HTTP request). La segunda ejecución se realiza sobre la respuesta del servidor (HTTP response). De éste modo, los plugins tienen un control total sobre todo el flujo que pasa a través del proxy, lo que les permite analizar y modificar cualquier dato que se reciba o se envíe. Adicionalmente los plugins están divididos en cinco capas o anillos, siguiendo una ejecución desde la capa 0 hasta la capa 5. Esto permite que haya un orden de ejecución de plugins en base a la criticidad de la tarea que realiza cada uno de ellos. A continuación se muestra un gráfico explicativo de esta arquitectura.
Flujo interno de ejecución de plugins en ProxyME

En la siguiente entrada, nos centraremos en un ejemplo de uso concreto con el plugin para realizar ataques de cache poisoning.

La puerta trasera (en iOS) de la discordia

lunes, 28 de julio de 2014

Jonathan Zdziarski, en una conferencia en el Hackers On Planet Earth afirmó que ciertos servicios de iOS no documentados oficialmente pueden ser usados para eludir el cifrado y acceder a los datos de usuario. La noticia corre en los medios: "Apple instala una puerta trasera en todos los teléfonos". Y lo cierto es que en los matices (como siempre) se encuentra la verdad. No es para tanto.

Resumiendo, Zdziarski mostró un estudio (según él, en una sala llena de "hackers") sobre servicios que llevaban ya un tiempo corriendo en iOS (e incluso en otros sistemas operativos de Apple)  y que permitían obtener información muy sensible del teléfono a terceras partes. Las intenciones del estudio/recopilación quedan aquí descritas:

Un extracto de la presentación que aclara las intenciones

Y la propuesta parece bien resumida y matizada como declaración de intenciones. También ofrece una breve lista de lo que no es el estudio, con la intención de que no se confundan los términos. Sin embargo, consigue justo lo contrario, centrar la polémica en la palabra "back door". Esta palabra no se vuelve a citar en todo el documento... excepto en el título, que es lo que todo el mundo va a leer (probablemente en exclusiva): "Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices"

Un extracto de la presentación para aclarar lo que no es

Y aquí aparece (además de en el título) por segunda y última vez la palabra. La omisión de respuesta de Tim Cook a lo que él llama "puertas traseras" parece confirmar sus sospechas. Al menos es la impresión que da en la transparencia expuesta. ¿Por qué los cita como "puertas traseras"? Parece que él mismo la elige ateniéndose a la definición de "puerta trasera" que ofrece OWASP:
  • Una entrada en el sistema que permite eludir políticas de seguridad.
  • Una forma no documentada de acceder al ordenador o los datos que contiene.
  • Una forma de entrar en el sistema protegido sin la contraseña.
Y parece que sus investigaciones pueden incluirse dentro de esas definiciones. Y no es mentira... pero tampoco es del todo cierto. Siendo estrictos, muchas funcionalidades aceptadas de gran cantidad de software, podría incluirse bajo esa definición. Incluso cualquier vulnerabilidad entraría en la segunda acepción. Si Zdziarski no quería que se confundieran los términos, apelando a la paranoia que sugiere hoy la palabra "puerta trasera", no debería haber llamado a su estudio "Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices". Tendría que haber trabajado el énfasis en que en realidad, se trata del uso (o abuso) de ciertos servicios de diagnóstico no documentados, y que para sacar provecho de ellos es necesario tener acceso al dispositivo.

Un ejercicio sano

El investigador realiza un ejercicio sano y necesario: comienza cuestionando todos los servicios que corren en iOS, preguntándose qué hacen y por qué están ahí. También cómo podrían servir a un tercero (un forense, que es su especialidad) para obtener información sensible. Teoriza sobre posibles funcionalidades y para qué pueden servir. Evidentemente, deben tener algún fin legítimo, de lo contrario, sí que estaríamos hablando de un mecanismo de espionaje. Zdziarski argumenta y se defiende frente a la confusión con dos postulados:
  • Algunos de los servicios de los que habló solo han sido explicados oficialmente después de su presentación y por tanto, tras "la acusación".
  • El problema con otros servicios encontrados en el teléfono no es que sean puertas traseras, sino grandes oportunidades de ataque porque están muy mal programados o ideados. Esto ya está expuesto en la primera imagen de la presentación.

La defensa de Apple

Apple emitió un comunicado. Fundamentalmente, algunas de las funcionalidades que cuestiona Zdziarski están pensadas para el diagnóstico profesional o para entornos corporativos, donde la información del teléfono debe estar disponible para un hipotético administrador y, bajo ciertas circunstancias controladas, es legítimo que este pueda recuperar información. Dados los titulares de los medios, sería como acusar a Microsoft de poner una puerta trasera en todos los Windows porque, bajo ciertas condiciones, un administrador de dominio puede llegar a eludir el sistema de cifrado integrado BitCrypt de un Windows. Podemos discutir sobre si están mejor o peor implementados, o si necesitan mejorar su seguridad o si su lógica contiene algún problema que permitiría aprovecharlos para algún ataque (se trataría de alguna vulnerabilidad entonces) pero no por ello podemos hablar necesariamente de "puertas traseras".

Una de las acusaciones más graves es que en realidad, se podría acceder a la información del teléfono aunque estuviera cifrada, protegida con código PIN o huella dactilar. Pero para ello el atacante debería tener acceso físico y estar conectado al teléfono a través de un sistema con el que previamente se haya pareado. Aunque luego Zdziarski explica que se puede eludir el pareo... De hecho, Apple se ha defendido alegando que son servicios necesarios para el diagnóstico, fundamentalmente. Pero Zdziarski siempre ha creído que esto iba más allá y sugirió que podría ser usado por terceros (la NSA), pero sin acusar directamente a Apple de trabajar con ellos. Quizás esta frase no ha hecho más que lanzar más leña al fuego y alimentar conspiraciones

Porque según afirma, estas funcionalidades están disponibles para todos y cada uno de los usuarios, independientemente de que se encuentren en un entorno corporativo. Y a los usuarios ni se les pregunta ni los pueden apagar. ¿Es esto una puerta trasera entonces? Es cierto que este es el punto que Apple no ha explicado realmente.

En cualquier caso Zdziarski aclara más tarde su postura, hablando de que no sugiere ningún tipo de conspiración. Que es posible que algunas compañías se hayan aprovechado de la existencia e implementación de esos servicios, y que simplemente sugiere a Apple que hay servicios que requieren una explicación más detallada y que podrían ser mejorados.

Lecciones

Zdziarski ha hecho un excelente trabajo. Pero sabía muy probablemente que sus palabras serían confundidas y quizás aprovechó el tirón mediático. Argumentar que una charla se ofrece en una sala llena de hackers es ingenuo, puesto que evidentemente sabe que sus palabras trascenderán (y serán malinterpretadas) si no se trata de una conferencia privada. Apple por su parte, simplemente defiende sus intereses, como es lógico y no parece que vaya a reconocer errores si los ha habido (no es muy abierta en ese sentido).

Zdziarski nos ha recordado algo interesante que no conviene olvidar, en cualquier caso. Los teléfonos contienen cada vez más información privada. El acceso físico es mucho más sencillo para el atacante y las posibilidades de acceder a la información son mucho mayores. En estos casos el bloqueo por PIN o huella dactilar no solucionan nada.

Pero sobre todo, que el periodismo y la industria de la seguridad están siempre "condenados a entenderse" (unos generan noticias, otros ofrecen difusión) y ambos deben realizar una mejor labor de comunicación y transparencia. Zdziarski afirma que lo explicó correctamente, dejando que la audiencia sacara sus propias conclusiones... y quizás ahí se ha originado el problema.

Sergio de los Santos
ssantos@11paths.com

El derecho al olvido y "Just delete me"

viernes, 25 de julio de 2014

Recientemente se ha podido comprobar lo difícil que es desaparecer sin dejar ni rastro en Internet. Uno de los casos más sonados es el del español Mario Costeja González, que denunció (y venció) a Google frente a los tribunales europeos en Luxemburgo. Tras una larga lucha, consiguió entre otras cosas que se pusiera el foco en el derecho al olvido, y que muchas de las grandes compañías y corporaciones cambiaran el rumbo en sus políticas de negocio y empezaran a poner a disposición de los usuarios la capacidad de poder practicar el "Habeas data".

En el caso concreto de Costeja, el epicentro de toda la polémica era una publicación del periódico digital La vanguardia, (que aún hoy puede ser vista), donde aparecía el propio afectado en una relación de subastas judiciales públicas causadas por diversos embargos.

La sentencia dictada por el tribunal de justicia europeo fue clara: El responsable directo del tratamiento de los datos personales era Google y debía proporcionar los medios, directa o indirectamente, para que los datos indexados a causa de terceros por su buscador pudieran ser eliminados. Dicho y hecho, Google se puso manos a la obra y recientemente publicó un formulario para poder ejercer el derecho al olvido de los ciudadanos.

Formulario de Google para ejercer el derecho al olvido

La sentencia judicial no sólo alcanzaba al ámbito de aplicación de Google, sino a cualquier buscador que indexase información y no pudiera proporcionar los medios para gestionarla consecuentemente. Así que Microsoft no tardó en reaccionar y ya cuenta también con su propio formulario de retirada de resultados de búsquedas. Ahora, como aporte dentro de sus "webtools", dispone de una herramienta que permite controlar cómo aparece una web en las búsquedas.

Webtool para controlar una web en los resultados de búsquedas de Bing
¿Y Facebook?

En este punto, en el que los principales buscadores han modificado su política, cambiemos de escenario. ¿Acaso no podríamos afirmar que darse de baja en una red social y eliminar los datos es practicar el derecho al olvido? Veamos un ejemplo con Facebook.

Si bien Facebook no impide a ningún usuario darse de baja, parece hacer uso de un concepto molesto, reconocido y documentado: Los "dark patterns”. Estos anti patrones de diseño engañan o desorientan al usuario para impedir que encuentre fácilmente las opciones deseadas. En el caso que nos ocupa, darse de baja en determinado servicio digital. Veamos con Facebook un ejemplo de cómo una tarea que tendría que ser sencilla, se transforma en más compleja de lo que debería.

Supongamos que una persona con perfil de usuario, sin mayores conocimientos informáticos, desea darse de baja permanentemente de la red social Facebook. Para ello, como es lógico, primero examina el entorno y piensa que esta posibilidad podría estar disponible en las opciones de configuración de su cuenta. Al llegar a la categoría "Seguridad", detecta que hay un enlace denominado "Desactiva tu cuenta".

Desactivación de cuenta en Facebook

Este enlace proporciona un formulario para desactivar la cuenta y se advierte que cierta información aún será accesible para ciertas personas. Siendo el único enlace "visible" cercano en concepto a la "baja" de la cuenta, podría dar pie al equívoco de pensar que, desactivando la cuenta, la información personal de un usuario se elimina de alguna manera.

Formulario para desactivar cuenta en Facebook

Pero lo cierto es que no es así. Desactivar la cuenta es siempre temporal, y Facebook permite que el usuario pueda volver a iniciar sesión con su usuario y clave, y activar de nuevo la cuenta. Incluso si no fuera así, Facebook sigue manteniendo los datos personales.

En realidad este no es el camino. Pensándolo bien, "desactivar", no es dar de baja. Si de verdad se quiere eliminar la cuenta de la red, adelantamos que el entorno visual de Facebook no proporciona un enlace directo para eliminar una cuenta definitivamente. ¿Cuál sería el siguiente paso lógico a dar?

Si el usuario acude a las opciones de ayuda disponibles en el entorno, debe tener cuidado. El patrón de búsqueda debe ser muy claro y no valdrán las palabras "darse de baja", sino que por ejemplo será  la "eliminación de la cuenta" la consulta que podrá ofrecerle las instrucciones para conseguirlo. Una dificultad añadida parece que de forma artificial.

Conseguir la información de baja a través de la ayuda

Incluso así, mediante la frase de búsqueda "eliminación de cuenta", Facebook proporciona el enlace "¿Cuál es la diferencia entre "desactivar" y "eliminar" mi cuenta?". Y a través de este enlace de ayuda, por fin se consigue acceder a la página de eliminación de cuenta de Facebook de forma permanente.

¿Objetivo conseguido?

Aun así, hay que tener en cuenta que Facebook establece dentro de sus términos de uso que no serán eliminados las conversaciones realizadas por el chat y otra información relevante. Aunque corresponde a cada usuario la responsabilidad de leerlos y aceptarlos, la mayoría puede que no sean conscientes.

¿Cómo obtener ayuda a la hora de borrar rastros en Internet?

Con el fin de que los usuarios pudieran disponer de más información respecto de las posibilidades de practicar su derecho al olvido, se creó el servicio Just Delete Me. Este servicio permite obtener información de lo fácil, difícil o imposible que puede resultar eliminar la información de, por ejemplo, los sitios más populares de internet.

Justdelete.me informando de la dificultad de páginas a la hora de darse de baja
Además, proporciona entre otras funcionalidades, las siguientes:
  • Fake identity generator: la capacidad de generar una identidad falsa (utilizada para enviar datos falsos en procesos de baja de determinados servicios digitales).
  • Submit a site: permite reportar sitios web y la dificultad para practicar el derecho al olvido en ellos, lo que permite generar una base de datos de conocimiento muy útil para aquellas otras personas que estén pensando en darse de alta en algún determinado sitio y desconfíen de voluntad de eliminar todo rastro digital cuando se solicite.
  • Chrome Extension "Where to delete an account": extensión gratuita para Chrome, que permite identificar rápidamente el nivel de compromiso de un sitio web respecto a la capacidad de eliminar todo dato personal de un usuario.

Extensión de Chrome "Where to delete an account"

Rubén Alonso
ruben.alonso@11paths.com

Faast: Nuevo diseño (I)

miércoles, 23 de julio de 2014

A lo largo del evento Eleven Paths Security Day el día 3 de julio se presentaron nuevas funcionalidades de Faast que se han ido desarrollando desde que se presentara el producto en el pasado Innovation Day. Una de las características más vistosas es la nueva interfaz web que ofrece el servicio. Por ello vamos a detallar en esta entrada algunas mejoras del producto, tanto de funcionalidad como de usabilidad.

Para estudiar las novedades de Faast, recorreremos paso a paso la interfaz. En primer lugar, tras el inicio de sesión, se puede mostrar o bien una pantalla de bienvenida (en caso de no disponer de ningún escaneo ya ejecutado), o bien el panel de control donde se muestran las estadísticas de los escaneos.

Pantalla de bienvenida de Faast


Panel de control de Faast


Como se puede observar en el panel de control, no solo se ha redistribuido la información ya presente en la interfaz antigua y retocado el diseño, sino que se ha sustituido una de las gráficas antiguas por lo que llamaremos "Timeline".

Gráfico del timeline de escaneos

Este gráfico representa el estado actual de la interfaz. Muestra la ejecución temporal de los escaneos en los últimos 5 dominios auditados, es decir, la fecha de inicio y finalización del escaneo (si es que se ha realizado alguno).

En el panel de control se pretende ofrecer al usuario la mayor información posible del estado del último dominio auditado, así como una visión global. En la vista de dominios se ha incorporado la información que antes se situaba en la pestaña "Log de asignación". La finalidad es unificar todos los datos relacionados con la gestión de dominios.

Gestión de dominios


Una de las novedades que se ve reflejada en la imagen anterior, es la posibilidad de crear de manera múltiple los dominios. Para conseguirlo, el usuario solo tiene que subir un fichero de texto con un dominio por línea. Se puede especificar una etiqueta para algún dominio, separando el dato por un punto y coma a continuación del dominio.

Creación múltiple de dominios

Una vez asignado algún dominio, el sistema ya está preparado para crear un escaneo.

A diferencia de la interfaz antigua, ahora se pueden observar en una misma pantalla todos los pasos incluidos en la creación de escaneos. Esto permite al usuario observar las opciones escogidas en los pasos anteriores, así como hacerse una idea general del escaneo que va a crear sin tener que esperar al paso de confirmación.

Para obtener una visión más global de la vista, podemos verla en detalle en la siguiente imagen:

Visión completa de vista de nuevo escaneo. Pulsa en la imagen para agrandar

El proceso de creación de escaneos

Paso 1: Elección de dominios

Creación de escaneos

Este paso ha sufrido grandes cambios frente a la versión anterior. En primer lugar se ha incorporado la posibilidad de crear escaneos de manera múltiple, es decir, se pueden crear varios escaneos a la vez siempre que no sea sobre dominios que ya se están analizando.

A diferencia de la vista de gesión de dominio, para crear varios escaneos a la vez solo se tienen que marcar varios dominios de la tabla. Además se permite al usuario tanto filtrar por etiqueta, como mostrar solo los dominios disponibles (considerando disponible un dominio cuando no se está realizando otro escaneo sobre él).

Y por último, se ofrece al usuario la posibilidad de marcar todos los elementos de la tabla. Más tarde, si el usuario filtra por una etiqueta concreta y presiona el checkbox de la esquina superior izquierda, se añadirán a los dominios seleccionados todos los filtrados.

Paso 2: Selección del modo de escaneo

Selección del modo de escaneo

El usuario debe en este paso elegir la configuración del escaneo, donde elegirá: el número máximo de "workers" que quiere que se utilicen durante su ejecución; la modalidad "modo continuo", "manual", "semanal" o "mensual" y si se quiere ejecutar en cualquier instante o únicamente en la franja horaria establecida en la ventana de tiempo. Algunas de estas opciones son excluyentes entre sí, por tanto se deshabilitarán siempre que no pueda ser escogido.

Una de las novedades importantes de esta vista es la ventana de tiempo. El usuario podrá escoger las horas durante las que quiere que se ejecute el análisis. Se ofrece además la posibilidad de invertir las horas seleccionadas. Veamos un ejemplo de esto: Imaginemos que se quiere crear un escaneo que únicamente se ejecute entre la 1:00 y las 23:00. Entonces en este caso se deberá indicar como sigue:

Ventana de tiempo

Si por el contrario se quiere que únicamente se ejecute entre las 23:00 y la 1:00, es decir, la franja horaria que en el caso anterior se excluyó, entonces se deberá marcar la opción "Invertir Selección".

Ventana de tiempo invertida

En este caso se estaría considerando el intervalo entre las 11 de la noche y la 1 de la mañana del día siguiente.

Paso 3: Selección de los test que se van a ejecutar

Selección de los test que se van a ejecutar

A diferencia de la interfaz antigua, ahora de forma predeterminada vienen marcados todos los test (personalizados y predeterminados) y en caso de que el usuario desee quitar alguno de ellos, solo tiene que desmarcarla.

Paso 4: Características opcionales

Elegir características opcionales para el escaneo

Este paso opcional es completamente nuevo frente a la interfaz antigua. Su funcionalidad engloba la inclusión de una descripción del análisis y la especificación de la dirección URL, usuario y contraseña de zonas internas. Esto permite a Faast descubrir más activos.

Paso 5: Confirmación

Confirmación de escaneos

En este paso se ha trabajado sobre todo en lo que a su diseño se refiere, con el fin de facilitar al usuario el acceso rápido a todos los datos. Una vez vistos los pasos de la creación de escaneos pasamos, a analizar la pantalla de los escaneos ya creados.

Lista de escaneos

Esta tabla se considera una de las grandes novedades de la nueva interfaz. Se ha unificado toda la información mediante las opciones presentes en la parte superior de la figura anterior. Estas opciones son:

  • Mostrar solo último escaneo: Al marcar todas las opciones de arriba se obtiene la información equivalente a la primera vista de la interfaz antigua, es decir, el último escaneo de cada dominio.
  • "Detenidos", "En proceso", "Finalizados" y "En espera": Al desmarcar una de estas opciones desaparecen de la lista aquellos escaneos que estén en ese estado.
  • Todos los dominios: Este desplegable permite al usuario elegir tanto un dominio concreto para filtrar la tabla, como la opción "todos los dominios".

Adicionalmente se puede filtrar la tabla escribiendo el dominio directamente en el área de búsqueda.

De manera similar a como se mostraba en la interfaz antigua, en la columna "Acción" se muestran las siguientes opciones:


Continuaremos detallando las mejoras de la interfaz de Faast en la próxima entrada.

* Faast: Nuevo diseño (y II)

Julia Llanos
julia.llanos@11paths.com

Mayhem: malware para *nix, "como si fuera un Windows"

lunes, 21 de julio de 2014

Mayhem es un malware para servidores Linux. Al margen de las discusiones estériles sobre fanáticos y escépticos que siempre levantarán este tipo de noticias, su tecnología es interesante (comparable a los bots habituales para Windows). Aunque al final, al menos desde cierto punto de vista, decepcionan sus aparentes objetivos. Veamos por qué.

Ocasionalmente se encuentra un malware más o menos sofisticado que está destinado a infectar a sistemas *nix. Normalmente orientados a servidores, ejemplos recientes son Forkitor, Effusion... Veamos ahora Mayhem (encontrado en abril de 2014 con unos 1400 bots manejados), y sus principales características a alto nivel.

Infectando y actuando

En el informe no aclara explícitamente cómo llega el malware a los servidores, pero suponemos que lo están haciendo a través de vulnerabilidades que permitan la ejecución de código en PHP. De hecho, el primer "enlace" en la cadena de malware es un script en PHP que descarga un script y lanza todo el proceso de infección. Este es el método clásico en servidores *nix. Cualquier despiste o falta de actualización en la configuración de una página PHP puede terminar en la ejecución de código PHP. Si normalmente los atacantes culminan su tarea de "conquista" del servidor subiendo una shell en PHP para controlar el sistema dentro de sus posibilidades, la diferencia es que Mayhem va mucho más allá.

Script  PHP de infección de Mayhem

El código PHP se encarga fundamentalmente de ejecutar un script llamado 1.sh con el comando "at now -f 1.sh". Este script fundamentalmente abusa de LD_PRELOAD para conseguir que una librería (shared object, los .so en Linux comparables con una DLL) se cargue antes que un programa y por tanto "enganche" funciones. Es una técnica conocida desde hace años. Mayhem en concreto reescribe la función "exit" para que sea invocada cuando se lanza el comando "/usr/bin host". Este nuevo "exit" lo que hace es "situarse" en el sistema (buscando la dirección de memoria base en memoria a partir de "ELF", y desde ahí deducir el path real) y además descargar un binario. Ese binario por último se encargará, a través de un "fork" de procesos, de comprobar que tiene conexión, borrar el ELF descargado y leer la configuración cifrada del C&C para poder empezar a trabajar. Como detalle, la configuración se encuentra cifrada en el segmento .data del objeto compartido. Una vez leída, se borra el .so y comienza la infección. Hasta aquí, lo cierto es que es similar a ciertos modelos estándar de infección de Windows, pero relativamente interesante en Linux.

Luego, Mayhem utiliza un sistema de colas más o menos complejo para poder ponerse en contacto con el C&C, enviarle la información relevante, recoger nuevos plugins, controlar el sistema, etc. Un resumen de los comandos con los que se comunica con el C&C es:
  • Comandos que envía: R (llamar al C&C y enviar información), F (requerir fichero), Q (envía datos), P (reporta su estado).
  • Comandos que recibe: F (ejecutar nueva tarea) , L (Cargar plugin), Q (enviar datos), S (parar tarea).

El disco invisible

Una característica interesante es la capacidad de crear, haciendo gala de incluso trucos antidebugging, un archivo (llamado ".sd0") oculto en memoria como un sistema de ficheros. Para comunicarse con él se usa una librería FAT16/32 libre modificada por los atacantes para poder trabajar con código cifrado. Este disco virtual oculto cifra la información con 32 rondas del algoritmo XTEA en modo ECB. La clave de cifrado varía de bloque a bloque. En este sistema de ficheros se guarda el botín, los plugins,  urls, etc.

Un sistema de plugins... ¿decepcionante?

El malware utiliza plugins. Hasta ocho se han encontrado, en forma de ficheros .so, y ninguno detectado por ningún motor antivirus (algo hasta cierto punto normal). Si analizamos para qué sirve cada uno, fundamentalmente se encuentran:

  • Plugins para encontrar páginas que sean vulnerables a problemas de RFI (Remote File Inclusion).
  • Plugins para atacar a Wordpress, encontrando usuarios válidos, páginas de login, aplicar fuerza bruta sobre páginas de login (también de Joomla)...
  • Un plugin más genérico para aplicar fuerza bruta sobre casi cualquier página y otro para cuentas FTP.
  • Otro para "crawlear" páginas o IPs (las que le dice el C&C) y extraer información.

Esta serie de posibilidades no resulta excesivamente espectacular. Ya existen miles de scripts y sitios desde donde (atacantes mucho menos sofisticados) realizan este tipo de búsquedas cuyo objetivo son sistemas muy populares como Wordpress, por ejemplo. Decenas de guías de "hacking" no hacen más que apuntar a scripts "listos para usar" que explotan fallos y listas de "dorks" para Google que devolverán páginas potencialmente vulnerables a esos fallos. Por otro lado, además, el uso de fuerza bruta es muy ruidoso y poco efectivo en general, si hablamos de objetivos jugosos. Quizás reporte cierto éxito entre páginas de usuarios comunes, pero resultaría de poco interés desde el punto de vista de un atacante de un perfil alto, a no ser que esto forme parte de una primera fase de un ataque más sofisticado que requiera de muchas máquinas "base" para conseguirlo.

Conclusiones

El sistema de infección y almacenamiento de información en disco virtual es interesante y efectivo, y hace lo que puede sin intentar elevar privilegios. Por supuesto, si el sistema se encuentra que corre como root, el sistema de comunicación con el C&C dará mucho más juego. Pero en principio el diseño de los plugins, que parecen las "tareas comunes" para las que ha sido diseñado el malware, tienen como misión encontrar páginas comunes con una configuración débil, algo que nos aleja de la idea de que fue creado con algún objetivo interesante en mente, sino que sus expectativas resultaban mucho más modestas. ¿El primer paso para reclutar agentes necesarios para otro ataque? Quién sabe.

Aunque la botnet puede ser muy potente y no se sabe cuál es su fin último, da la sensación de que el método de infección está muy trabajado, pero el botín que puede encontrar una vez funcionando desde un sistema bajo su control, no es de "buena calidad". Este botín (paginas en PHP mal configuradas, servidores FTP con contraseñas que pueden ser deducidas por fuerza bruta) es el que esperan los atacantes de un perfil mucho más bajo, que solo necesitan comprometer una página en PHP atacando un CMS desactualizado, subir una shell común y desde ahí lanzar dorks y plugins ya existentes... al alcance de cualquier atacante adolescente. De hecho no se necesitan grandes conocimientos para hacerse con un buen puñado de páginas de este tipo y controlarlas para que sirvan de lanzadera de spam, alojar phishings, etc. Son el "low hanging fruit" de los atacantes.

Sin embargo Mayhem sirve, como siempre, para recordar que es necesario asegurar los servidores (y aquí no podemos más que recomendar Faast), y que no solo existen ataques personalizados que puedan estar buscando una empresa como objetivo, sino que, como servidor basado en *nix, se puede ser víctima hasta de malware más o menos automatizado.


Sergio de los Santos
ssantos@11paths.com

Latch in Node.js... too mainstream?

viernes, 18 de julio de 2014

Hoy en día cuando comenzamos cualquier proyecto web que se precie existen unos pasos de obligado cumplimiento si queremos estar en la cresta de la ola y convertirnos en verdaderos "hipsters". Lejos quedaron las épocas donde se usaban frameworks que eran "mainstream", donde los hombres eran hombres (y las mujeres mujeres) y escribían sus propios drivers.
Node.js? Too mainstream

Actualmente estamos viviendo una carrera continua para ser más modernos: desde frameworks como Nodyn donde desarrollamos en ClojureScript que compila a JavaScript, se ejecuta en Node.js que compila a una... ¡JVM!, a infinidad de variedades de AngularJS (EmberJS, Backbone, Knockout, Ractive.js etc.), alternativas a Grunt como gulp.js, alternativas a Yeoman como FireShell, pasando por convertidores de JavaScript a CoffeeScript, o mejoras sobre el propio CoffeeScript como Six o Functional Reactive Programming como bacon.js.

Básicamente, estos son los pasos principales para desarrollar cualquier proyecto web en 2014:
  1. Escribe tweets sobre él.
  2. Fotografía tu espacio de trabajo y súbelo a Instagram.
  3. Elige tu framework JS.
  4. Configura tu MongoDB y Redis.
  5. Visita Reddit, meneame, forocoches y similares.
  6. ...
  7. Profit
Bromas aparte, es para nosotros un placer tener ya disponible un SDK de Latch para Node.js e incluso una estrategia de autenticación para PassportJS de Latch. Para los que no lo conozcan, Node.js es un framework creado en 2009 por Ryan Dahl y su desarrollo está patrocinado por la empresa Joyent (compañía que ofrece IaaS y PaaS, y entre cuyos inversores se encuentra Telefónica).

Su característica principal es que está basado en el famoso y potente motor V8 de JavaScript de Google y pretende ofrecer una forma fácil y segura de crear aplicaciones en JavaScript escalables y de altas prestaciones. De hecho una de las características que cuesta un poco al principio entender es su orientación mayoritaria a utilizar código asíncrono y basado en eventos, que puede llegar a ser más complejo que uno síncrono normal.

Si se comprueba el código del SDK de Latch veremos que, realmente, es muy sencillo (el código siguiente está extraído de index.js).

Primero tenemos que añadir las cabeceras HTTP que necesitan recibir nuestros servidores de Latch para saber que las peticiones son correctas:
Y luego simplemente hacemos la petición HTTP a nuestros servidores de Latch con la operación escogida.

Observando este último código podemos ver una parte de funcionamiento de Node.js donde se aprecia ese carácter asíncrono que se ha mencionado. La petición HTTP que realizamos (el "request") es a su vez una función donde podemos ver varios eventos; en la respuesta tenemos el evento "data", que significa que estamos recibiendo datos, y también el evento "end" que significa que ya hemos recibido todos los datos y pueden ser tratados si se quiere (o se podrían haber tratado según llegaban). También existe un evento "error" en la petición, en el caso de que hubiera algún problema con la petición HTTP.

Así de sencillo; con unas cuantas líneas tenemos implementado todo el SDK de Latch en Node.js. También hemos puesto a disposición de todos una estrategia de autenticación de PassportJS para que sea fácil su uso: Ahí mostramos ejemplos de cómo utilizar Latch, ya sea como:
En definitiva, el SDK de latch para Node.js se une a lista de SDK existentes como PHP, Java, Ruby, Python, C, .NET o PowerShell para que se puedan utilizar en todas las aplicaciones.

David Barroso
david.barroso@11paths.com

Ejemplos de fuga de información a través de web

miércoles, 16 de julio de 2014

En el proceso de desarrollo de un software (ya sea una aplicación web o un sistema de información en general), el código se suele someter a un continuo cambio que engloba despliegues en producción, reestructuraciones, actualizaciones, etcétera. Durante estas etapas de la evolución del software aumentan las posibilidades de que se produzca un error humano que pueda suponer un riesgo para la integridad y la privacidad de la información que la aplicación gestiona.

La fase de recopilación de información sobre el sitio que se está auditando es clave durante el proceso de auditoría. Cuanta mayor información posea el auditor, con mayor eficacia podrá detectar fallos y errores. Las fugas de información o código suelen proporcionar los datos necesarios para culminar o continuar ataques, dando peso a la auditoría. A continuación se muestran diversos casos que ejemplifican diversos escenarios habituales de fugas simples (pero graves) de información.

Caso 1: Conexiones a Base de datos en ficheros de respaldo

Un ejemplo clásico de revelación de información muy sensible es dejar la cadena de conexión al servidor de base de datos en una copia de seguridad del fichero con la lógica de la aplicación. En ella suele encontrarse la contraseña, y esto permite al atacante o auditor tomar control.

Conexión a base de datos MySQL

Como ejemplo de lo común que podría resultar (aunque obviamente no todos los resultados se puedan contar como una fuga), usando un buscador se pueden descubrir miles de resultados de este tipo.

Resultados al buscar por cadenas de conexión a servidores MySQL en archivos sql o bak

Caso 2: Fugas de información generadas por el sistema operativo

Es importante tener en cuenta los ficheros generados por el sistema operativo. Por ejemplo, en el caso de Linux se podría llegar a encontrar el histórico de los comandos.

Resultados al buscar archivos bash_history

Si profundizamos en las herramientas usadas por un sistema operativo podemos encontrar que editores de texto como VIM o EMACS, generan copias de seguridad ocultas .Sin el debido cuidado, esa información puede quedar pública.

Caso 3: Errores por parte del desarrollo y el despliegue de la aplicación

Es muy común encontrar fugas de información provocadas por un mal desarrollo y que como consecuencia se revele información sobre rutas internas o la propia implementación. Un ejemplo habitual son los errores mostrados por PHP.
Fuga de información generada por un error en el script PHP

En la imagen se observa una fuga de información que revela tanto la ruta interna del fichero afectado, como un parámetro al que se accede directamente:

Resultados al buscar por la fuga de información mostrada en la imagen anterior

Caso 4: Manejadores de errores

También es posible que el sitio web implemente un manejador de errores como el caso de ASP.NET, elmah (Error Logging Modules and Handlers). Este muestra los errores producidos a lo largo de la vida del servidor web y si no se ha configurado correctamente estará disponible al público accediendo al "fichero" elmah.axd:

Resultados al buscar por el manejador de errores elmah

Existes múltiples manejadores de errores para cada plataforma. Además, dependiendo del manejador mostrará mayor o menor cantidad de información. Un ejemplo para PHP sería el framework Symfony, que contiene su propio manejador de errores y muestra una traza del error muy completa junto con la línea de código afectada:

Manejador de errores Symfony

Resultados al buscar manejadores de erorres Symfony

Conclusión

Independientemente de la plataforma o el lenguaje que se utilice para el desarrollo de la aplicación, se pueden encontrar fugas de información que pueden comprometer la seguridad de la empresa y a su imagen. Es importante configurar correctamente los entornos, almacenar las copias de seguridad en lugar privado, aprovechar herramientas de control de versiones y no mantener copias innecesarias, además de revisar periódicamente los archivos públicos del servidor. Faast, como herramienta de pentesting persistente, tiene en cuenta este tipo de fugas de información (y muchas otras) que permitirían a un posible atacante conocer en mayor profundidad la aplicación y sus componentes, detectándolas y mostrando evidencias de la fuga. Al detectarla, Faast intenta extraer el mayor volumen de datos posible, incluyendo usuarios, versiones de software, servicios, rutas internas, etcétera, relacionando la fuga de información obtenida con el servidor que la contiene.

Evidencia de fuga de código mostrara en la interfaz web de Faast

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

Certificados falsos, CRLSets y sospechas

lunes, 14 de julio de 2014

Se han detectado más certificados fraudulentos que pretenden legitimar páginas falsas de Google (aunque podría hacerlo con cualquier dominio). Una entidad de confianza (para todos los Windows) ha firmado certificados falsos, lo que permite que se suplanten las páginas del buscador o que el tráfico cifrado en realidad sea visto por un tercero. Veamos algunas curiosidades.

Vuelve a ocurrir por quinta vez desde 2011, de forma muy similar. El 2 de julio, Google se percató de que se estaban usando certificados no válidos de Google, firmados por una autoridad de confianza preinstalada en Windows. En este caso, la organización gubernamental National Informatics Centre (NIC) de India, que maneja varias CA intermedias,  todas confiadas en última instancia por el "Indian Controller of Certifying Authorities (India CCA)".

Al estar incluida en el repositorio de confianza raíz de Windows, la inmensa mayoría de programas confiarán en el certificado, además de por supuesto Internet Explorer y Chrome bajo Windows. Firefox, como sigue una política diferente de en quién confiar (que se ha mostrado más eficaz) no se ve afectado. Chrome, bajo otros sistemas operativos, tampoco.

Recordemos que para esto que suponga un "daño" para un usuario, se deben dar varias circunstancias:

  • Que la víctima sea redirigida al sitio fraudulento donde se ha instalado el certificado falso. Esto puede hacerse por pharming, DNS, o cualquier otro método.
  • Aunque así ocurriese, Google utiliza certificate-pinning para sus dominios de forma predeterminada. Así que si el atacante se limitó a emitir certificados de dominios de Google con la CA de la India, y la víctima visitaba estos sitios falsos con Chrome, el sistema se hubiese quejado.

Lo que no han dejado claro aún (habría que estudiar el certificado en detalle) es si estos certificados tienen alguna restricción de uso. Si solo han sido emitidos para validar servidores, o quizás también se pueda firmar código, etc.

Ejemplo de hipotético error de certificate pinning en Chrome sobre Eleven Paths

En cualquier caso, actualmente, ya no se corre tanto peligro. Los certificados están revocados y Microsoft ha emitido el parche correspondiente, que hace que los tres certificados intermedios (y por tanto cualquier "hijo" creado ilegítimamente) pasen al estado de "no confianza". Incluso si han emitido certificados para otros dominios, y estos no están "pineados", lo más probable es que el navegador se queje. Incluso así, por si fuera poco, Google ha emitido CRLSets actualizados para Chrome que actúan automáticamente sobre el navegador.

Algunos de los certificados revocados (falta el de 2014) mostrados en el keystore de Windows


¿Qué son los CRLSets?

CRLSets es un método "rápido" de revocación que utiliza Chrome, como ellos mismo dicen, para "situaciones de emergencia". Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca. No se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Para saber qué conjunto de CRLSets está descargando Chrome en este momento, lo más cómodo es usar este programa, creado en el lenguaje Go.

Descargando y volcando el contenido del crlset1718 de Chrome
Contenido del CRLSet

Al descargar el CRLSet más reciente, se observa un JSON con varios SPKI. Luego una lista de certificados padre, seguido de números de serie de certificados. Como un número de serie se puede repetir entre certificados diferentes, se organizan de esta manera puesto que un padre no debería emitir dos números de serie iguales. En algún punto de esta lista, se encuentran ya los certificados falsificados. El uso de CRLSets no es la mejor manera de proteger de forma global a los usuarios, pero sí es un método rápido con el que Google se permite reaccionar al margen de la industria de las CA.

¿Ataque o no?

¿Por qué siempre Google? Esto ya ha pasado. Es prácticamente la misma situación que ocurrió con  el gobierno francés en enero de 2014, Comodo y Diginotar en 2011 y TurkTrust en 2013. Curiosamente, en todos estos casos suelen ser dominios de Google (y en menor medida, Yahoo) los falsificados. Esto supone un riesgo para el atacante, porque llama mucho más la atención. ¿Se han creado certificados para otros dominios diferentes? No lo sabemos. Pero poder espiar las comunicaciones con Google es sin duda un botín más jugoso para atacantes que pretendan espiar que otros que intenten lucrarse... De ahí la siguiente duda.

Ha podido ocurrir que el Indian Controller of Certifying Authorities (India CCA) haya sido atacado, o que emitiera esos certificados conscientemente con el fin de espiar y, una vez "cazado" alegue que han sido atacados. Al tratarse de una institución nacional, podría ser usado para el espionaje civil, puesto que tendría la posibilidad de redirigir el tráfico a través de sus propios DNS. Pero como hemos mencionado, el hecho de que el certificate pinning activo de Chrome esté presente, hubiera delatado rápidamente el movimiento, lo que le resta efectividad. También puede ser que solo mencionen los certificados de Google porque esta es la empresa que suele detectar el fraude en sus certificados, y se ocupe de sus propios asuntos, pero existan otros dominios falsificados "ahí fuera".

Sergio de los Santos
ssantos@11paths.com

OSX: Cómo controlar dispositivos USB con Latch desde "userland"

viernes, 11 de julio de 2014

Desde hace varias versiones de OSX es posible tener un cierto grado de control de los dispositivos USB sin necesidad de instalar ningún driver en el kernel (en OSX se llaman extensiones). Vamos a aprovechar esto para crear un hack que permita controlar los dispositivos USB con Latch sin necesidad de programar drivers ni hookear funciones. En esta entrada se mostrará el código C desarrollado internamente para conseguirlo.

Este control del núcleo, al situarse en userland nos proporciona ciertas ventajas obvias:
  • No se necesitan permisos de administrador.
  • No es necesario instalar ningún controlador, por lo que en caso de algún fallo la aplicación creada simplemente se cerrará pero no afectará a la estabilidad del sistema operativo.
Aunque en realidad sí que se está utilizando un driver en el kernel, el propio sistema operativo permite la abstracción al ofrecer una instancia de IOUSBDevice e IOUSBInterface en userland que permite interactuar con el hardware a través de una API llamada IOUSBLib.

Generalmente los USBs no están continuamente conectados a una máquina por lo que la propia API ofrece un servicio de notificaciones que avisa cuando se conecta o desconecta un dispositivo USB para poder realizar las acciones que se deseen. Ahí es donde entra Latch; si es posible detectar cuándo se conecta o desconecta un dispositivo USB, es posible crear un sistema de control de puertos USB, donde dependiendo del estado del latch configurado, se podrá permitir el uso del dispositivo en el equipo, bloquear todos o ninguno o incluso filtrar por tipo de dispositivo o dispositivo concreto.

Más allá, gracias a la versatilidad de latch sería posible filtrar por cualquier tipo de dispositivo e incluso crear diferentes latches donde por ejemplo con uno se controle la webcam y con otro el resto de dispositivos USB. O quizás permitir exclusivamente el disco USB concreto donde se realicen las copias de respaldo, pero ninguno más porque generalmente para poder identificar cualquier dispositivo USB se suele utilizar su vendorIDproductID y serial number, que en principio (aunque luego no es siempre así) son únicos. Las posibilidades son infinitas.

Es el momento de mostrar el código para entender cómo funciona, en 10 sencillos pasos...

Paso 1: Establecer la comunicación

Lo primero es crear un puerto especial para establecer la comunicación entre el kernel (I/O Kit) y la aplicación de usuario. Además es necesario configurar un bucle que esté esperando a que lleguen las notificaciones de cambios a las que será necesario registrarse más adelante:

Paso 2: Registrar las notificaciones

A continuación se deben registrar las notificaciones a las que "nos vamos a suscribir". Para ello, primero es necesario indicar qué tipo de dispositivos USB interesa. En este caso kIOUSBDeviceClassName indica que interesan todos los dispositivos USB, pero se podría indicar solamente los dispositivos de audio, de vídeo, de almacenamiento masivo, o incluso alguno en concreto.

Paso 3: Suscribirse a las notificaciones (si se conecta)

Ahora ya es posible suscribirse a las notificaciones. Primero nos suscribimos a cuándo se conecta un dispositivo USB (kIOMatchedNotification) e indicamos cuál es el callback que llamará la notificación; en este caso usb_device_added.

Paso 4: Suscribirse a las notificaciones (si se desconecta) 

Se hace lo mismo para suscribirse a las notificaciones cuando un dispositivo USB es desconectado (kIOTerminatedNotification), en este caso llamando al callback usb_device_removed.

Paso 5: Obtener la información del dispositivo

Ambos callbacks (usb_device_added y usb_device_removed) permiten realizar las operaciones que se deseen después de estas notificaciones. En este caso solamente se utilizará el primero (cuando un dispositivo USB se conecta) para poder comprobar el estado de un latch concreto que se haya configurado. Para ello primero será necesario obtener información sobre el dispositivo USB concreto; cuando llega la notificación realmente llega un objeto io_iterator_t que se debe recorrer para obtener información sobre el dispositivo USB en cuestión. En este caso se va a obtener la información del dispositivo con la función propia get_usb_device_info:

Paso 6: Recoger los datos concretos del dispositivo

Esta función obtiene información sobre el dispositivo USB. Para ello, sería necesario obtener toda la información posible:

Paso 7: Preguntar a Latch

Una vez que se han obtenido todos los datos relacionados con el dispositivo USB es cuando se debe preguntar a Latch por el estado del pestillo correspondiente para ver si se deja conectar este dispositivo o no y poder realizar la operación oportuna. La solución no es perfecta puesto que simplemente se están recibiendo notificaciones del sistema operativo pero no se posiciona en medio del proceso de conexión de un dispositivo USB, con lo que siempre va a existir una pequeña ventana (de milisegundos) entre que el dispositivo se conecta, y la operación que queramos realizar. Estas operaciones dependiendo del tipo de dispositivo pueden ser de diferente índole: por ejemplo en el caso de un disco duro USB es posible explusarlo nada más que se conecta, con lo que no se permitiría conectar el dispositivo, o en el caso de una webcam u otro USB se puede suspender el dispositivo USB, con lo que tampoco se permitiría que funcionara correctamente.

Paso 8. Expulsar el dispositivo

En el primero caso, en el del disco duro USB, es posible esperar hasta que el sistema operativo reconoce el disco duro, y una vez que lo intenta montar, ejecutar el eject para desmontarlo ipso facto. Para ello se debe saber qué dispositivo virtual ha asignado el sistema operativo al disco duro USB (generalmente disk1); esto se consigue obteniendo la propiedad kIOBSDNameKey:

Paso 9: Suspender el dispositivo

En el caso de otro tipo de dispositivo, cabe la posibilidad de suspender el dispositivo USB donde se encuentra para que no funcione. Como dato relevante, destacar que realizando pruebas con diferentes dispositivos el resultado ha resultado a veces extraño, puesto que dispositivos como una webcam sí que dejaban de funcionar, pero otros dispositivos intentaban conectarse continuamente aunque se les obligara a suspenderse. Como curiosidad podemos comentar que tanto la webcam como el teclado de los MacBook están conectados por medio de USB y por tanto es posible controlarlos como cualquier otro dispositivo USB (aunque su desconexión física es más complicada):

Paso 10: Configuración con ficheros plist

Como se ha comprobado, es posible detectar la conexión de dispositivos USB desde userland de forma rápida pero también se observa que no es la solución perfecta, puesto que no se posiciona en el medio del proceso USB y por tanto se reacciona a las notificaciones que llegan desde el kernel (I/O Kit). OSX permite realizar también la misma funcionalidad de forma más limpian utilizando XPC. Se trata de una especie de IPC (InterProcess Communication) muy poco conocida que introdujo OSX desde la versión 10.8 y permite a los procesos que se ejecutan con launchd suscribirse a estas notificaciones de I/O Kit simplemente indicándolo en su fichero plist de configuración como se ve en el ejemplo siguiente, con el que se recibirían notificaciones de conexión del dispositivo USB con vendorId 725 y productId 2794:




En definitiva, gracias a las posibilidades de Latch, y a las notificaciones que ofrece OSX en userland, se puede conseguir una forma sencilla de controlar todos los dispositivos USB del equipo, disfrutando de un mayor control de nuestra máquina y evitando por ejemplo la infección de malware o el robo de datos mediante estos dispositivos. Es una opción adecuada para las personas que no deseen  instalar ningún driver en el kernel o que no disponen de permisos de administrador en su equipo.

Para una próxima entrada explicaremos cómo realizar un mejor control de estos dispositivos, pero en este caso mediante un driver en el kernel (extensión).

David Barroso
david.barroso@11paths.com

News: El plugin de Latch para Windows ya está disponible

jueves, 10 de julio de 2014

Con este plugin, se podrá proteger el acceso a sistemas Windows, en una máquina sin conexión con otros sistemas de autenticación. El plugin puede ser descargado directamente desde aqui o aquí dependiendo de la arquitectura. Esta "edición personal" es gratuita, pero es necesario registrarse para obtener una cuenta de desarrollador con un AppId y Secret correctos si no se tiene ya. Es posible conseguirlo desde https://latch.elevenpaths.com arriba a la derecha en la "Zona de desarrolladores".

Ofrecemos un pequeño tutorial en el que se muestra lo sencillo que es utilizarlo. El único requisito es disponer de un sistema Microsoft Windows versión XP SP 3 o posterior. Para una versión profesional de este plugin, compatible con Directorio Activo, existe la versión Enterprise disponible desde aquí.

Instalación y configuración

Una vez descomprimido, se debe ejecutar latch_windows_plugin_pe_64.exe. De forma predeterminada, el plugin se añade como un programa estándar bajo la carpeta "Eleven Paths", "Latch for Windows". Normalmente se corresponderá con "C:\Program Files (x86)\Eleven Paths\Latch for Windows\" o C:\Program Files\Eleven Paths\Latch for Windows\" dependiendo de la arquitectura. Activar la casilla "Habilitado" y el pulsar sobre "Configuración de Latch".


Pulsa sobre "Habilitar" para comenzar a usar Latch para Windows

  • Se deben completar ahora los campos con los datos ID de aplicación y Secreto generados previamente en el área de desarrollador, y pulsar en "OK" . ID op. login no es un campo obligatorio.

En"Configuración de Latch", es necesario rellenar los campos con el Application ID y el Secret key


  • En la ventana principal, se debe pulsar sobre "Añadir" y escribir el nombre de usuario. Desde la app de Latch en el teléfono, se debe generar un token y rellenar el campo "Token de pareado" en las opciones de usuario. Parear y pulsar "OK".

Añadir un nombre de usuario y generar un token con la app


Generar un token de pareo para el usuario


  • El usuario se añade a la lista. Reiniciar Windows, y el plugin estará listo para ser usado.

Usuario añadido a la lista principal de usuarios protegidos


 Usando Latch

Desde ahora, el usuario podrá bloquear su cuenta Windows desde su smartphone, para que nadie pueda presentarse en Windows, incluso conociendo la contraseña.



Bloquear o desbloquear la cuenta desde el dispositivo


Incluso si la contraseña es correcta, el usuario no podrá presentarse en el equipo