QA: Pruebas para asegurar la calidad del producto software (III)

martes, 30 de diciembre de 2014

Tal y como se había comentado con anterioridad, las pruebas de calidad sobre una aplicación informática se pueden dividir siguiendo diversos criterios, y uno de ellos es según la accesibilidad que se tenga sobre los elementos del sistema a evaluar. Es allí donde entran en juego dos conceptos muy conocidos por los profesionales de seguridad informática: caja blanca y caja negra... incluso la caja gris como punto intermedio entre ellas.



Fuente: http://www.softwaretestingnet.com/2009/10/black-box-and-white-box-testing.html


Pruebas de caja blanca

Cuando nos referimos a pruebas de caja blanca hablamos de pruebas que están fuertemente ligadas al código fuente. Para realizar la batería de test en primer lugar habremos inspeccionado el código fuente y analizado todos los posibles flujos de ejecución de la aplicación, cerciorándonos en cada caso de que los resultados obtenidos sean los esperados.

Es por esto que se dice que estas pruebas están fuertemente ligadas en una implementación en concreto, ya que si ésta se modifica, por regla general las pruebas tendrán que ser modificadas y/o rediseñadas.


Fuente: http://www.calidadysoftware.com/testing/pruebas_unitarias1.php

Como puede apreciarse en la imagen de arriba, los "testers" tendremos la posibilidad de observar el funcionamiento de los diversos componentes (óvalos) y probarlos adecuadamente, además de poder verificar las dependencias, interfaces y flujos de comunicación existentes entre ellos (flechas).

Llegado a este punto suele surgir una pregunta... ¿Quién debería encargarse de hacer las pruebas? Lo más recomendable sería que sea la persona del equipo que mejor conozca el lenguaje de programación en el que se haya desarrollado el proyecto, además que debería estar familiarizado con las herramientas de depuración y pruebas útiles para ese entorno.

En la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas, como por ejemplo, las soluciones incluidas en el paquete "Mercury Interactive Software Test Tools" u otras como las bibliotecas de JUnit, NUnit para C#, CPPUnit, etc.


Esto deja en claro que dependiendo del lenguaje que se esté utilizando se pueden conseguir herramientas nativas o adaptadas a dicho lenguaje y además estas herramientas facilitan en gran medida el desarrollo de pruebas, la elaboración de casos de prueba, seguimiento de errores, etc., de forma que se pueda llevar un proceso lo más ordenado y completo posible.

  • ¿A qué niveles se aplica?

Son diferentes los criterios que se toman al respecto, ya que en realidad se puede aplicar a cualquier nivel (unidad, integración o sistema)... Sin embargo, comúnmente se suele aplicar modularmente a unidades funcionales con el objetivo de inspeccionar y verificar el comportamiento de cada uno de los elementos antes de empezar su integración dentro de un producto software como tal. Una vez que se tienen probados todos los elementos por separado, se pasa a realizar una prueba más general después de haber pasado una fase de integración, donde se comprueban los flujos existentes entre las diferentes unidades funcionales. Este criterio vuelve a ser válido si se tratan de sistemas completos donde se busca en código abierto comprobar la comunicación entre todos los subsistemas que componen un proyecto.

  • ¿Cómo se aplicaría esto a un escenario real?

Si quisiéramos brindar un caso práctico sobre el uso de pruebas de caja blanca, podríamos pensar en un sistema de revisión de código como Gerrit (sistema de integración continua).

Ciclo de control de desarrollo de software con caja blanca

Si tenemos un ciclo de desarrollo donde los programadores van incluyendo cambios sobre un proyecto base, tarde o temprano surgirá la necesidad de que exista de por medio una persona que evalúe la calidad y validez del código que se está subiendo al repositorio principal. No está de más recordar que esta persona tendrá acceso al código fuente que va a auditar en cada momento.

En la figura anterior, hemos enmarcado en azul la acción que realizaría un tester para realizar una inspección de código tras recibir una nueva actualización por parte de los desarrolladores. En este caso, si el evaluador considera que el código es correcto y funcional aceptará el cambio y este pasará a ser incluido como parte del proyecto final (en un repositorio centralizado). En caso contrario se pedirá una rectificación o "patch set" para que el cambio que se pretendía introducir sea válido tras la corrección (no se puede dar por válido un cambio tras una rectificación sin antes volver a analizar el código fuente del cambio).

Otro entorno donde comúnmente se utilizan las pruebas de caja blanca es en las auditorías de seguridad de una aplicación web, donde el cliente proporciona el código fuente de su aplicación con el fin de que encuentre el mayor número de fallos. En estos casos lo primero que se hace es comprobar el uso de buenas prácticas de seguridad incluidas en diversas guías de seguridad y manuales especializados, ejecución de herramientas automatizadas para el escaneo de vulnerabilidades... Tras esto también se realiza un procedimiento manual para verificar la validación de campos de entrada, control de usuarios, controlar la ejecución de código externo, filtraciones de información interna a través de metadatos o comentarios en el código fuente (con especial atención a cuando se hace uso de código de terceros), etc.

Pruebas de caja negra

Su definición es un poco más sencilla, ya que conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que esa función está bien realizada solamente a través de su interfaz software, panel de ejecución, etc. Es decir, de la función que desempeña la aplicación, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas.





  • ¿Cómo se aplicaría esto a un escenario real?

Tal y como se mencionó en la anterior entrada, las fábricas de pruebas son empresas especializadas en confeccionar conjuntos de test con el fin de evaluar la calidad de la aplicación que está probando. En la mayoría de los casos estas empresas solamente tienen acceso al producto final, por lo que inspeccionan todo desde afuera. Es muy interesante este punto de vista, ya que además de centrarse especialmente en el ámbito funcional se tiende a buscar indicios de mal funcionamiento a nivel de caja blanca, es decir, mala práctica a la hora del diseño. Por ejemplo inspeccionar el comportamiento "responsive", evaluar la salida tras determinadas entradas en campos de formularios o parámetros de la aplicación (algo muy utilizado en el entorno de seguridad informática, sobre todo en el sector profesional en el hacking ético), etc.

Pruebas de caja gris

Algunos analistas consideran que solamente existen los dos tipos de cajas previamente mencionados, pero algunos pocos consideramos la posibilidad de incluir en la clasificación un tercer tipo de caja que, en resumen, será una mezcla de los dos anteriores como si de una situación intermedia se tratara. En este caso utilizaremos los casos de prueba generados para los test de caja blanca, pero en un escenario de un testing de caja negra, es decir, vamos a realizar pruebas sobre elementos que a priori podrían tener problemas por la forma en la que se ha realizado la fase de integración, la complejidad de los métodos o patrones de diseño elegidos, implementación de código de terceros, etc. Y tras lo cual vamos a analizar los resultados obtenidos.

En la próxima oportunidad entraremos de lleno en las pruebas unitarias, que son consideradas un punto clave a la hora de desarrollar. Se trata de pruebas que se realizan paralelamente al desarrollo y son creadas por los propios programadores como parte de un buen proceso de desarrollo de aplicaciones informáticas.


Jhonattan Fiestas
jhonattan.fiestas@11paths.com


News: Latch es compatible con el reciente Wordpress 4.1

viernes, 26 de diciembre de 2014

Hace unos meses se liberó la versión 4.0 de este popular CMS, y hace pocas semanas la nueva versión, 4.1, llamada "Dinah". Se incluyen mejoras en muchos aspectos, como por ejemplo en el editor de entradas, en los menús y en las consultas. Además de incluir el nuevo tema "Twenty Fifteen", que es un completo gestor de sesiones, incluir más idiomas, librería multimedia mejorada, mejor adaptación a móviles...

http://trends.builtwith.com/cms

En cuanto salió la versión iniciamos las pruebas funcionales del plugin de Latch para comprobar su correcto funcionamiento, por si habían cambiado procesos internos del producto que hiciesen que el plugin no funcionase correctamente con la nueva versión.

Realizamos varias pruebas. Primero hicimos una instalación limpia desde cero de Wordpress, y tras seguir escrupulosamente el manual de instalación del plugin de Latch, comprobamos que todo se hace y funciona exactamente igual que en versiones anteriores, incluido el pareado y el OTP.

La siguiente prueba fue una actualización de un WordPress en el que ya teníamos instalado Latch. Acto seguido probamos que funcionasen tanto los bloqueos y desbloqueos como el proceso de pareado de Latch con la nueva versión. En todos los casos la respuesta fue satisfactoria. Latch funciona perfectamente con la nueva versión de WordPress.

Nuestro criptograma tiene premio

martes, 23 de diciembre de 2014


Si no te ha tocado el gordo, no te han dado cesta en tu empresa, y tampoco esperas grandes regalos estas Navidades, no te preocupes…¡nuestro criptograma tiene premio!

Sé el primero en descifrar su mensaje oculto y ponte en contacto con nosotros en contact@support.elevenpaths.com para recoger el premio.



¿Aceptas el reto? 

Eleven Paths highlights 2014

2014 ha sido un año de grandes momentos: la presentación de Latch en Mobile Word Congress, el acuerdo estratégico con Microsoft, la adquisición de las tecnologías de SmartAccess, o el lanzamiento de Path5, nuestro nuevo producto de ciberinteligencia para el entorno móvil... que sería imposible quedarnos solo con uno.

Nos hace especial ilusión compartir y repasar con vosotros los highlights de ElevenPaths en estos últimos 12 meses.

  • El ecosistema Latch no ha parado de crecer. Empezamos el año latcheando nuestra vida digital, y así fuimos “echando el pestillo”, desconectando nuestras identidades digitales en aquellos servicios web integrados con Latch. Los últimos días del mes de febrero estuvimos con Latch en Mobile Word Congress de Barcelona donde os contamos cómo algunas organizaciones de los sectores de banca, comercio, universidades y redes sociales ya han integrado sus servicios web en la aplicación de seguridad de Latch.

  • Llegó el mes de abril, el mes en el que cumplimos 12 meses. Después de un año nuestro equipo de expertos sigue trabajando con la misma pasión, lo mejor de ElevenPaths es nuestro equipo.

  • Una de las demandas más reiteradas sobre Latch ha sido desarrollar una solución para entornos empresariales. Por eso, a mitad de año en nuestro Security Day, os presentamos Latch for Windows que permite proteger toda la infraestructura de autenticación de Microsoft Windows. También os hablamos de Faast, nuestra tecnología de pentesting persistente que automatiza las técnicas y herramientas de atacantes reales. La drástica reducción de los tiempos de exposición de activos vulnerables de una organización convierte a Faast en una tecnología única. De esta manera, se ofrece un pentesting estratégico, es decir, información sobre las vulnerabilidades y debilidades que pueden afectar a sus activos, ya estén bajo su control o en sus relaciones con terceros.
Octubre ha sido quizás nuestro mes más dulce. Bajo el marco del SID2014, nuestro evento anual de innovación, revelamos muchas sorpresas:

  • Desde nuestro laboratorio de "ideas locas" lanzamos Path5, una innovadora herramienta de ciberinteligencia única en el mercado para luchar contra las amenazas del mundo móvil. Path5 (¡es tan nuevo que todavía le estamos buscando un nombre!) permite y facilita a los profesionales y expertos en seguridad la investigación en entornos de aplicaciones móviles mediante su tecnología patentada de big data y motor de correlación. Con ella, ya hemos detectado y bautizado un nuevo malware para Android previamente desconocido.

Os contamos también nuestros últimos acuerdos y alianzas con los principales líderes de la industria, empresas y tecnologías más punteras del sector, organismos públicos y Cuerpos y Fuerzas de Seguridad del Estado:

  • Firmamos un acuerdo a nivel mundial con la Unidad de lucha contra el crimen digital de Microsoft por su amplia experiencia en erradicación de malware y programas dañinos.

  • A través del acuerdo con Radware ofreceremos conjuntamente a nuestros clientes una solución de carácter único basada en Metashield Protector, que ayuda a resolver problemas reales como es la salvaguardia de la confidencialidad de los datos.

  • La alianza con el Instituto Nacional de Ciberseguridad, Incibe, ofrece a las PYMEs españolas la licencia Latch Silver gratis durante un año, ayudando a proteger sus servicios online y a estudiar la utilidad de la herramienta para su negocio.

  • Nuestra gran novedad del año ha sido la adquisición de la tecnología de SmartAccess, una de las empresas españolas líderes en desarrollo de firma digital y biométrica en dispositivos móviles más innovadoras del momento. Esta tecnología nos permite seguir trabajando en la gestión de identidad, uno de los campos más apasionantes y complejos al que nos dedicamos en el día a día en seguridad.

Con Chema sin gorro y en traje, os presentamos Latch Plugins Contest, el primer concurso Latch que premiará con 10.000 USD y/u optar a una beca de trabajo en ElevenPaths al desarrollador que cree un plugin innovador y de utilidad para Latch. Además, para ponéroslo un poquito más fácil, hemos creado los seminarios online Latch Talks.

Cerramos el año lleno de alegría y satisfacción, con agradecimiento por todo vuestro apoyo, por vuestra confianza y aliento, ya que sin vosotros, nada de esto sería posible. Al nuevo año, le pedimos desarrollar muchos más paths. Después de todo, lo tenemos claro: desde ElevenPaths queremos ofreceros la mejor oferta en seguridad, poniendo toda nuestra experiencia y capacidad de innovación en vuestras manos con servicios pioneros en el mercado, seguiremos trabajando "hasta 11". Up to eleven!




¡Felices fiestas y feliz 2015!



5.500 apps potentially vulnerable to Man in the Middle attacks in Google Play

lunes, 22 de diciembre de 2014

It has been discovered than AppsGeyser, an app creator "with just a few clicks", deactivates the SSL certificate validation in its apps. An attacker on the same network as the user running these apps, will be able to inject any page when browsing from the affected apps, or view and modify webs that should be protected. This app generator is very popular and (as they show in their own web, there have been installed almost a thousand million apps). There are 5500 AppsGeyser apps in this moment in Google Play. Let's analyze the problem, and its details.

AppsGeyser main website

AppsGeyser is a service that eases the creation of Android apps with just a few clicks. Literally, it allows users to create apps in three simple steps, so the web experience is translated to an app. This kind of applications introduce risks we have already talked about, since de programmer does not control the code and it may introduce unwanted security vulnerabilities.

In this case, AppsGeyser has deliberately introduced a function that disables the SSL certificate validation of HTTPS traffic in all apps developed from this platform. This vulnerability means that any navigation from an app created by AppsGeyser may be intercepted, forwarded, faked... No certificate from the remote server will be validated.

In order to be successful, the attacker has to be on the same local network as the victim. Then the attacker needs to access the victim’s traffic with any known technique (ARP spoofing, proxy control, gateway...) and analyze the traffic generated from any of the apps created with AppsGeyser. If an user of these apps visits an HTTPS website, the attacker would just have to introduce his own web signed with any certificate, and the victim would not notice anything. It would be like the perfect phishing. Or intercepting traffic between the victim and a secure website. Even if the victim does not explicitly visits an HTTPS webpage, the attacker could redirect him. For example, if an AppsGeyser apps visits some ads, the attacker could forward the user to a fake Facebook, Twitter, etc. webpage and ask for his password in any moment. 

5.500 vulnerable apps

