Llaves maestras y vulnerabilidades

Las últimas semanas han estado bastante agitadas debido a los anuncios del descubrimiento de llaves maestras o llaves maestras chinas que se califican como vulnerabilidades críticas para la plataforma Android. Aunque las aguas se han calmado un poco, seguimos pendientes del acto final de Black Hat USA en Las Vegas, en el que Jeff Forristal (el investigador que descubrió una de las dos vulnerabilidades mencionadas) se referirá en detalle al caso (nunca se sabe cuándo surgen las sorpresas). Sin embargo, ya contamos con suficiente información para evaluar su impacto.

Primero, el término “llave maestra” (master key) es un poco engañoso, pues en realidad la vulnerabilidad no involucra ninguna codificación primitiva, sino que se almacenan dentro de la aplicación Android (el archivo apk) dos versiones del mismo recurso a fin de evadir parcialmente algunas verificaciones de integridad. Sin embargo, el impacto es prominente ya que significa que un adversario puede alterar un archivo apk firmado por una autoridad confiable, con el fin de incluir un recurso modificado en lugar del genuino (resulta fácil ver el caso de un classes.dex modificado como el más peligroso).

El classes.dex inyectado no impide el proceso de verificación.

Desde la perspectiva del usuario, esto significa que una aplicación publicada y formada por “FamousCompany ™” puede en realidad incluir algunos códigos maliciosos. Sin embargo, el hecho de que Play Store (la principal tienda de aplicaciones para todos los dispositivos Android) haya sido parchada para rechazar aplicaciones empacadas como archivos zip incluyendo el mismo archivo repetido, mitiga en gran medida el problema. Pero, según algunos informes, se han detectado algunas aplicaciones mediante esta vulnerabilidad, aunque inofensivas, y muy posiblemente por equivocación (el archivo zip de la aplicación en cuestión incluía el mismo recurso png repetido). Esto significa que las verificaciones de seguridad se aplican sólo a aplicaciones que se acaban de subir, y que no se analiza todo el conjunto de aplicaciones.

Por si eso fuese poco, sólo unos pocos dispositivos (sólo se ha informado del Samsung Galaxy S4) son capaces de ejecutar el código que repara esta vulnerabilidad. Esto resulta muy interesante si consideramos que muchos usuarios consiguen aplicaciones de otras tiendas de aplicaciones, que quizás no bloquean los archivos apk subidos. Si la tan debatida fragmentación de dispositivos no está matando la industria del desarrollo de aplicaciones, nos preguntamos cuántos usuarios estarían dispuestos a aceptarla si diera como resultado una constante exposición a virus como este. De cualquier manera, esta es otra razón por la que los mismos investigadores han publicado una aplicación (https://play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner) que verifica si tu dispositivo está expuesto. Los productos de Kaspersky Lab aseguran que tu dispositivo no cuente con ninguna aplicación que explote vulnerabilidades gracias a la red Kaspersky Security Network (KSN).

Dicho esto, la mejor manera de estar protegido contra estas amenazas es evitando las tiendas de aplicaciones no oficiales y no marcando la casilla “Instalar desde fuente desconocida”.

Teniendo esto en cuenta, analizaremos las vulnerabilidades, para ver por qué y cómo se las arreglan para burlar las medidas de seguridad. Una aplicación para Android no es más que un archivo comprimido Zip que incluye todo tipo de recursos: bits ejecutables, imágenes, datos de hilos, datos de diseño, etc. La integridad se mantiene mediante el haseho (y hasheo de los hashes) de todos los recursos incluidos para detectar cualquier modificación no autorizada. El proceso también es automático, y se realiza cuando se instala la aplicación. Los usuarios cuidadosos pueden también verificar un archivo apk con el comando “jarsigner -verify -verbose” command, cuyo resultado, en el caso de una aplicación regular, es similar al siguiente:

Si, por ejemplo, quisiéramos modificar el archivo main.xml, el proceso de verificación fallaría de inmediato:

Después de instalarse, el sistema operativo Android hace exactamente lo mismo. Resultó que, a diferencia de jarsigner, no le gustan mucho algunos casos como cuando el archivo zip incluye entradas duplicadas. En particular, si se incluyera en el apk un recurso con un nombre duplicado (no es muy fácil, pero ten paciencia), el sistema operativo verificaría sólo uno de los dos, y cargaría el otro. Mira por ejemplo el siguiente archivo apk (conseguido aquí):

Observa que el archivo classes.dex aparece en dos casos, con la entrada más reciente potencialmente maliciosa. Lo que es frustrante es que jarsigner avisa de inmediato que algo está mal:

Consideremos que el estándar ZIP (detalles aquí) en realidad no permite entradas múltiples que compartan el mismo nombre de archivo. Sin embargo, como ha notado Saurik, en realidad Android usa dos implementaciones distintas para descomprimir un archivo zip. Las diferencias sutiles entre ambas son suficientes para que el proceso de verificación ignore por completo la primera entrada.

Apenas diferente, aunque igual de peligrosa, es la segunda vulnerabilidad que ha aparecido en los últimos días. Un grupo de seguridad chino, que se autodenomina “el Escuadrón de seguridad de Android”, descubrió el virus que permite las mismas acciones que el descubierto por Jeff Forristal: inyección y ejecución del código ejecutable obviando las verificaciones de seguridad. También en este caso, el virus surge de utilizar dos implementaciones distintas para leer (y descomprimir) el archivo apk. Sin embargo, en este caso la culpa recae en cómo se maneja el campo “Extra field length” (parte del encabezado ZIP). Este campo, que normalmente se fija en 0, especifica la longitud de algunos metadatos muy poco usados. No resulta sorprendente (rara vez hemos visto lo contrario al observar tipos o protocolos de datos binarios) que este valor se guarde como un entero sin firma (16-bit, para ser precisos). Aunque es común para los lenguajes de bajo nivel razonar en términos de tipos de datos sin firma, algunos lenguajes como Java no pueden hacerlo. En realidad, Java puede ser el peor cuando se trata de tipos de datos sin firma: todos los tipos de datos (con la única excepción de caracteres) tienen firma.

Todos los programadores de Java con algo de experiencia saben que el uso de datos binarios te obliga a cubrir todo el programa con una serie de máscaras (& 0xffff) para poder utilizar correctamente los datos sin firma. Por desgracia, no es el caso de la biblioteca de Java utilizada para analizar los campos de datos adicionales. Aunque los bits están en realidad guardados correctamente, cada vez que se accede a ellos para realizar, por ejemplo, un cálculo tipo bound-check, tienen que interpretarse como enteros de 16-bit firmados (con bajos valores que se leen como valores negativos). Esta dicotomía lleva, una vez más, a la situación en la que el verificador ve un código, mientras que el cargador (que correctamente maneja ese campo como un número sin firma) ve otro.

Ahora, tranquilízate porque todos estos virus ya se han registrado, se han hecho las reparaciones correspondientes, y los binarios actualizados están en camino a tu dispositivo (la efectividad de la política de diseminación queda por ahora fuera del alcance de este análisis). Sin embargo, la responsable del impacto limitado en ambos casos es la divulgación. La pregunta real y que nos preocupa es la siguiente: ¿Y si la divulgación no hubiese sido la responsable?