Un error en Android permitía a una app instalar cualquier otra de forma transparente

miércoles, 19 de marzo de 2014

Daniel Divricean ha descubierto un fallo interesante en Android, que permitía la instalación de cualquier aplicación (con cualquier permiso) en cualquier dispositivo de un mismo usuario sin que se diera consentimiento explícito. El fallo fue descubierto en diciembre y ha sido corregido ahora.

La prueba de concepto construida por Divricean consistiría en crear una aplicación (que sería considerado como el "troyano") con permisos en principio inocuos o poco entendidos, como:
  • android.permission.INTERNET: Permiso para acceder a la red. Algo muy habitual.
  • android.permission.GET_ACCOUNTS: Permiso para acceder a la lista de cuentas. Muy usado, y poco entendido por los usuarios en general.
  • android.permission.USE_CREDENTIALS: Permite a las apps utilizar los tokens de autenticación del AccountManager.
Esta aplicación, crearía un WebView, que no es más que una ventana a una web. Se presentaría con la cuenta de Google del usuario gracias a los tokens recogidos con el permiso correspondiente. Esto sería transparente para el usuario. Esta web cargaría el Google Play e inyectaría JavaScript en la página. Con este código obtendría información del dispositivo y los tokens CSRF, además de la lista de otros dispositivos (si el usuario estuviera presentado en ellos con la misma cuenta). Desde aquí, podría requerir que se instalara cualquier aplicación de Google Play en el dispositivo o en otros bajo la misma cuenta. El usuario no podría detenerlo, y no se le preguntaría confirmación alguna.

Cabe recordar que ya existe la posibilidad de que las aplicaciones se actualicen de forma transparente, pero bajo dos condiciones: que posean el mismo certificado, y que no cambien sus permisos. De lo contrario, la app pedirá confirmación. El método encontrado por Divricean elude todo esto, y permite una instalación transparente de cualquier aplicación, con cualquier permiso. Como si el usuario aprobara la instalación desde el navegador en Google Play. Y esto es muy peligroso.

El investigador plantea escenarios todavía más complejos, en los que la app podría abrirse a pantalla completa y ocultar incluso la barra de instalación que delataría el proceso aunque sea automático. También la instalación en dispositivos diferentes, por lo que el usuario no notaría nada en el dispositivo donde ha instalado esa primera app con pocos permisos y que realizará la instalación posterior.

Google fue informada en diciembre, pero no se ha hecho público hasta que la solución no ha sido desplegada y se encuentra operativa. Parece que ahora impide que el navegador pueda presentarse de forma automática con la cuenta. Mostrará un texto advirtiendo que la aplicación quiere tener acceso a los datos de Google, y será el usuario el que tenga que aprobar esto explícitamente.

Si el usuario lo permite, parece que volveríamos a estar en la misma situación de peligro, y la aplicación podría instalar otras apps de forma transparente. Esta es la razón por la que Divricean prefiere no publicar la prueba de concepto... aunque con las pistas dadas, no resultaría difícil crearla.

Un modelo confuso

Existen varias mitigaciones en el modelo de ataque propuesto por Divricean. En principio el usuario debe instalar una app maliciosa con ciertos permisos reducidos. Pero, ¿es esto un problema realmente? Además, no olvidemos que las ya instaladas con estos permisos podrían actualizarse automáticamente (siempre que mantengan el certificado y los permisos) para realizar este ataque.

El hecho de que este fallo solo permita la instalación de apps ya alojadas en Google Play tampoco resta importancia al problema. Google mantiene una política de lista negra. En Google Play no es nada complicado subir aplicaciones troyanizadas, malware, o adware muy agresivo. Pueden desaparecer más o menos rápido, pero desde luego, no se debe transmitir la idea de que usar el market oficial es una garantía.

Además, la solución no parece muy robusta. Permitir al usuario la toma de decisiones sobre acciones que no termina de entender no resulta una barrera muy compleja de eludir para un atacante. El usuario nunca ha sido ni será bueno, a la hora de tomar decisiones de seguridad. Incluso las advertencias más llamativas y los permisos más explícitos no podrán con un usuario medio que confía en la aplicación, desconoce lo que implican los permisos y además, toma decisiones basadas en su comodidad eludiendo toda seguridad.

En el fondo, confiar en un modelo de permisos tampoco es una buena solución. El usuario (incluso los más avanzados) no saben que permisos aparentemente inocuos pueden suponer un problema grave para la privacidad y, como demuestra este fallo, pueden suponer el primer paso hacia un mal mucho mayor. De hecho, el adware (el malware más numeroso en Android) no necesita de tantos permisos como se piensa. Los atacantes saben adaptarse. Desde que con Windows Vista, el usuario no suele ser administrador "por defecto" (en rigor sí lo es, pero le separa el UAC de sus "poderes") el malware para Windows ha tenido que adaptarse a las circunstancias y asumir que no disponía de plenos permisos en el equipo. Se han revalorizado las posibilidades de elevar privilegios, sí, pero también la imaginación para explotar al usuario con los recursos de los que se disponen. De ahí, el auge del ransomware y el virus de la policía. No necesitan permisos especiales (con acceder a donde más duele al usuario, a sus documentos y fotos, le vale) y resultan igual de lucrativos. Un claro ejemplo es esta app falsa para Whatsapp alojada durante horas en Google Play, de la que ya hablamos hace tiempo, que necesitaba menos permisos que la original. Y eso no la hacía más segura precisamente.

WhatsApp Messenger falso colgado en Google Play

Por último, el sistema de "always logged in" de Google, que convierte Internet en una suerte de Single Sign-On para el usuario tanto en sus dispositivos como en la red, parece que también puede trasladar y amplificar problemas de una manera más compleja.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario