#MundoHacker: Funciones de usabilidad de Android como vector de ataque

accesbility service

Creo que todo lector asiduo a esta página es ya consciente que la seguridad absoluta es inalcanzable.

Los equipos azules de las organizaciones se dedican en cuerpo y alma a segurizar sus sistemas y productos, conscientes de que están ante una lucha perdida de antemano.

A los malos les basta con encontrar una sola manera de comprometer la seguridad de los sistemas. A los buenos, les toca intentar descubrir cuál puede ser la próxima ventana que éstos utilizarán para realizar sus fechorías. Hacer de adivinos parcheando todos y cada uno de los potenciales vectores de intrusión, conocidos y aún por conocer. Y que todo ello no afecte sensiblemente a la usabilidad del sistema y a la experiencia que los usuarios/clientes tienen en él.

Hace unos días le contaba cómo un permiso necesario para hacer retrocompatibles la mayoría de aplicaciones en Android era precisamente un foco de riesgo de nuestra seguridad. Recientemente hemos sabido de la existencia de un ataque dirigido a dispositivos Android, que afecta por igual indistintamente de la versión instalada.

Vamos a explicar cómo funciona.

Cómo funciona Cloak and Dagger

El ataque, que ha sido bautilizado como Cloak and Dagger, fue expuesto directamente a Google en al menos tres ocasiones (según los investigadores), y viendo que Google no movía ficha, decidieron crear la página cloak-and-dagger.org (EN) para explicar su funcionamiento.

Básicamente, algunos empleados del Instituto de Tecnología de Georgia y de la Universidad de Santa Bárbara, en California, encontraron una manera de aprovechar algunos de los permisos de Android dirigidos principalmente a funcionalidades de accesibilidad del sistema para crear aplicaciones maliciosas capaces de escalar privilegios, robar credenciales de otras apps y, en definitiva, cualquier maldad que a uno se le pueda ocurrir en entornos móviles.

Un problema muy habitual en el sistema operativo de Android, que en este caso en particular se agrava ya que estas aplicaciones no necesitan pedir explícitamente en tiempo de instalación acceso a las funciones de accesibilidad, y por ello, pueden pasar fácilmente los controles de seguridad de Google Play.

Concretamente hacen uso de dos funciones:

  • SYSTEM_ALERT_WINDOW (EN): Una ya conocida por estos lares, y que permite a una aplicación ocupar la interfaz de cualquier otra, superponiéndose.
  • ACCESSIBILITY_SERVICE (EN): Un conjunto de funciones creadas para dotar al sistema operativo de herramientas para que una persona con problemas auditivos y/o de visión pueda utilizarlo.

El ataque consta de dos partes bien diferenciadas.

Control de la interfaz:

Una vez el usuario ha instalado la aplicación maliciosa, ésta se encarga de, esgrimiendo las razones que sean oportunas (aquí entra la ingeniería social), forzar al usuario a que haga acciones que permiten a la app obtener los permisos y credenciales de acceso de otras aplicaciones.

¿Qué cómo lo hace? Como ya hemos visto hace tiempo:

Secuestrando la interfaz gracias a SYSTEM_ALERT_WINDOW, de manera que mientras que el usuario piensa que está por ejemplo logueándose en Facebook, realmente lo que está es metiendo sus credenciales de acceso o aceptando permisos a la aplicación maliciosa para que esta pueda interaccionar en su nombre en Facebook.

En uno de los ejemplos mostrados por este grupo, la aplicación en particular creaba una capa transparente que se superponía a la interfaz del teclado nativo de Android, de forma que todo lo que teclease el usuario era capturado. En definitiva, la creación de un spyware de tipo keylogger.

Ver en Youtube (EN)

Utilizando las funciones de accesibilidad del sistema:

Esta es la parte interesante (y, hasta cierto punto, más novedosa) del ataque.

ACCESSIBILITY_SERVICE es un conjunto de funciones para que los desarrolladores puedan ofrecer accesibilidad a personas con sentidos reducidos. Por ejemplo, permite que una aplicación tenga la opción de leer en voz alta lo que se muestra en la pantalla, o es capaz de forzar el cambio de tipografía y los colores de pantalla con el fin de mejorar la legibilidad del sistema para personas con visibilidad reducida.

Y puestos a hacer el mal, por supuesto, te está ofreciendo una serie de recursos casi ilimitados para hacerse con el control del sistema. Desde spyware (si puedes leer el contenido mostrado en pantalla, puedes espiar), pasando por la automatización de acciones presuntamente por parte del usuario (genial para botnets, por ejemplo).

Google es consciente de la criticidad de esta herramienta, y por ello, para que una aplicación pueda hacer uso de la misma es necesario que el usuario proactivamente lo habilite dentro de los Ajustes del Sistema.

Es aquí donde entra el anterior permiso, SYSTEM_ALERT_WINDOW. La aplicación maliciosa se encarga de engañar a la víctima para que piense que está realizando X acciones, cuando realmente está navegando por debajo a los Ajustes del Sistema y concediendo permisos de accesibilidad a esta app.

Gracias a ello, la app puede realizar compras en Google Play, o instalar nuevas apps con los permisos que estimen oportunos. Un clickjacking de guión que llega a operar incluso en modo silencio (mientras el usuario está viendo un vídeo, con la pantalla apagada…).

Ver en Youtube (EN)

Un problema de confianza

Como puede ver, el principal problema viene más bien dado por los límites de legitimidad que debería tener un desarrollo de terceros en un sistema operativo como Android.

¿Dónde ponemos el límite?

Tanto SYSTEM_ALERT_WINDOW como ACCESSIBILITY_SERVICE son utilizadas por muchísimas aplicaciones legítimas, y en el caso de la segunda, es crítica para un porcentaje de la sociedad que de otra manera no podría utilizar dispositivos tecnológicos.

Encontrar un equilibrio entre los controles que debería pasar un desarrollo de terceros legítimo para por ejemplo poder leer en voz alta el contenido mostrado, y diferenciarlo de aquellos desarrollos que podemos considerar maliciosos, suena más bien a utopía.

De nuevo, seguridad vs usabilidad.

Y de cara al usuario hay también poco que podamos hacer para defendernos.

  • Instalar únicamente aplicaciones del market oficial ampliamente conocidas: Lo que a priori minimiza el riesgo a que sean maliciosas… siempre y cuando su desarrollo no haya sido comprometidoo haya sido vendido a terceros.
  • Revisar los permisos y comentarios que éstas tengan: Lo primero por razones obvias (una aplicación de linterna no debería tener acceso a los contactos), y lo segundo porque de nuevo, minimizamos ligeramente la posibilidad de que esa aplicación sea fraudulenta. Es raro que una app de este estilo, que cuente con millones de descargas y miles de valoraciones, haya pasado tanto tiempo sin que alguien se haya dado cuenta de que en efecto está utilizando mecánicas de tapjacking para vaya usted a saber qué.
  • Evitar todo lo posible tener el terminal rooteado: En este caso en particular el ataque hubiera funcionado tanto si el dispositivo era root como si no, pero hay muchos más ataques, y bastante más comunes, que necesitan estar rooteados para funcionar. E incluso en aquellos que no lo necesitan, van a encontrar muchísimos más obstáculos para escalar privilegios (sin root, y a no ser mediante canales paralelos como es el tema de las funciones de accesibilidad, resulta prácticamente imposible). De ahí que por defecto, y a no ser que sea estrictamente necesario para uso particular, lleve años defendiendo que nada de fuentes desconocidas, ni depuración USB, ni root/jailbreak.

En definitiva, un problema histórico que vuelve a salir a la palestra. Apostar por ecosistemas digitales nos ha traído verdaderos beneficios. Pero con ello, y debido precisamente a que cada vez hay más libertad para que un tercero ofrezca un servicio a partir del ecosistema de turno, vamos a sufrir más tergiversaciones de uso cuya mitigación del riesgo se vuelve, por momentos, incontrolable.

 

Actualización el 13 de Noviembre: En AndroidPolice (EN) leemos otro caso parecido. Aplicaciones como LastPass o Tasker están utilizando los Servicios de Accesibilidad para realizar funciones que no deberían poder realizar. El pez que se muerde la cola…

 

________

Puede ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.

Y si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.

hazme patrono pabloyglesias