Accessing (and hacking) Windows Phone registry

lunes, 30 de diciembre de 2013

Although Microsoft’s efforts on securing Windows Phone 8 devices from community hacks, accessing the device’s registry is still possible with some limitations. Writing to the registry is denied by default but read-permissions are quite lax.

First approach

When trying to read the registry, initial approach is (maybe) to invoke a low-level library from WIN32 API, such as winreg.h to import the necessary functions. However, PInvoke/DllImport isn’t available in Windows Phone, so we would have to implement it from scratch. Needless to say that this breaks Microsoft’s requirements for submitting such an application to the Store.

Doing some research shows that much work has already been done and is available for public download in the "XDA Developers" forum. There is a project called "Native Access" by GoodDayToDie that does exactly this. However compiling and using it is not straightforward so we’ll give it a go and show how to do it.

Dependencies

The project’s source code can be download from the following link: http://forum.xda-developers.com/showthread.php?t=2393243.To get the referenced libraries needed for building the project, it is needed to convert the phone’s DLLs into .lib format (using, for example dll2Lib available from https://github.com/peterdn/dll2lib). Actually, the needed libraries are in system32 directory, but using the emulator’s libraries will not work on an actual phone. So you will need an image from real devices. There are ISO files available "out there", so you can get and extract them easily.

Once done, you need to place the extracted .LIBs in the Libraries folder of the WP8 SDK (typically in Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Libraries).

Problems compiling

However, if you have trouble compiling the code, there’s a shortcut by referencing the .winmd file from an existing project that uses Native Access (WebAccess for example). Just extract the XAP’s contents (which is just a zip file) and search for “Registry.dll” which is a precompiled version of the project.

Now we are ready to use the library and writing code to search for some interesting keys in the registry. The class provides all of the necessary methods to access the registry: ReadDWORD, ReadString, ReadMultiString, ReadBinary, ReadQWORD, GetHKey, GetSubKeyNames, GetValues

A real example

Here are the codes needed to access the different registry hives:
  • 80000000 -> HKEY_CLASSES_ROOT
  • 80000001 -> HKEY_CURRENT_USER
  • 80000002 -> HKEY_LOCAL_MACHINE
  • 80000003 -> HKEY_USERS
  • 80000004 -> HKEY_PERFORMANCE_DATA
  • 80000005 -> HKEY_CURRENT_CONFIG
Example code to access registry in Windows Phone 8
For some registry locations that are highly sensitive, or for writing or creating keys, you need to add special Capabilities to your app. This will require an interop-unlock that has currently been achieved only in Samsung devices by taking advantage of Samsung’s "Diagnosis tool".


Tero de la Rosa
tero@11paths.com

Accediendo (y "hackeando") el registro de Windows Phone

sábado, 28 de diciembre de 2013

Aunque Microsoft se esfuerza en proteger Windows Phone 8 de los hacks de la comunidad, acceder al registro de los dispositivos todavía es posible con algunas limitaciones. Escribir en el registro está denegado por defecto,  pero los permisos de lectura son bastantes laxos.

Primera aproximación

Si se quiere intentar leer el registro, la primera aproximación puede ser invocar a una librería a bajo nivel de las API WIN32, como puede ser winreg.h e importar las funciones necesarias. Sin embargo, PInvoke/DllImport no está disponible en Windows Phone, así que se tendría que implementar desde cero. No hace falta decir que esto viola los requerimientos de Microsoft para subir una aplicación a la Store.

Pero investigando un poco, podemos encontrar que una buena parte del trabajo ya está hecho y disponible para descarga desde el foro "XDA Developers". Es posible aprovechar un proyecto llamado "Native Access" de GoodDayToDie que hace exactamente eso. Sin embargo compilarlo y usarlo no es trivial, así que vamos a documentar un poco cómo hacerlo.

Dependencias

El código fuente del proyecto puede ser descargado desde esta dirección: http://forum.xda-developers.com/showthread.php?t=2393243. Para compilar el proyecto, es necesario hacerse con las librerías de referencias y convertir algunas DLL del teléfono en formato .lib usando, por ejemplo, dll2Lib (disponible en este enlace: https://github.com/peterdn/dll2lib). En realidad, las librerías necesarias están en el directorio system32, pero utilizar las del emulador no va a funcionar en un teléfono real. Así que se necesitarán imágenes de dispositivos reales y extraer de ellas las DLL. Hay imágenes ISO de teléfonos reales disponibles "ahí fuera", así que en realidad no es difícil extraerlas y conseguirlas.

Una vez hecho, es necesario, además, poner las librerías .LIB extraías en el directorio Libraries del SDK de WP8 (normalmente en Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Libraries).

Problemas compilando

Sin embargo, si tienes problemas compilando el código, se puede tomar un atajo si se referencia el fichero .winmd de un proyecto ya existente que use Native Access (por ejemplo WebAcess). Se debe extraer el contenido del fichero XAP (que no es más que un zip) y buscar "Registry.dll" que ya es una versión compilada del proyecto.

Ahora ya estamos listos para usar la librería y escribir el código para buscar claves en el registro. La clase proporciona todos los métodos necesarios para acceder al registro: ReadDWORD, ReadString, ReadMultiString, ReadBinary, ReadQWORD, GetHKey, GetSubKeyNames, GetValues

Un ejemplo real

Aquí están los códigos para acceder a las diferentes ramas:
  • 80000000 -> HKEY_CLASSES_ROOT
  • 80000001 -> HKEY_CURRENT_USER
  • 80000002 -> HKEY_LOCAL_MACHINE
  • 80000003 -> HKEY_USERS
  • 80000004 -> HKEY_PERFORMANCE_DATA
  • 80000005 -> HKEY_CURRENT_CONFIG
Ejemplo de código para acceder al registro de Windows Phone 8
Para acceder a algunos puntos del registro que son muy sensibles, o para crear claves, se necesitarán ciertas capacidades especiales. Por ejemplo conseguir interop-unlock que por ahora solo se ha hecho en dispositivos Samsung que aprovechan la "Diagnosis tool" de la marca.

Tero de la Rosa
tero@11paths.com

Intercambio de datos entre páginas: SOP, CORS y WebMessage (I)

martes, 24 de diciembre de 2013

Los navegadores son las aplicaciones más usadas por los usuarios a causa del desplazamiento del escritorio "a la nube" y por la grandes posibilidades que abarcan. La creciente complejidad del navegador ha permitido potenciar sus funcionalidades y (en consecuencia) aumentar los problemas de seguridad y su criticidad. Pero además, ha exigido nuevos métodos de intercambio de información y protocolos. Veamos algunos.