By using Path5, ElevenPaths’s app markets monitorization, correlation and research product, we have been able to detect 5.532 AppsGeyser apps created and still active on Google Play. During this year, more than 7.000 have been in this official platform, what confirms its popularity. There is even a browser developed with AppsGeyser that claims to be a tool to easily visit Twitter, Amazon, Facebook... in a totally insecure way. Some antivirus already detected AppsGeyser apps as badware, no matter the app’s features.. Now it is confirmed that they have good reasons to do it. 

A browser with direct links to popular pages, created with AppsGeyser

There are some serious institutions and companies that have used this method to create its app. Even very popular apps with hundreds of thousands of downloads. There are about 50 apps created with this platform that have been downloaded more than 100.000 times.

Maybe not every single one of them is vulnerable, but we have our doubts. In order to avoid being vulnerable, the original developer should have to add or remove the SSL explicit deactivation made by AppsGeyser. The vast majority of developers that have delegated the development of an app to a third party, it is not very likely they have the needed technical level for solving it. Moreover, AppsGeyser does not tell the developer that is invalidating the SSL check. 

Why deactivating SSL? We think that is has been done to make everything easier for the creator using autosigned certificates for his web, or certificates that can not be validated by the system. AppsGeyser saves support incidents in its support system. Users will never see a "SSL validation error" with their apps. AppsGeyser disables SSL certificate validation and then they avoid problems to their support department, but jeopardizes any user of their apps.

Proof of concept

