Un fallo en la verificación de firmas de Android permite modificar las aplicaciones certificadas

Sin detalles técnicos, Jeff Forristal CTO de Bluebox, indicó en un post en el blog de la empresa que están trabajando junto con Google desde el pasado mes de febrero para solucionar el fallo. Según Forrestal, han encontrado un error en el modelo de seguridad de Android que posibilita la modificación de un APK firmado sin que la firma electrónica se rompa.

El fallo podría hallarse desde el primer sistema Android, 1.6 ‘Donut’ publicado hace casi 4 años, hasta el más reciente.

Android requiere que todas las aplicaciones estén firmadas digitalmente. Esto es, cada desarrollador ha de tener una clave privada, generada por el mismo, con la cual firma la aplicación que ha creado. Esta firma nos permite saber dos cosas: Quien es el creador de la aplicación y si la aplicación ha sido manipulada.

Cualquiera puede crear un certificado y firmar una aplicación. El uso de certificados autogenerados es algo que está extendido como práctica habitual en el mundo Android. El problema reside en la confianza. Si no conoces al desarrollador y no confías en el puedes optar a no instalar su aplicación. ¿Pero que ocurriría si la aplicación que estas a punto de instalar viene de una firma reconocida, digamos el propio fabricante del teléfono?

Idealmente, la firma digital del paquete sería invalidada si intentáramos modificar el paquete original. Es decir, si abrimos el paquete, modificamos su código e intentamos construir un APK nuevo, la firma ya no debería ser la misma. El fallo que Bluebox ha anunciado permitiría exactamente eso: Modificar un APK original de un fabricante reconocido y volver a generar un paquete con firma idéntica, con lo cual estaríamos viendo un paquete “original” con contenido manipulado. Sobra decir que contenido manipulado es equivalente a malware de cualquier tipo, desde el robo de información personal hasta el envío de SMS Premium o funcionalidad espía.

Android usa la herramienta ‘keytool‘ del SDK de Java (Oracle) para generar certificados y firmar nuestros APK, por lo que cabe suponer que la vulnerabilidad no se encuentra ahí, ya que esto supondría que las aplicaciones Java firmadas por esta misma herramienta serían susceptibles al mismo error, quedando expuestas de la misma forma.

En principio, ‘keytool‘ usa tu llave privada para firmar cada uno de los archivos del APK. Esto es, no se firma el APK en su conjunto.

Esto es un extracto de lo que vemos cuando usamos la herramienta ‘jarsigner‘, también del SDK de Java, para comprobar que todos los archivos que contiene el APK están firmados correctamente (jarsigner –verify –verbose archivo.apk):

Hemos descomprimido el APK e insertado un simple archivo (el contenido es lo de menos). Podemos observar que el archivo insertado no tiene la cadena «sm» puesto que la verificación ha fallado. La ‘s‘ significa que la firma ha sido verificada y ‘m‘ que el archivo en cuestión se encuentra dentro del manifiesto.

Si intentamos instalar la aplicación el proceso se detendrá:

 Si quitamos el archivo intruso y probamos de nuevo:

Resulta intrigante, si el fallo no reside en el proceso de firmado con ‘jarsigner‘, comprender donde se encuentra el error, ya que si introducimos un archivo nuevo este no estará firmado y si modificamos uno ya existente el sistema lo indicara con el mismo mensaje.

Forristal habla de “discrepancias en como Android criptográficamente verifica e instala las aplicaciones, permitiendo modificar código del APK sin romper la firma criptográfica”. Curioso también el paso dado por Google hace unos meses: Eliminó de Play aquellas aplicaciones que se actualizaban a través de otros canales que no fueran su tienda.

Tendremos que esperar hasta la próxima conferencia «BlackHat» en Estados Unidos para que en una de las charlas previstas, Bluebox nos muestre como saltar la comprobación de firma de Android.

Ahora la cuestión será saber cuanto tardarán los fabricantes en adoptar el parche en el que está trabajando Google. Tradicionalmente, los fabricantes, suelen tardar meses en liberar una actualización de su firmware para el teléfono. Meses que podrían convertirse en una ventana de exposición considerable para los usuarios e incluso eterna para aquellos sistemas que han dejado de ser soportados.