Comentaremos una de las políticas de intercambio implementadas por los navegadores desde hace tiempo (SOP) y otras soluciones "menos estrictas" ideadas para permitir mayor versatilidad y funcionalidad a las aplicaciones web.

Same-Origin Policy (SOP)

Same Origin Policy (SOP), es una de las políticas que implementan los navegadores desde prácticamente su concepción. Su objetivo fundamental (aunque en realidad esta definición se encuentra muy simplificada) es impedir que dominios que no compartan el mismo host, puerto y protocolo sean capaces de acceder a la información de otro dominio. Esta "información" pueden ser cookies, archivos HTML, imágenes, scripts, bases de datos, etc…
Tabla comparativa sobre SOP. Fuente: Wikipedia
En realidad, es un poco más complejo que todo eso. SOP no solo se trata de "acceder a recursos de otro dominio" sino que necesita distinguir entre qué recursos y de qué manera accede a ellos (con el ánimo de leer, escribir o incluso ejecutar). Eric Lawrence lo explica perfectamente en este enlace aplicando el concepto de permisos Unix (RWX) para explicar SOP.

Profunda explicación sobre SOP por Eric Lawrence
La idea de la política se remonta a NetScape Navigator 2.0, implementándose incluso en lenguajes de terceros como Adobe Flash o Adobe Acrobat o en mecanismos del propio navegador como la navegación por DOM. Incluso en el uso de XMLHttpRequest (peticiones HTML 5).

Esta política es implementada por todos los navegadores, aunque algunos navegadores la interpretan a su manera. Por ejemplo Internet Explorer no incluye el puerto como parte del "origen" delegando parte de su funcionamiento a su particular uso de las Zonas. Por ejemplo, si encuentra dos dominios que el usuario haya establecido como "Sitios de Confianza" la política permitirá la comunicación.

Opciones de sitios de confianza de Internet Explorer
Un claro ejemplo de la implementación de SOP y su utilidad, se observa durante la navegación a través del árbol DOM  cuando una web usa la etiqueta IFRAME (que permite incrustar una web dentro de un marco). Ninguno de los documentos podrá acceder al contenido del otro siempre y cuando no estén dentro del mismo dominio, usen el mismo protocolo y el mismo puerto.

Examinando el DOM de una web en la que se bloquea por política
Esta implementación evitaría que cuando el usuario acceda a una web maliciosa con un IFRAME, el atacante sea capaz de recopilar cualquier dato de la web o la cookie de sesión del usuario. Por tanto, la política SOP juega un papel fundamental a la hora de proteger los datos y que estos se compartan con otras entidades.

Sin embargo, en algunas ocasiones esta política puede llegar a ser muy restrictiva, por lo que en HTML 5 se incorporan varias funcionalidades y soluciones que la relajan, llegando a permitir compartir más datos. Un ejemplo es CORS, del que hablaremos en la próxima entrega.
Oscar Sánchez
oscar.sanchez@11paths.com

Latch ya está en Acens (y poco a poco en más servicios)

viernes, 20 de diciembre de 2013

Ya hemos hablado de la tecnología Latch, pero lo realmente interesante ahora no es que sea posible aprovecharla en diferentes webs, páginas, portales y servicios. Acens la compañía de hosting, ya la tiene disponible para sus clientes.

Acens ha implementado Latch para proteger el acceso a las cuentas de los clientes. Añade así una capa adicional de seguridad en su panel de control, permitiendo al usuario controlar cuándo (incluso si un tercero conociera sus credenciales) se puede acceder a esa información tan sensible. Si hablamos por ejemplo de los servidores DNS, es más que recomendable proteger su acceso. Además no suele ser algo que cambie a menudo.

Acens ha conseguido integrar Latch en sus sistemas en menos de 24 horas, lo que da una idea de lo fácil que resulta para los técnicos involucrados.

Para aprovechar esta oportunidad de proteger las cuentas en Acens, solo es necesario que el usuario descargue la aplicación para iPhone o Android (en Windows Phone estará en breve, y para BlackBerry y Firefox OS dentro de unas semanas).

Después, desde el panel de control de Acens, es necesario parear la cuenta.

Pasos necesarios para parear la cuenta de Acens con Latch desde su panel de control
Y así quedará disponible en el teléfono.

Acens en Latch
Poco a poco, Latch intentará estar disponible en más y más páginas de servicios, para que el usuario pueda realmente aprovechar esta tecnología.

Sobre cookies y sistemas de seguimiento (y II)

miércoles, 18 de diciembre de 2013

El tracking o seguimiento a través de web, consiste en intentar identificar al usuario que está navegando y recopilar la mayor información posible sobre él creando un perfil. Con este perfil, se podrá tratar al usuario como receptor de una publicidad más personalizada y por tanto, efectiva. Veamos las propuestas de diferentes fabricantes para "solucionar" este problema, y realizar un tracking más efectivo de los usuarios.

Google

Desde hace algunos años, Google posee doubleclick.com, una de las mayores empresas de publicidad de internet. La compró en 2008 por 3.000 millones de dólares. Está presente en una inmensa mayoría de webs que se visitan. Esta ubicuidad, a efectos prácticos, permite a Google rastrear y evaluar qué anuncios debe mostrar basándose en el perfil de navegación recopilado. 

Fuente: Wall Street Journal
Cada perfil se relaciona con un ID almacenado en la cookie de doubleclick.com. Pero este "viejo método" es fácilmente eludible por el usuario, que puede deshabilitar las cookies de terceros, por ejemplo. Una evolución por parte de Google es su empeño en que realicemos las búsquedas cuando ya estamos presentados (hemos hecho el log in) en su domino, con lo que puede también recabar información sobre el usuario que realiza las consultas.

Pero Google planea cambiar el método de tracking con third party cookies a un ID único que lleve el navegador o el dispositivo. Esto permite una mayor persistencia además de poder unificar la información de varios dispositivos. Así podría seguir recopilando información para el perfil tanto desde el ordenador como desde otros dispositivos móviles.

Esta idea ya se está llevando a cabo en los nuevos dispositivos que usan Android 4.4 (Kitkat). En ellos ya se puede ver el Advertisement id. De momento solo aplicable para las apps y Google Play:

Advertising ID en los nuevos Androids
Como se muestra en la imagen, el usuario puede deshabilitar y restablecer el identificador. La idea es implantar este AdID en los navegadores y dispositivos de Google, con lo que se generaría un "gran perfil" incluso entre varios dispositivos. Con AdID, Google promete traer mayor privacidad y control, permitiendo a través de las opciones del navegador o dispositivo controlar qué entidades acceden a los datos. Además no todas las entidades podrían acceder a la información recopilada, solo las que cumplan con ciertas "normas".