This proof of concept shows a MITM attack against an AppsGeyser app (https://play.google.com/store/apps/details?id=com.SantiniLabsWebBrowser) that allows to get encrypted traffic. The attacker has to enable IP forwarding and redirect HTTP AND HTTPS traffic to a webproxy in this machine.



Then he needs to launch an ARP spoofing attack (although any other technique would work).


The victim opens a Facebook session from the browser in the app.


The traffic is captured, although the user thinks is encrypted, since actually all is done with the non-trusted certificate in the webproxy:


The user would not be able to check the certificate from the browser, because the app does not allow this functionality.

Technical details

Technically, the failure is easy to spot. For example, we can have a look to the code from this browser created with AppsGeyser. It would be the same in any app created with this third party that have not explicitly fixed the vulnerability.

In the onCreate(…) method in the initial activity, we can find the following code snippet:



The first highlighted line, stores in the mStartupScreenViewContainer attribute the FrameLayout startupScreenContainer , that we will see when the app is launched. The second line, creates a controller from the FrameLayout with this code:


StartupScreenController class contains these attributes:


BrowserWebView will be the one in charge of showing web pages. To get it, it will need to use a WebViewClient object, established when building StartupScreenController:

You can see highlighted in this code, how BrowserWebView is recovered (in the initial activity layout) and how the WebViewClient is assigned as an instance of FullScreenBannerWebViewClient object.


As we can see, the class inherits from SimpleWebViewClient:



That in turn, inherits from WebViewClient, that, according to the Android API documentation, has the following method:


And this method is overwritten in SimpleWebViewClient with the following code, so, when an invalid SSL certificate is found, the page is still loaded with no warnings.


So, risky connections inside the apps, would be the ones from the objects that inherit from SimpleWebViewClient and BrowserWebViewClient. and provided that they do not overwrite onReceivedSslError behavior with paramSslErrorHandler.cancel().


Miguel Ángel García
miguelangel.garcia@11paths.com

Sergio de los Santos
ssantos@11paths.com

5.500 apps potencialmente vulnerables a ataques de Man in the Middle en Google Play

Se ha descubierto que AppsGeyser, un creador de aplicaciones "a golpe de clic", desactiva la comprobación de certificados SSL en sus aplicaciones. Un atacante en la misma red local que un usuario que utilice estas aplicaciones, podrá inyectar cualquier página cuando navega desde las apps afectadas, o bien ver y modificar webs que deberían estar protegidas. Este generador es muy popular y (según ellos mismos) se han instalado mil millones de apps. Existen más de 5.500 aplicaciones suyas en estos momentos en Google Play. Veamos los detalles del fallo, con los matices necesarios.

Página principal de AppsGeyser

AppsGeyser es un servicio que facilita la creación de apps de Android "a golpe de clic", basadas en un contenido web. Literalmente, permite crear programas en tres pasos, de la forma más sencilla, y así llevar a una app la experiencia web de una página. Este tipo de aplicaciones introducen riesgos de los que ya hemos hablado, pues el programador no controla el código que se inyecta, y puede desencadenar en efectos no deseados en la seguridad del usuario.

En este caso, AppsGeyser ha introducido deliberadamente una función que desactiva la comprobación de la validez de certificados SSL en todas las aplicaciones creadas desde su plataforma. Esto quiere decir que cualquier navegación realizada desde una aplicación creada con AppsGeyser, puede ser interceptada, redirigida, falseada... En ningún momento se validará el certificado del servidor remoto.

Para que el ataque tenga éxito, el atacante solo tiene que encontrarse en la misma red local que la víctima. Acceder a su tráfico a través de cualquier técnica (ARP Spoofing, tener el control de un proxy, del gateway...) y observar el tráfico generado desde las apps creadas con AppsGeyser. Si un usuario de una app de este tipo visita una web HTTPS, el atacante solo tendría que introducir su propia página firmada con cualquier certificado, y la víctima no notaría nada extraño. Sería el phishing perfecto. O situarse en medio de la navegación entre una web segura y la víctima. Aun así, si no visita ninguna página explícitamente con HTTPS, podría redirigirla. Por ejemplo, si una app de AppsGeyser visita una página de publicidad, el atacante podría redirigirle a una supuesta página de Facebook, Twitter, etc. y preguntar por las credenciales en cualquier momento.

5.500 aplicaciones vulnerables

Utilizando Path5, la herramienta de investigación, correlación y monitorización de mercados de ElevenPaths, hemos podido comprobar que existen en estos momentos 5.532 aplicaciones creadas y activas con AppsGeyser en Google Play. Durante este año, se han subido unas 7000, lo que da una idea de su popularidad. Existe incluso un navegador creado con AppsGeyser que sirve para visitar Facebook, Amazon, Twitter... de una forma totalmente insegura. Algunos antivirus ya detectaban desde hace tiempo estas aplicaciones como badware, independientemente de qué hiciesen. Ahora se comprueba que tenían buenos motivos para hacerlo.

Un navegador de accesos directos a páginas populares, creado con AppsGeyser

Si bien muchas apps son meros entretenimientos, existen instituciones y empresas serias que han utilizado este método para crear su app. Incluso aplicaciones muy populares y descargadas. Existen unas 50 apps creadas con esta plataforma, que superan las 100.000 descargas.

Puede que no sean vulnerables todas y cada una, pero es poco probable. Para no serlo, el programador original podría añadir código para activar de nuevo la desactivación de SSL realizada por AppsGeyser. Al tratarse de un perfil de usuario que ha preferido delegar la creación de la app a un tercero, vemos poco probable que baje al nivel técnico necesario para solucionarlo. Además, AppsGeyser no avisa de que está realizando esta desactivación de la comprobación.

¿Por qué desactivar SSL? Sospechamos que para facilitar la vida en el caso de que el creador de la app utilice certificados autofirmados para su web, o certificados que no pueden ser validados por el sistema. AppsGeyser se ahorra así quejas en su sistema de soporte de usuarios creadas con su sistema en los que existe "un error de validación SSL". AppsGeyser desactiva toda comprobación y evita problemas para su soporte técnico, pero pone en riesgo a cualquier usuario de sus aplicaciones.

Prueba de concepto

Valga como prueba de concepto que permite observar el tráfico cifrado esta demostración de un ataque MITM contra una aplicación de AppsGeyser (https://play.google.com/store/apps/details?id=com.SantiniLabsWebBrowser). El atacante tendría que habilitar IP forwarding y redirigir el tráfico HTTP y HTTPS a un webproxy configurado en la máquina.


Para conseguir el ataque de hombre en el medio, se realiza arp-spoofing sobre el dispositivo (aunque podría utilizarse cualquier otra técnica).


La víctima inicia sesión en Facebook desde el navegador incluido en la app:


El tráfico queda capturado, aunque al usuario le parezca cifrado, puesto que en realidad todo se está realizando con el certificado no confiable del webproxy:


El usuario ni siquiera tendría la oportunidad en este caso de comprobar el certificado desde ese navegador, puesto que la aplicación no lo permite.

Detalles técnicos

Técnicamente, el fallo es muy sencillo. Tomemos como ejemplo ese navegador creado con AppsGeyser, aunque el comportamiento sería el mismo en todas las aplicaciones de AppsGeyser en las que no se haya arreglado explícitamente la desactivación.

En el método onCreate(…) de la actividad de inicio, tenemos el siguiente código:


La primera línea destacada, guarda en el atributo mStartupScreenViewContainer el FrameLayout startupScreenContainer que veremos cuando se arranque la aplicación. La segunda, crea un controlador desde el FrameLayout anterior según el siguiente código:


A su vez, la clase StartupScreenController tiene los siguientes atributos:


BrowserWebView será el encargado de presentar las páginas web. Para esto necesitará hacer uso de un objeto WebViewClient que se establece en la construcción de StartupScreenController:

Destacamos de este código cómo se recupera el BrowserWebView (en el layout de la actividad de inicio) y cómo se asigna como WebViewClient la instancia del objeto FullScreenBannerWebViewClient.


Como vemos, la clase hereda de SimpleWebViewClient:


Que a su vez hereda de WebViewClient, el cual según la documentación de la API de Android dispone del siguiente método:


Y este método es sobrescrito en SimpleWebViewClient con el siguiente código, invalidando así el comportamiento de denegación de carga de la página Web en caso de encontrarse con un certificado SSL inválido:


Las conexiones en riesgo dentro de las apps, serían pues las que se hagan desde objetos que hereden de SimpleWebViewClient y BrowserWebViewClient, y siempre que no sobrescriban el comportamiento de onReceivedSslError con un paramSslErrorHandler.cancel().

Miguel Ángel García
miguelangel.garcia@11paths.com

Sergio de los Santos
ssantos@11paths.com

Metashield Protector for Outlook

jueves, 18 de diciembre de 2014

El correo electrónico se ha vuelto indispensable para comunicarse con los demás y para el envío de documentación. Nos permite poder enviar información de manera personalizada, económica, rápida y masiva. Si en la era del fax, el dispositivo imprimía en papel información extra como la hora de envío y el número de fax... ¿qué otra información se escapa hoy a través de los adjuntos de correo? Y lo más importante, ¿cómo la eliminamos de manera sencilla?

En el caso de los ficheros adjuntos en un correo electrónico, si no son tratados previamente, corremos el riesgo de fuga de información sensible: el usuario que creó y modificó los documentos, cuándo lo hizo, con qué rutas de almacenamiento, correos electrónicos...  información relevante que en manos de un atacante podría generar un grave perjuicio para el usuario u organización. Pero sin olvidar también la necesidad de cumplir con los reglamentos referentes a la protección de datos.

Estos riesgos pueden ser solventados o mitigados con herramientas para la limpieza de metadatos. Hasta ahora, se depende de que el usuario recuerde que debe utilizar estas herramientas de forma manual antes de enviar un adjunto. Pero los usuarios pueden no adaptarse completamente a nuestras necesidades. Lo ideal sería poder automatizar la limpieza de metadatos de los documentos adjuntos en el correo electrónico, de una manera rápida y efectiva y sin depender del usuario.

Eleven Paths dispone de Metashield for Outlook, un add on que se instala en Microsoft Outlook y permite realizar de manera desatendida el tratamiento de los metadatos detectados en los documentos adjuntos. La herramienta es capaz de limpiar los metadatos de los tipos de ficheros ofimáticos más importantes del mercado, incluidas las de iWorks de Apple, PDF e imágenes JPG. Al enviar un adjunto desde Outlook, el add on se encargará de todo. Así de simple

Configurador de Metashield for Outlook

Esta solución incluye la opción de modificar, eliminar o mantener la información de los campos más relevantes de los ficheros, tales como el autor, compañía etc., lo que ayudará a homogeneizar esta información en los documentos de Office y en el resto de extensiones de documentos soportadas de otros fabricantes.

Personalización de los metadatos que contendrán los adjuntos

Una vez realizada la configuración inicial, la solución ya estará preparada para trabajar. No es necesario nada más, simplemente usar el correo como de costumbre. Cada vez que se adjunten archivos y se pulse el botón "Enviar" el tratamiento de metadatos se pondrá en marcha inmediatamente. Si así está configurado, se puede mostrar la evolución del proceso. Finalizada la operación, el mensaje y sus adjuntos saldrán hacia su destino con la configuración aplicada en sus metadatos.

Procesamiento y resultado de los metadatos de los adjuntos, antes de ser enviado

La herramienta se encuentra en su fase Beta y se espera que próximamente entre en producción para formar parte de las soluciones Metashield Protector disponibles en el store de Eleven Paths.


Antonio Bordón Villar 
antonio.bordon@11paths.com

Nuestros nuevos productos de identidad y privacidad se llaman SealSign y SmartID

martes, 16 de diciembre de 2014

El pasado 16 de octubre fue una fecha muy especial para nosotros. Por muchos motivos, pero sobre todo porque ese día, bajo el marco del evento Security Innovation Day, os anunciamos la integración de las soluciones de SmartAccess en ElevenPaths.


SealSign y SmartID son soluciones seguras que permiten a todo tipo de empresas firmar documentos de forma electrónica y asegurar transacciones a través de Internet. "Gracias a sus aplicaciones, se puede eliminar el papel, las relaciones comerciales internacionales son mucho más ágiles y las empresas pueden colaborar de forma segura con sus negocios y proveedores", así explicaba el reportaje de TVE en el programa "Espacio Empresa" el 1 de febrero de 2014 cómo funcionaba la tecnología de SmartAccess.


Firma electrónica y biométrica

SealSign es una plataforma empresarial, escalable, modular y completa de firma de documentos electrónicos compatible con certificados digitales, sistemas biométricos, sistemas OTP y archivo a largo plazo de documentos electrónicos firmados.
  • Para quién es SealSign
    • Directores comerciales para la mejora de los procesos de venta a clientes.
    • Directores de compras para agilizar los procesos de adquisición y firma de contratos con proveedores.
    • Directores de RRHH para la firma electrónica de contratos y documentación laboral.
    • Departamentos jurídicos para la firma y revisión de documentos legales con generación de evidencias electrónicas.
    • Responsables de seguridad TIC para proteger la integridad de los documentos y asegurar el origen auténtico de los documentos y mensajes.
Autenticación fuerte y Single Sign-On

SmartID es una solución que permite la autenticación más segura de los usuarios para el acceso a equipos y aplicaciones, empleando la combinación de varios factores como Smart Cards (incluido el DNI electrónico español), dispositivos RFID/NFC o mediante técnicas de reconocimiento biométrico.
  • Para quién es SmartID. SmartID está indicado para empresas y profesionales que necesiten protegerse frente a:
    • Suplantaciones de identidad.
    • Accesos no autorizados de sistemas de información.
    • Fugas de información, especialmente si manejan información sensible o confidencial.
    • Excesivos costes de operación de TI relacionados con la gestión de contraseñas de usuarios o la limitación de uso de certificados de terceros en el Directorio Activo.
    • Responsables de procesos de negocio que requieren el uso de documentos con revisiones y/o firmas. 
Como ya os contamos en SID2014, la gestión de identidad es uno de los campos más apasionantes y complejos que trabajamos en el día a día en seguridad. Así lo explicaba Rames Sarwat.


Seguridad electrónica, identidad digital… esta es la tecnología que estamos integrando en Telefónica. Esto es ElevenPaths.

Latch para Windows: Enterprise Edition (I)

lunes, 15 de diciembre de 2014

Hace un tiempo lanzamos Latch para Windows - Personal Edition. Este plugin permitía proteger el proceso de autenticación de usuarios locales en entornos Windows. Pero, ¿qué pasa si una organización quisiera proteger los usuarios de su dominio? Para ello disponemos de Latch para Windows - Enterprise Edition, que permite proteger la infraestructura de autenticación de Microsoft Windows en entornos centralizados sin importar la cantidad de controladores de dominio que existan en él.

Este plugin para Latch está diseñado para ser utilizado en sistemas operativos Windows Server 2003 o superior y funciona sobre plataformas de 32 y 64 bits. No requiere de instalación de software en los equipos de los usuarios finales.

Latch for Windows, Enterprise Edition, ventana principal

A simple vista no se observa una gran diferencia entre los paneles de configuración del plugin personal y la edición Enterprise, pero este plugin incluye algunas características adicionales que permiten su uso dentro del dominio de las organizaciones, como por ejemplo:


  • Servicio de sincronización entre controladores de dominio: Se encarga de que todos los controladores de dominio puedan tener actualizada la configuración de la protección de las cuentas de usuario custodiadas por Latch.


Sincronizar cuentas entre dominios


  • Web de pareado: Pensando en la comodidad de todos los usuarios y de los administradores de sistemas, el plugin incorpora una web diseñada exclusivamente para gestionar las acciones de pareado y despareado de las cuentas de usuario del dominio. Solo sería necesario configurar el sitio que la albergará.

Web para parear desde una URL interna


  • Posibilidad de proteger el despareado de las cuentas: El plugin ofrece la opción de proteger el despareado de la cuenta de usuario a través de la web antes mencionada. Así, se evita un usuario malintencionado desparee la cuenta de cualquier otro usuario e invalide la protección que otorga Latch. La idea es que el despareo no se realice sin el consentimiento del usuario legítimo. Cabe resaltar que esta protección no afecta en ningún momento al panel de administración, por lo que en cualquier momento (de ser necesario), los administradores a través de su panel de administración pueden realizar cualquier acción que consideren, incluyendo el despareado de las cuentas.


Configuración de Latch para el despareo protegido

Este es el primero de nuestros plugin premium y ya está disponible para su descarga. Su disponibilidad dependerá exclusivamente del tipo de suscripción que posea el desarrollador.

Diferentes versiones en la web de desarrollador

En próximas entradas veremos cómo instalar y configurar el plugin. Para cualquier información adicional es posible contactar a través de nuestro formulario de contacto, o de nuestro correo electrónico latch-help@support.elevenpaths.com.

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

Umberto Schiavo
umberto.schiavo@11paths.com

Latch USB Monitor: New tool to monitor PNP devices with Latch

jueves, 11 de diciembre de 2014

Latch USB Monitor is a tool that monitors Plug 'n Play device (PNP) changes in Windows and gives the user the possibility of tracking incoming devices, and react accordingly to a preconfigured Latch response. For instance, it would allow to block USB ports so it will not recognize a new inserted memory USB stick until it is authorized with the movile device.

This means that Latch USB Monitor will ask Latch servers what to do when a certain PNP device is detected in a Windows machine. So the administrator has a tool to potentially react to plugged devices, and modify the behavior and scripts launched in any way, at any moment, just sliding a bar from his mobile device.

How it works

Latch USB Monitor works as a service and has a GUI to configure it. That means it still works and monitors incoming devices even when no user is logged in. The service is constantly monitoring any device with the characteristics given by the user. When it occurs, it asks Latch servers and reacts in the way that the user has configured it.

It may as well be used as an alerting system, with no action associated to an event. So if a device is plugged to the machine, a blocking message is sent by Latch to the mobile device, but no action is taken.


Latch USB Monitor with some configured rules

 How to install it

No special instructions. Just accept the license and choose the path. If, for the sake of security, you do not want the service to run as SYSTEM, you may change it to whatever account you wish, as long as it has privileges to run as a service, and network access.

A config file is created in XML format. This file contains sensitive information. Take care with the permissions specially in shared computers.

Pairing with Latch

First of all, a Latch account has to be set with a pairing token. Go to Latch management and add the App ID and secret. A timeout is specified here. This means that if the computer is not connected to a network or, for any other reason it cannot get a response from Latch in the specified time limit (0 milliseconds by default which corresponds to no timeout) the "no response" action is applied.

How to add and configure a device

Each monitored device, may have these fields:
  • Device (optional): If your device is currently plugged in, you can choose it from this dropdown menu where all attached devices are listed.
  • Description (optional): Giving a meaningful description of the device helps you better identify it in the main list.
  • Device Instance ID: The ID that uniquely identifies a device in a Windows machine. When an arriving Device Instance ID is detected it goes through a matching system that can be used to discard or allow the rule. If the string set matches, the Latch query will be launched. This is treated as a string, so "Starts with", "Contains"... may be used to match.
  • Operation ID: The operation ID used in Latch.
  • Actions.Open (optional): If the Latch query responds with an "on", the process specified here will be launched, with the specified argument set (optional).
  • Actions.Closed (optional): If the Latch query responds with an "off", the process specified here will be launched, with the specified argument set (optional).
  • Actions.No response (optional): If the Latch query doesn't respond (because there's no connectivity, for instance, after the timeout declared in "Latch settings"), the process specified here will be launched, with the specified argument set (optional).

Device details with pendrive example

The tool is written in C# and may be freely downloaded from: https://elevenpaths.com/downloads/LatchUSBMonitor.zip. You may want to check out Latch Event Monitor, too.

We encourage you to use it.

Latch USB Monitor: Nueva herramienta para monitorizar dispositivos PNP con Latch

Latch USB Monitor es una herramienta que monitoriza los cambios en dispositivos Plug 'n Play (PNP) de Windows y ofrece al usuario la posibilidad de detectar los dispositivos insertados y reaccionar de acuerdo a una respuesta de Latch preconfigurada. Por ejemplo, permitiría bloquear puertos USB de forma que no reconociera una memoria USB insertada hasta que no se autorizase con el móvil.

Esto quiere decir que Latch USB Monitor preguntará a los servidores de Latch qué hacer cuando algún dispositivo PNP se detecta en una máquina Windows. De esta forma, el administrador dispone de una herramienta para reaccionar potencialmente a los dispositivos insertados y modificar el comportamiento o los scripts lanzados de cualquier forma y en cualquier momento, con solo desplazar una barra en su dispositivo móvil.

Cómo funciona

Latch USB Monitor funciona como un servicio y dispone de una GUI para configurarlo. Esto significa que funciona y monitoriza los dispositivos entrantes incluso cuando no se ha presentado un usuario en el sistema. El servicio está constantemente monitorizando cualquier dispositivo con las características que desee el usuario. Cuando ocurre, pregunta a los servidores de Latch y reacciona en la forma en la que el usuario lo haya configurado.

También podría usarse como un sistema de alerta si no se asocia ninguna acción a un evento. Así que si un dispositivo se inserta en la máquina, Latch enviaría un mensaje de bloqueo al dispositivo móvil, pero no se tomaría ninguna acción en el ordenador.


Latch USB Monitor con algunas reglas configuradas

Cómo instalarlo

No se requieren instrucciones especiales. Simplemente acepta la licencia y elige una ruta. Si, por seguridad, se prefiere que el servicio no se ejecute como SYSTEM, es posible cambiarlo a cualquier cuenta que se desee, siempre que se le otorgue el permiso de ejecutar como servicio y acceso a red.

El programa crea un fichero de configuración en formato XML, que contiene información sensible. Es necesario observar sus permisos, especialmente en sistemas  compartidos entre varios usuarios.

Pareando con Latch

Lo primero de todo, se debe crear una cuenta Latch  con un token de pareo. En el programa, ir a Latch management y añadir el Secret y App ID. En este punto también se especifica un "timeout". Esto quiere decir que si el sistema no está conectado a la red o, por cualquier razón, no puede obtener una respuesta de Latch en el tiempo especificado (0 milisegundos por defecto corresponden a que no existe "timeout"), se aplicará la acción especificada en "no response".

Cómo añadir y configurar un servicio

Cada dispositivo monitorizado puede contar con estos campos:
  • Device (opcional): Si el dispositivo se encuentra conectado, se puede elegir desde este menú desplegable en el que aparecerán los dispositivos encontrados en ese momento.
  • Description (opcional): Una descripción significativa del dispositivo ayudará a identificarlo mejor en la lista principal de reglas.
  • Device Instance ID: El ID que identifica de forma unívoca un dispositivo en una máquina Windows. Cuando se detecta un Device Instance ID entrante, se comparará con la lista de reglas. Si casan, se lanzará la consulta a Latch. Las comparaciones se realizan como "strings" así que se pueden usar expresiones como "Starts with", "Contains"...
  • Operation ID: El operation ID usado en  Latch.
  • Actions.Open (opcional): Si la consulta a Latch responde con un "on", el proceso especificado se lanzará con los argumentos correspondientes (opcional).
  • Actions.Closed (opcional): Si la consulta a Latch responde con un "off", el proceso especificado se lanzará con los argumentos correspondientes (opcional).
  • Actions.No response (opcional): Si la consulta a Latch no responde (porque no hay conectividad, por ejemplo, después del "timeout" declarado en "Latch management"), se lanzará el proceso especificado aquí, con los argumentos correspondientes  (opcional).

Detalles de un dispositivo con un ejemplo de un pendrive


La herramienta está escrita en C# y puede ser descargada libremente desde: https://elevenpaths.com/downloads/LatchUSBMonitor.zip. Quizás también quieras probar Latch Event Monitor.

Invitamos al uso de la herramienta.