Pero aunque AdID se considere un identificador anónimo para mostrar publicidad acorde a los gustos del usuario, no deja de tratarse de un sistema de seguimiento que podría llegar a vincularse con otros productos de Google como GMail o Google Plus, pudiendo identificar al usuario. De popularizarse, AdID daría a Google más poder y control de información.

Apple

Safari, tanto en su versión de escritorio como móvil, implementa por defecto la política de desactivar las cookies de terceros.  Por otro lado, en los dispositivos iOS existen varias opciones de tracking de ubicación, búsquedas o aplicaciones que pueden ser desactivadas o activadas a elección del usuario, aunque por defecto estén activadas.

Pero aunque Apple no permita cookies de terceros en su navegador, sí que implementa su propio ID For Advertisement (IFA o IDFA) que actúa como identificador para la publicidad de las aplicaciones en los dispositivos móviles. En anteriores versiones se conocía como UDID. Desde iOS 6 en adelante, aparece la opción de privacidad en el menú de ajustes que permitirá al usuario limitar o restablecer este identificador:
Menú de ID for Advertisement en iOS
Facebook

Facebook usa cookies de terceros en los elementos integrados en las webs, como el conocido botón de "Like!" o píxeles transparentes para realizar el seguimiento. Obviamente, Facebook es capaz de relacionarlo directamente con el perfil, puesto que el identificador de sesión de Facebook se envía en la cookie.

Además Facebook es capaz de rastrear al usuario incluso después de cerrar la sesión. Esto ocurre porque existen elementos en la cookie que no varían tras cerrar la sesión, permitiendo identificar al usuario que previamente inició y cerró sesión.

Cookies de Facebook antes y después de cerrar sesión
Microsoft

Por otro lado Microsoft propone una alternativa parecida a Google, creando un ID de dispositivo para sus productos Windows, Windows Phone, Xbox, IE y Bing permitiendo conocer los gustos a través de estas plataformas. Todavía no se ha revelado demasiada información de cómo funcionaría. Aquí, realizaban una pequeña comparativa entre los métodos.

Do not track... ¿la solución?

Hace ya algún tiempo (2001) se introdujo una opción en los navegadores llamada "Do not track" (DNT), que incluye un flag o header en todas las peticiones realizadas por el navegador para evitar que se realice el tracking. Sin embargo, queda en la mano del servidor valorar esta opción o no.

Ejemplo de cliente enviando la cabecera Do Not Track
Actualmente todos los navegadores populares como IE, Firefox, Chrome, Safari y Opera implementan la función DNT y se puede configurar fácilmente en el apartado de preferencias de cada navegador. Internet Explorer es el único que lo implementa por defecto.

Configuración de "Do Not Track" en diferentes navegadores
* Sobre cookies y sistemas de seguimiento (I)
Oscar Sánchez

FOCA Final Version, la FOCA definitiva

lunes, 16 de diciembre de 2013

A todos os suena la FOCA. Durante estos años, ha tenido una gran aceptación y se ha convertido en una herramienta muy popular. Pero Eleven Paths ha matado a la FOCA y la ha convertido en un servicio muy especial, FaasT. Sin embargo, la FOCA no ha muerto. FOCA Pro es ahora una versión portable llamada  FOCA Final Version se puede descargar gratuitamente.

FOCA Free vs. FOCA Pro
Solía existir la FOCA Free y la FOCA Pro. La versión Pro incluía algunas funcionalidades extra como reportes, análisis de mensajes de error en las repuestas, fuzzing de URLs buscando errores de conversión de tipos en PHP, errores de sintaxis en consultas SQL/LDAP, errores de desbordamiento de enteros y más paralelismo en su core. Tampoco contenía anuncios.

Pero ahora, FOCA se une en una única versión, basada en la FOCA Pro, pero gratuita. Así que aquí está  FOCA Final Version. Esta versión final incluye todos los plugins disponibles y la posiblidad de crear otros propios. También se han corregido ciertos errores que habían reportado los usuarios.

Si quieres saber cómo funciona, podéis comprar este libro sobre pentesting con FOCA.


FOCA Final Version
FOCA se puede descargar gratuitamente sin necesidad de registro desde la página de Eleven Paths Labs.

Esperamos que la disfrutéis.

FOCA Final Version, the ultimate FOCA

You all know FOCA. Over the years, it had a great acceptation and became quite popular. Eleven Path has killed the FOCA to turn it into a professional service, FaasT. But FOCA did not die. FOCA Pro is now a portable version called FOCA Final Version that you can download for free.

FOCA Free vs. FOCA Pro
There used to be a FOCA Free and a FOCA Pro. The Pro version included some extra features such as reporting, analysis of error messages in response pages, fuzzing of URLs searching for data type conversions errors in PHP, syntax errors in SQL/LDAP queries, integer overflow errors, and more parallelism in its core. It had no ads either.

But now, FOCA joins in just one version, based on FOCA Pro, but for free. So here it is FOCA Final Version. This final version includes all the plugins available and the tools for you to create your own plugins. Some bug reported by users had been fixed as well.

If you want to know how it works and some secrets, you can buy this new book about pentesting using FOCA.

FOCA Final Version
FOCA is free for download with no registration from Eleven Paths Labs page.

Hope you enjoy it.

Latch, new ElevenPaths' service

jueves, 12 de diciembre de 2013

During the time we've been working in ElevenPaths we've faced many kind of events internally, buy one of the most exciting and awaited is the birth of Latch. It's a technology of our own that has been invented, patented and developed by our own team... and, at last, exhibited to the world. We're proud of the work that has been done and we needed to tell about it. Finally we can do so. This is Latch.

We think that users do not use their digital services (online banking, email, social networks...) 24 hours a day. Why would you allow an attacker trying to access them at any time then? Latch is a technology that gives the user full control of his online identity as well as better security for the service providers.

Latch, take control of when it's possible to access your digital services.
Passwords, the oldest authentication system, are a security problem that we have to deal with every day. Second factor of authentication, biometry, password managers... We haven't found yet the ultimate solution for the user not to depend on simple passwords, reusing them, or writing them on a paper. Latch isn't that solution, either. Even advanced users that use good password practices are exposed to their passwords being stolen. Malware that focuses on credentials thievery are very "usual" since long agoBut even the most cautious users may have their passwords stolen by attackers if a third party's database is hacked and exposed. Latch isn't a solution for this problem, either.
Latch doesn't replace passwords, but complements them and makes any authentication system stronger.

Latch's approach is different. Avoiding authentication credentials ending in wrong hands is very difficult. However, it's possible for the user to take control of his digital services, and reduce the time that their are exposed to attacks. "Turn off" your access to email, credit cards, online transactions... When they're not being used. Block them even when the passwords are known. Latch offers the possibility for the user to decide when his accounts or certain services can be used. Not the provider and, of course, nor the attacker.
Latch makes it possible to control your services even if an attacker has stolen the user's password, credit card or any other service that needs authentication, making it impossible for the attacker to use the stolen data in that service out of a defined time interval. In other words, (by just pushing a button) it's possible to make the authentication credentials for any service valid only for that very moment when the user needs to introduce them on the system. 

Latch's scheme
Even though we've talked about passwords, Latch is actually a service to protect service provider's defined processes for interacting with the end user. The background and uses that may be given to these processes are independent of the protection layer that Latch provides.
The main idea of the structure of this protection is limiting the exposure window that an attacker owns for taking advantage of any of these processes. The user will decide if his service accounts are turned ON or OFF and even will detail the actions that can be taken from those services. This makes it possible to reduce in time the possibilities of an attack, associating an external control to every operation. The service provider requests Latch for the user-defined status of a certain operation for a defined time.
Latch's general work scheme
In this figure, a client that tries to execute an operation from a service provider obtains confirmation on whether the operation has been allowed or denied.

The configuration of an operation's state is made through an alternative channel (and considered more "secure" than the regular device), so any attempt to access an operation blocked by the user may be identified as an anomaly. Such an anomaly could imply that the user trying to access the blocked operation is not reality who he's claiming to be and a possible fraud attempt is identified.

How it works in practice

The user will only need a smartphone to "activate" or "deactivate" the services paired with Latch. To do so, he or she will need to:
  • Create a Latch user account. This account will be the one used by the user to configure the state of the operations (setting to ON or OFF his services accounts).
  • Pairing the usual account with the service provider (an email account or a blog, for example) that the user wants to control. This step allows Latch to synchronize with the service provider and to provide the adequate responses (defined by the user) depending on which operation is tried to be used. The service provider must be compatible with Latch, of course. This allows the users to decide whether to use Latch or not. Latch is offered but not imposed.
Latch for the service providers


Latch allows the users to configure the access to their services, and to accomplish this, the service providers need to integrate Latch in their systems. We've programmed different SDKs in many different languages (.NET, PHP, ASP...) and we've created plugins for already existing platforms such as Wordpress, PrestaShop, Drupal and Joomla. The webpages using these platforms are able to offer Latch to their users quite easily...  so the users deciding  to use the service may take advantage of Latch also very easily.

The integration is easy and straightforward, giving the service provider a great opportunity to improve the security offered to its users, and therefore, their online identity.

And that is not all...

Latch offers more ways to protect users, their credentials, online services and online identities. We will introduce them soon. Stay tuned.

Latch, el nuevo servicio de ElevenPaths

Durante el tiempo que llevamos trabajando en ElevenPaths, internamente han ocurrido acontecimientos de todo tipo, pero uno de los más emocionantes ha sido el nacimiento de Latch. Una tecnología propia que ha sido pensada, ideada, perfilada, patentada e implementada por nuestro equipo... y ahora mostrada al mundo. Estamos orgullosos del trabajo realizado y necesitábamos contarlo. Por fin podemos hacerlo. Aquí está Latch.
Pensamos que el usuario no utiliza los servicios digitales (su banca online, su correo, sus redes sociales...) las 24 horas del día. ¿Por qué se permite que los atacantes sí tengan la posibilidad de intentar acceder a ellos en cualquier momento? Latch es una tecnología que pretende otorgar al usuario el control de su identidad en la red fortaleciendo la gestión de la autenticación y mejorando la seguridad de los proveedores de servicios. 
Latch, controla cuándo es posible acceder a tus servicios digitales.
Las contraseñas, el sistema de autenticación más antiguo, son un problema de seguridad con el que tenemos que aprender a convivir. Un segundo factor de autenticación, biometría, gestores de contraseñas... todavía no se ha dado con la fórmula mágica para que el usuario deje de usar contraseñas simples, las reutilice, o las escriba en un papel. Y Latch no es esa solución. Aun en el caso de usuarios avanzados con buenas prácticas en el uso de credenciales, es posible que la contraseña sea robada. El malware que se dedica profesionalmente al robo de credenciales es "habitual" desde hace tiempo. Pero incluso los usuarios más cuidadosos con sus sistemas pueden sufrir problemas si las bases de datos de terceros son vulneradas, y sus credenciales acaban en manos de atacantes. Y Latch, tampoco es la solución para este problema.
Latch no sustituye a las contraseñas, complementa y fortalece cualquier sistema de autenticación.

La aproximación de Latch es diferente. Evitar que los datos de autenticación sean robados es muy complejo. Sin embargo, sí que es posible que el usuario tome el control de sus servicios digitales, y reduzca su tiempo de exposición. "Apagar" el acceso a tu correo, la posibilidad de usar tu tarjeta de crédito, o realizar transacciones online, cuando no esté usando. Bloquearlos incluso cuando se conocen las contraseñas adecuadas. Latch otorga la posibilidad de que sea el propio usuario quien decida cuándo se puede acceder a sus cuentas o usar ciertos servicios. No el proveedor. Ni por supuesto, el atacante.
Latch va a permitir que, incluso si un atacante utiliza un usuario y contraseña robado, una tarjeta de crédito, o cualquier sistema de que necesite una aprobación, al atacante le sea imposible utilizar esta información para hacerse pasar por el usuario fuera de un intervalo definido. En resumen, es posible que el usuario y contraseña que se utilizan para acceder a cualquier servicio, sean (pulsando un botón) solo válidos durante esos pocos segundos en los que es el propio usuario quien los introduce en el sistema.
El esquema Latch
Aunque hemos hablado de contraseñas, Latch se presenta en realidad como un servicio diseñado para proteger los procesos definidos por cualquier proveedor de servicios para interactuar con sus usuarios. La naturaleza y el uso que se pueda dar a estos procesos son independientes de la protección que puede ser proporcionada por Latch.
La idea fundamental sobre la que se estructura esta protección es la limitación del tiempo de exposición del que dispone un atacante para intentar aprovechar alguno de estos procesos en su propio beneficio. El usuario decidirá si sus cuentas están en ON u OFF e incluso las acciones que se pueden realizar desde ellas. Esto supone que se logre la reducción de la ventana de tiempo en la que podría suceder un ataque, asociando a cada operación un control externo. El proveedor de servicio consultará a Latch el estado con el que el usuario ha decido configurar  la ejecución de esta operación para un momento determinado.

Esquema general de funcionamiento de Latch
En esta figura, un cliente que solicita la ejecución de una operación a un proveedor de servicios puede obtener la confirmación de que esta operación se ha realizado de forma satisfactoria o que se ha denegado.

La configuración del estado definido por una operación concreta se realiza de a través de un canal alternativo (y considerado más "seguro" que el dispositivo habitual), así que cualquier intento de utilizar la operación que ha sido bloqueada por el propio cliente se puede identificar como una anomalía. Su existencia podría implicar a su vez que el usuario que solicita la ejecución de la operación no sea quien está afirmando ser y se haya detectado así un intento de fraude.

Cómo funciona en la práctica

El usuario solo necesitará utilizar su smartphone para "activar" o "desactivar" los servicios pareados con Latch. Para ello es necesario:
  • La creación de una cuenta de usuario en Latch por parte del cliente. Esta cuenta será la utilizada por el usuario para configurar sus estados en las operaciones (establecer a ON u OFF sus cuentas con los proveedores).
  • El pareado de su cuenta habitual con el proveedor (la cuenta de correo, o de un blog, por ejemplo) que se desea controlar, con la cuenta de usuario de Latch. Este paso permitirá a Latch sincronizarse con el proveedor de servicio para ofrecerle la respuesta adecuada (configurada por el usuario) dependiendo del proveedor de servicio y la operación concreta dentro de él. Por supuesto, el proveedor de servicio debe ser compatible con Latch. Esto permite a los usuarios que lo decidan, aprovechar esta ventaja ofrecida por el proveedor, sin que este deba imponer la solución a todos sus clientes.
Latch en los proveedores de servicio

Latch permite que los usuarios adapten el acceso a sus servicios a la forma en que ellos usan estos servicios y para conseguirlo, los proveedores deben integrar Latch en sus sistemas. Hemos preparado diferentes SDKs en muchos lenguajes diferentes (.NET, PHP, ASP...) y hemos creado plugins para plataformas ya existentes, como Wordpress, PrestaShop, Drupal y Joomla. Las páginas que usen estas plataformas, pueden ofrecer Latch a sus clientes, de forma muy cómoda. Los usuarios que decidan utilizar el servicio, podrán beneficiarse de Latch también fácilmente.
La integración es sencilla, y el proveedor puede mejorar sustancialmente la seguridad que ofrece a sus usuarios, cediéndoles un mayor control de su seguridad y por tanto, de su identidad en la red.
Y esto no es todo...

Latch permite otras fórmulas para intentar proteger al usuario, sus credenciales, servicios online e identidad en la red. Las presentaremos poco a poco. 

El extraño caso del gobierno francés que crea certificados falsos para Google

martes, 10 de diciembre de 2013

Google ha reconocido que un tercero ha construido certificados válidos emitidos para sus dominios, pero obviamente no autorizados. Esto ha ocurrido otras veces en los últimos años. Lo interesante es que esta vez ha sido el gobierno francés el responsable y las consecuencias que se pueden "intuir" al respecto.

Qué ha ocurrido

El 3 de diciembre Google reconocía que había encontrado certificados emitidos para google.com y otros dominios de Google. Esto lo puede hacer en teoría, cualquiera. El problema es que estos certificados se vean certificados a su vez por una autoridad. Y lo estaban. En concreto, los certificados estaban firmados por la Directorate General of the Treasury (DG Trésor), subordinada de la CA del gobierno francés ANSSI (Agence nationale de la sécurité des systèmes d'information). Esta CA está presente en las autoridades certificadoras en las que confía Microsoft por defecto, y por tanto Google Chrome.

Según Google, ANSSI ha dicho que el certificado falso emitido estaba siendo usado en red interna, para acceder al tráfico cifrado sin que los usuarios de esa red se percataran. Pero en la declaración oficial del gobierno francés no se menciona este aspecto directamente.

¿Consecuencias?

Tanto Google como Microsoft han tomado medidas. Aunque Microsoft dice que "han eliminado la confianza de los certificados que provocan este problema" a través de sus listas CTL, parece que a través del actualizador automático de certificados han eliminado la confianza de toda la CA intermedia (que es lo que hay que hacer). El certificado de la autoridad intermedia en concreto es que tiene como huella 5c e3 39 46 5f 41 a1 e4 23 14 9f 65 54 40 95 40 4d e6 eb e2.

Microsoft insinúa además que la nueva funcionalidad de EMET podría ayudar a mitigar esta situación, pero no parece cierto. En el caso de una autoridad certificadora intermedia, EMET no alertaría si se ha "pineado" el dominio solo a la raíz de certificación. En este caso concreto de compromiso de CA intermedia, en la cadena de certificación, la raíz sigue siendo válida... por tanto EMET no notaría nada extraño.

Mozilla también ha revocado a esta autoridad intermedia. 

El gobierno francés ha declarado que "ha sido a causa de un error humano. En un intento de fortalecer la seguridad de todo el ministerio francés de finanzas, se han emitido certificados de terceros que no pertenecen a la propia administración". Añade que el error no tiene consecuencias para la seguridad global, y que en cualquier caso se ha revocado preventivamente esa CA para que cualquier certificado emitido por ella no sea aceptado.

Pero ¿qué ha podido pasar?

Ya hemos vivido situaciones parecidas. Varias veces. En enero de 2013 con a TurkTrust. Anteriormente con Diginotar (septiembre de 2011) y Comodo (marzo de 2011). No sabemos qué ha pasado exactamente, pero al menos este incidente vuelve a levantar algunas sospechas y permite refrescar otras reflexiones.
  • En aquellas situaciones ya citadas, se falsificaron también certificados de Google. Aunque en realidad se puede hacer para cualquier dominio, parece que cuando  cuando se tiene la oportunidad de falsificar certificados de dominio, google.* es la opción mayoritaria.
  • En los últimos dos años, se han tenido que emitir bastantes más emergencias de este tipo (revocaciones masivas de certificados o entidades certificadoras) que en los diez previos. No es algo nuevo, pero se vuelve a demostrar lo débil de este sistema. Confiar en muchas CA lo "debilita" y confiar en pocas, lo hace menos práctico.
  • ¿Qué quiere decir el gobierno francés con "un fallo humano"? ¿Cómo se pueden emitir y validar certificados para dominio que no te pertenecen a causa de "un fallo humano"? ¿Oculta un compromiso de su autoridad? ¿Tiene al "enemigo en casa"?
  • Es posible que fuesen pruebas internas, como ha declarado, con el fin de mejorar la seguridad. En estas circunstancias, podemos entender "mejorar la seguridad", como ensayos en los que se intenta comprobar cómo se defiende la seguridad de una red ante ciertos ataques de este tipo. Pero también se puede tomar esta técnica de "mejora de la seguridad" como una forma de acceder al tráfico cifrado y analizarlo. Como consecuencia inmediata, está la pérdida de privacidad para los usuarios. Si se habla de que estaba instalado en un dispositivo interno... esta última posibilidad es la más probable. Quizás el gobierno hacía de "hombre en el medio" para un ministerio en Francia, escudriñando el tráfico en busca de ataques. Pero para eso no es imprescindible crear certificados de este tipo.
  • Si no han sido víctimas de un ataque y se trata realmente se de un fallo humano, en abstracto, significa que "abusaron de su poder" para validar certificados de dominios conocidos y que los navegadores no se quejaran al respecto. O incluso, que no entendían las consecuencias de hacer lo que hicieron. Quizás a esto se refieren con el "fallo humano".
  • Si se pretendía usar estos certificados en un entorno controlado, ¿cómo escaparon de su red para que Google finalmente lo descubriese?
  • Quizás el sistema de pineo de EMET no alerta sobre estos casos concretos... pero el de Chrome sí. ¿Durante cuánto tiempo se hicieron estas prácticas? ¿Nadie usó Chrome en esa red interna? ¿Sirvió de algo el sistema de protección integrado?
Un asunto extraño, en todo caso. Se podría intuir, finalmente, que lo que ha ocurrido es que el gobierno espiaba/protegía a ciertos usuarios de una red ministerial, con la excusa de detectar ataques. Eligieron un método extraño para conseguirlo. Google, de alguna manera (y quizás ahí es donde entra de nuevo el "error humano") ha terminado enterándose y tomado cartas en el asunto, puesto que esos certificados firmados y validados para dominios tan "jugosos", en manos de cualquiera, pueden suponer un grave problema.

Sergio de los Santos
ssantos@11paths.com

Sobre cookies y sistemas de seguimiento (I)

El tracking o seguimiento a través de la web, consiste en intentar identificar al usuario que está navegando y recopilar la mayor información posible sobre él creando un perfil. Con estos datos, se podrá tratar al usuario como receptor de una publicidad más personalizada y por tanto, efectiva.

La información que maneja el usuario puede ser catalogada y almacenada en un perfil que le identifique por sus búsquedas, ubicación u horario en que usa una u otra web. A medida que se "dispersa" el acceso a internet (ha pasado del PC a los móviles y tabletas e incluso consolas y televisión), se hace más interesante para los anunciantes técnicas que permitan identificar al usuario en cualquier parte.

Veamos las propuestas de diferentes fabricantes para "solucionar" este problema, y realizar un tracking más efectivo de los usuarios.

El origen, las cookies

Las cookies fueron el primer método de "rastreo" utilizado. Una cookie es una pequeña porción de información (texto codificado como se desee) que el servidor crea en el navegador y almacena en local. En esa porción de datos (texto) se almacena temporalmente con una relación clave-valor. Solo un dominio puede acceder a su cookie establecida por él previamente.

Protocolo básico de intercambio de cookies

Gestión y visionado de cookies con Cookie Manager
Las cookies se usan para identificar a un usuario después de un login o incluso para guardar información sobre preferencias de la navegación.  Aunque en teoría, una cookie establecida por un dominio solo puede ser accedida por ese dominio, el hecho de incrustar un mismo dominio en diferentes páginas (a través de servidores de anuncios compartidos, por ejemplo) permite saber a qué páginas accede un usuario si comparten estos dominios.

Estas son las conocidas como third party cookies (de terceros) que guardan o usan información sobre el  usuario sin que este navegue directamente por ellas, aprovechando que la web embebe o incrusta página a través de una etiqueta img o iframe (por ejemplo), normalmente usado para ofrecer publicidad inteligente acorde con los gustos del usuario.

Entre la información que es posible recopilar sobre el usuario, destaca el navegador que usa, la ubicación geográfica desde donde se navega, horarios de uso, el idioma y los sitios por los que navega, así como los gustos y aficiones de este. Si se ha buscado en una tienda online algún producto, esa información queda en la cookie de esa tienda online. Pero si otra web cualquiera incrusta en ella publicidad que permite acceder a esa cookie, sabrá qué productos de la tienda se han visitado previamente y aparecerá publicidad relacionada.
Ejemplo de dominio insertado en dos páginas diferentes, ofreciendo información

Una prueba de concepto muy simple es limpiar los datos de navegación y buscar algún producto en un buscador y visitar alguna tienda. Es más que probable que en la próxima web que se visite, la publicidad esté relacionada con lo buscado previamente. Si la web no tiene suficiente información mostrara publicidad genérica o relacionada con la web visitada. La mayoría de los navegadores ya permiten bloquear las third party cookies que no es más que no aceptar cookies de un dominio incrustado en otro. Solo se aceptarán las del dominio principal que se visite.

Una de las empresas más importantes que usa esta técnica es DoubleClick, adquirida por Google. Para consultar el perfil que ha generado Google y DoubleClick es posible acceder a http://www.google.com/settings/ads donde se puede observar la información relacionada con las búsquedas realizadas y la posibilidad de editar las preferencias:

Página en la que es posible editar la configuración de publicidad de Google
También es importante destacar que al pie de la página Google avisa de la posibilidad de inhabilitar o instalar una extensión que inhabilita DoubleClick.

La ley y las cookies

En la primavera del año pasado en España se obligaba a las entidades web a indicar para qué propósito se iban a usar las cookies y solicitar la confirmación al usuario. Las posibles multas van hasta los 30.000 euros para las empresas que no cumplan con la ley.
Esta aplicación de la ley ha provocado que casi todas las páginas web actuales muestren un aviso del propósito de las cookies y soliciten la aprobación del usuario.

Pero las empresas grandes como Google, Apple, Microsoft y Facebook tienen sus propios métodos e ideas para "mejorar" el negocio. Daremos un breve repaso en la siguiente entrada.
Oscar Sánchez

EmetRules: The tool to create "Pin Rules" in EMET

viernes, 6 de diciembre de 2013

EMET, the Microsoft tool, introduced in its 4.0 version the chance to pin root certificates to domains, only in Internet Explorer. Although useful and necessary, the ability to associate domains to certificates does not seem to be very used nowadays. It may be hard to set and use... we have tried to fix it with EmetRules.

To pin a domain with EMET it is necessary
  • Check the certificate in that domain
  • Check its root certificate
  • Check its thumbprint
  • Create the rule locating the certificate in the store
  • Pin the domain with its rule

Steps are summarized in this figure:



It is quite a tedious process, much more if your target is to pin a big number of domains at once. In Eleven Paths we have studied how EMET works, and created EmetRules, a little command line tool that allows to complete all the work in just one step. Besides it allows batch work. So it will connect to domain or list indicated, will visit 443 port, will extract SubjectKey from its root certificate, will validate certificate chain, will create the rule in EMET and pin it with the domain. All in one step.

EmetRules de ElevenPaths
The way it works is simple. The tools needs a list of domains, and will create its correspondent XML file, ready to be imported to EMET, even from the tool itself (command line).

Some options are:

Parameters:
  • "urls.txt" Is a file containing the domains, separated by "\n". Domains may have "www" on them or not. If not, EMET will try both, unless stated in "d" option (see below).

  • "output.xml" specifies the path and filename of the output file where the XML config file that EMET needs will be created. If it already exists, the program will ask if it should overwrite, unless stated otherwise with "-s" option (see below).

Options:
  •  t|timeout=X. Sets the timeout in milliseconds for the request. Between 500 and 1000 is recommended, but it depends on the trheads used. 0 (by default) states for no timeout. In this case, the program will try the connection until it expires.
  • "s", Silent mode. No output is generated or question asked. Once finished it will not ask if you wish to import the generated XML to EMET.
  • "e", This option will generate a TXT file named "error.txt" listing the domains that have generated any errors during connection. This list may be used again as an input for the program.
  • "d". This option disables double checking, meaning trying to connect to main domain and "www" subdomain. If the domain with "www" is used in "url.txt", no other will be connected. If not, both will be connected. With this option, it will not.
  •  c|concurrency=X. Sets the number of threads the program will run with. 8 are recommended. By default, only one will be used.
  • "u". Every time the program runs, it will contact central servers to check for a new version. This option disables it.

Tool is intended mainly for admins or power users that use Internet Explorer and want to receive an alert when a connection to a domain is suspected to be "altered". Pinning system in EMET is far to be perfect, and even the warning displayed is very shy (it allows to get to the suspected site), but we think is the first step to what it will be, for sure, an improved feature in the future.



We encourage you to use it.

EmetRules: La herramienta para configurar "Pin Rules" en EMET

jueves, 5 de diciembre de 2013

EMET, la herramienta de Microsoft, introdujo en su versión 4.0 la posibilidad de "pinear" certificados raíz a los dominios correspondientes, solo en Internet Explorer. Aunque útil y necesaria, la capacidad de asociar dominios a certificados parece una funcionalidad poco utilizada hoy por hoy. Una de las razones puede ser la dificultar de configuración y uso... y por eso hemos intentado remediarlo con EmetRules.

Para "pinear" un dominio con EMET, es necesario:
  • Consultar el certificado de ese dominio
  • Comprobar cuál es el raíz en el que confía finalmente la conexión
  • Mirar su huella digital
  • Crear la regla encontrando el certificado en el repositorio
  • Asociar el dominio a la regla correspondiente
Los pasos se resumen en esta figura.


Es un proceso bastante tedioso, sobre todo si se quieren "pinear" un buen número de dominios. En Eleven Paths hemos estudiado el funcionamiento de EMET, y creado EmetRules, una pequeña herramienta por línea de comando que permite realizar todo el trabajo en un solo paso. Además permite realizarlo por lotes. Esto es, se conectará al dominio o lista de dominios indicada, visitará por el puerto 443 la página, extraerá la SubjectKey del certificado raíz devuelto, validará la cadena de certificación, creará la regla en EMET y además, la "pineará" junto al dominio. Todo en un solo paso.

EmetRules de ElevenPaths
El funcionamiento es simple. Se le proporciona un listado de dominios, y creará el archivo XML correspondiente que podrá ser importado a EMET, incluso desde la propia herramienta (por línea de comando). 

Permite algunas opciones:

Parámetros:
  • "urls.txt" El fichero que contiene los dominios, separados por retorno de carro. Los dominios pueden tener el subdomino "www" o no. Si no es así, el programa intentará usar los dos, a menos que se especifique lo contrario con la opción "-d".
  • "output.xml" especifica la ruta y nombre de fichero donde se creará el fichero XML de configuración que EMET necesita. Si ya existe, el programa preguntará si debería sobrescribirse, a menos que se especifique lo contrario con la opción "-s".
Opciones:
  •  t|timeout=X. Establece el timeout en milisegundos para la petición. Entre 500 y 1000 milisegundos son los recomendados, aunque depende de las hebras establecidas. El valor 0 por defecto indica que no hay timeout. En ese caso el programa intentará conectar hasta que la conexión expire.
  • "s", Silent mode. No se genera ninguna salida ni se hacen preguntas. Una vez terminado, tampoco preguntará si se desea configurar EMET importando el XML.
  • "e", Esta opción genera un fichero txt llamado "error.txt" que contiene el listado de dominios que han generado un error en la conexión por cualquier razón. Este listado se puede usar de nuevo para intentarlo con el programa.
  • "d". Esta opción deshabilita la doble comprobación. Esto significa intentar conectarse al dominio principal y a su subdominio "www". Si se especifica el dominio con "www" en la lista, no se intentará otro. Si no se especifica, se intentarán los dos. Con esta opción activa, no.
  •  c|concurrency=X. Establece el número de hebras con las que correrá el programa. Son el número de conexiones concurrentes. Se recomiendan unas 8. Por defecto será solo de una.
  • "u". Cada vez que se lance el programa, contactará con los servidores centrales para comprobar si existe una versión nueva. Esta opción deshabilita esta comprobación.

La herramienta está pensada para administradores y usuarios avanzados que utilicen Internet Explorer y quieran recibir una alerta cuando se sospeche que la conexión a un dominio puede estar siendo alterada. Si bien el sistema de pineo de EMET no es ni mucho menos perfecto, e incluso la alerta que emite es muy tímida (sigue permitiendo visitar la web), es el primer paso de lo que seguro será una funcionalidad mejorada en el futuro.
Ciertos dominios devuelven diferentes certificados raíces válidos, dependiendo del país desde el que se visite u otras circunstancias. La herramienta por su parte, no permite pinear varios certificados a un mismo dominio, por lo que estará ligada al lugar donde se ejecute.

Se puede descargar desde: http://elevenpaths.com/downloads/emetrules.zip

Invitamos al uso de la herramienta.

Cómo se comprueba la integridad de un programa en Java

miércoles, 4 de diciembre de 2013

Hace unos meses hablamos de cómo se comprobaba la firma digital de los ficheros ejecutables en Windows. Veamos en esta ocasión cómo funciona la firma digital de ficheros creados en Java, su estructura interna y cómo se realiza la comprobación paso a paso.

Keystore de CAs en Java
Los programas en Java pueden tomar forma de ficheros .jar, .apk... según se usen para ejecutables, applets, programas para Android... 

En realidad no son más que zips con un formato muy característico. Los ficheros de este tipo firmados, además, contienen en su interior una serie de archivos que permiten garantizar su integridad y, en cierta forma, su procedencia gracias a un certificado. Los certificados de los programas Java firmados, se validan en un "keyring" de CAs que viene de serie con la instalación de Java, y que es independiente al de Windows o del navegador Firefox, por ejemplo. Los applets, sin embargo, sí que se pueden "validar" contra el keystore de Windows.

En general, la comprobación de la firma se realiza "normalmente" con la misma aplicación del SDK de Java que permite firmarlos (jarsigner), solo que modificando la opción. Por ejemplo:

Ejemplo de validación de firma de un APK
Lo que ofrece información sobre ficheros, la verificación, etc... pero ciertamente es una información muy pobre y peor presentada visualmente. ¿Qué está ocurriendo internamente? En realidad, varias comprobaciones diferentes. Toda la información relativa a la firma e integridad se almacena dentro, en el directorio META-INF del ZIP. Ahí se pueden encontrar varios ficheros. Vayamos por partes.

Manifest.mf

Es un fichero donde se incluye el hash (normalmente SHA1) de cada fichero contenido en el ZIP. El hash se codifica en base64. El formato es simple: primero unas cabeceras, y luego "Name" y SHA1-Digest (que puede ser SHA256-Digest). Por ejemplo, AfPh3OJoypH966MludSW6f1RHg4= , decodificado en hexadecimal da como resultado 01f3e1dce268ca91fdeba325b9d496e9fd511e0e que es el SHA1 de ese archivo.

Abajo, en la imagen de la izquierda se observa un ejemplo real de manifiesto.

Un fichero Signature File (extensión SF)

También en el directorio META-INF, se encontrará un fichero con cualquier nombre, pero de extensión SF (signature file). En él se observan de nuevo unas cabeceras, y un formato muy parecido al del manifiesto, con lo que se diría que es el SHA1 de cada fichero... otra vez. Pero curiosamente, diferente al valor que se muestra en el manifiesto. En realidad, el hash que aparece el el signature file, no es el hash del fichero, sino de las tres líneas del manifiesto donde se muestra el hash. Si se almacenan tal cual las tres líneas (Name, SHA1-Digest y una en blanco) en un archivo de texto, se calcula su SHA1 y se codifica en base64, el resultado sería el que aparece en el signature file.

Fichero manifiesto a la izquierda y "signature file" a la derecha de un mismo APK.
En la cabecera del signature file, a través de SHA1-Digest-Manifest, se calcula al SHA1 del fichero del manifiesto. Efectivamente, en el ejemplo, Og+1qY7DjNHiykvwIOijpOUYPBI= coincide con el SHA1 en hexadecimal de archivo de manifiesto... Como el manifiesto a su vez, contiene el hash del resto de archivos, estamos de esta forma "validando" a todos los ficheros internos de una vez. Comprobando el hash del manifiesto (en el signature file), de alguna manera, comprobamos el resto de archivos. En esta imagen de ejemplo, se resume todo.



El certificado

Lo explicado hasta ahora cubre la integridad, pero no se ha hablado de la criptografía pública. ¿En qué punto entra el certificado? Finalmente, en el directorio META-INF se puede encontrar un fichero con extensión DSA o RSA, según se use uno u otro algoritmo de firma digital.

Lo que se firmará con la clave pública del certificado, es el hash del fichero "signature file". Así se "cierra el círculo". El manifiesto mantiene un listado de todos los ficheros internos y su integridad, el "signature file", mantiene la integridad del manifiesto. Y el signature file es firmado con una clave pública.

La verificación

La verificación se puede observar en el  propio código fuente de Java o OpenJDK o en su documentación. Resumiendo, se hace en varios pasos:

1) Se verifica la firma asímétrica del signature file (extensión .SF). Se verifica la firma RSA o DSA contra el certificado.

2) Si existe el valor "SHA1-Digest-Manifest" (u otro SHA) en el fichero SF, se comprueba que es el correcto. Con esto se asegura que el manifiesto no ha sido alterado. Si es correcto, se elude el paso siguiente (y se pasa al 4).

3) Si esa cabecera no existe, o su valor no es correcto (se asume que se ha modificado el hash del manifiesto), no se considera inválido el archivo jar o apk directamente. En realidad, se hacen dos cosas:
  • a) Si existe la cabecera Digest-Manifest-Main-Attributes en el fichero SF, se calcula el hash de los atributos principales del manifiesto. Los "atributos principales" son esos primeros datos que aparecen en el fichero y que no corresponden propiamente a cada archivo interno. Si no es válido, la comprobación falla.
  • b) Si no existe esa cabecera, se comprueba una a una cada entrada en el fichero SF. O sea, que el SHA1 corresponde a esas tres líneas del manifiesto. Con esto gana velocidad y eficiencia, puesto que no tiene que calcular el hash de cada fichero, sino que se fía de que el hash ya calculado en el momento de compilación y contenido en el manifiesto, no haya sido alterado. Si algo falla, la firma falla.
4) En el cuarto paso, se comprueba cada fichero, su hash real, contra el calculado en el manifiesto.

El modelo en general es bastante curioso. Se puede dar el caso en el que difiera el hash real del manifiesto con el  hash del manifiesto almacenado en el fichero de firmas... pero que eso no signifique que la firma no sea válida. Y esto es así porque se pueden añadir ficheros a un .jar, sin que se altere su firma. De hecho, si se usa la herramienta "jar" para añadir ficheros al programa, cambiará el manifiesto, pero no el fichero de firmas. Así que su firma con el certificado no se ve alterada y seguirá siendo válido la firma digital, aunque el ZIP en sí sea completamente diferente. Si se da el caso, para alertar de este hecho, durante la verificación simplemente se mostrará un warning de este tipo:

Warning:
This jar contains unsigned entries which have not been integrity-checked.

Como siempre, una firma válida habla de la integridad (y posible procedencia, según el certificado) de la aplicación, pero nada de sus intenciones sobre el sistema...


Sergio de los Santos
ssantos@11paths.com