#MundoHacker: Tapjacking, secuestrando las pulsaciones de pantalla

tapjacking

Una de las estrategias esgrimidas por la mayoría de herramientas de análisis de seguridad en tiempo de acción pasa por revisar el código de la aplicación o programa que se está instalando o abriendo con el fin de detectar posibles series de peticiones que habitualmente están relacionadas con actividades maliciosas.

En entornos móviles, y debido a la paulatina sofisticación de permisos con los que estos sistemas cuentan, esa limitación de peticiones que el desarrollador de una aplicación tiene a la hora de crear el producto juega tanto a favor como en contra de las herramientas de seguridad, puesto que la mayoría de peticiones podrían ser usadas tanto con fines legítimos como maliciosos.

De todas ellas, quería centrarme en una que por su idiosincracia pasa habitualmente desapercibida tanto por estas herramientas, como por el usuario final.

Así, en este nuevo capítulo de la serie #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital, hablaremos del tapjacking, un ataque que permite a los ciberdelincuentes ocultar sus fechorías a ojos de la víctima, que pasa a ser un mero ejecutor del mismo.

Sobre el Tapjacking nativo en entornos Android

El funcionamiento del tapjacking es sencillo.

La víctima instala una aplicación aparentemente legítima (por ejemplo, un juego), que no tiene apenas permisos.

Una vez abierta, la aplicación pedirá al usuario que pulse una secuencia de acciones, convenientemente ofuscadas bajo el uso esperable de la aplicación (un aparente registro, o el navegar por un menú convenientemente diseñado para tal labor).

Por detrás, lo que en verdad está haciendo el usuario es realizar esas pulsaciones en un entorno distinto, que podría conllevarle la instalación de otras aplicaciones (permisos aceptados incluidos), el robo de datos (dándole a la aplicación no legítima los permisos para acceder a datos de otra aplicación) o en definitiva, cualquier otro fin malicioso (difusión de malware, formar parte de una botnet, enriquecimiento ilícito del cibercriminal mediante sistemas de publicidad clickeables,…).

Todo esto se lleva a cabo gracias a una API específica de Android llamada TYPE_SYSTEM_ALERT (EN), la cual permite a los desarrolladores mostrar una alerta superpuesta a un layout que es en la práctica (y siempre y cuando sea opaca y ocupe todo el ancho y alto de la pantalla) lo que verá el usuario.

Para poder hacer uso de esta API, la aplicación debe pedir permisos en tiempo de instalación de Apertura de Ventanas de Alerta (SYSTEM_ALERT_WINDOW (EN)), y puede controlar qué clicks deberán ser transmitidos a la actividad subyacente mediante varios parámetros (not_touch_modalnot_touchablenot_focusable, …).

Un ejemplo lo tenemos en este vídeo (un tanto antiguo aunque útil para escenificar el funcionamiento, que se aprovechaba además de una vulnerabilidad que ya fue corregida y que permitía acceder a los ajustes del sistema) en el que desde una aplicación aparentemente insulsa se activaban los permisos para instalar aplicaciones no verificadas.

 

Otro ejemplo lo encontramos en la web de ESET (ES), donde la aplicación TuneMatch, que en principio reproducía algún tipo de sonido, tiene por debajo la Play Store y fuerza al usuario a instalar la aplicación oficial de Twitter (que en vez de esta app, podría haber pedido instalar alguno de los malwares presentes en el market).

tunemach tapjacking

Ahora se preguntará si este problema afecta únicamente a Android, y lamento informarle que no es así.

Los navegadores embebidos como herramienta de tapjacking para Android, iOS y WP

Navegando por internet para documentar el artículo, me encuentro con un estudio realizado por Tongbo Luo, Xing Jin, Ajai Ananthanarayanan y Wenliang Du de la Universidad de Syracuse (Nueva York), en la que demuestran cómo utilizando las APIs propias de encapsulado de navegador en aplicaciones es posible hacer tapjacking (EN) (touchjacking, que lo llaman).

Básicamente se trata de explotar la API específica de cada SO (WebView (EN) en Android, UIWebView (EN) en iOS, y WebBrowser (EN) en Windows Phone), para mostrar una pestaña superior a la web objetivo que será opaca para el usuario, y transparente para las acciones de este.

Los ataques se basan en “jugar” con las APIs que no dependen directamente de WebView (que sí controla que no se produzca este tipo de ataques), sino que heredan de esta, y al menos en el momento de publicación de este paper (2012) todos los sistemas eran vulnerables. Me he encontrado no obstante algunos de 2015 (este (EN) por ejemplo) en el que siguen ratificando que el problema persiste.

Suplantación de actividades como herramienta de robo

Existe otro tipo de ataque que si bien no es exactamente un tapjacking bebe de la misma filosofía. Se trata de que una aplicación esté continuamente monitorizando el uso que la víctima está haciendo del terminal, y tan pronto vea que esta hace la petición adecuada (por ejemplo, abrir su GMail), lanzaría una actividad que mostraría por pantalla algún tipo de acción.

Lo habitual es que el usuario entienda que esta actividad está siendo lanzada por la aplicación legítima, y por tanto, no dude en volver supuestamente a loguearse (cuando en realidad seguramente está enviando sus datos a un servidor externo) o de permisos a la aplicación maliciosa para acceder al contenido de la legítima.

Y digo que no es exactamente un tapjacking porque no hay superposición de pantallas (o al menos, no suele ser necesario que la haya), sino que simplemente se cancela la petición original (o se pospone) y se lanza la maliciosa, escudándose en que esta ha sido lanzada por la víctima.

Como ve, una manera más de aplicar ingeniería social para el robo de credenciales o la usurpación de identidad, y difícilmente rastreable por las herramientas de seguridad con las que cuenta el sistema (puesto que en la práctica no tendría porqué ser considerado un movimiento peligroso).

¿Cómo nos defendemos del tapjacking?

No hay una respuesta sencilla, la verdad.

Diría que el primer paso es cerciorarse de que tenemos deshabilitada la opción de Fuentes Desconocidas (normalmente en Ajustes > Seguridad > Fuentes desconocidas) en Android. Esto impide (a priori) la instalación de aplicaciones fuera del market oficial, por lo que los riesgos de que se nos instale herramientas maliciosas disminuyen drásticamente.

En todo caso, y como se veía en el vídeo, al menos hace unos años era posible mediante tapjacking hacer que el usuario activara esta opción, para luego hacer que instalara lo que fuera. A día de hoy quiero pensar que ya no hay manera (al menos conocida públicamente). En iOS y WP no he encontrado problemas semejantes.

Sobra decir que debemos instalar aplicaciones alojadas únicamente en los markets oficiales. Tanto para minimizar el riesgo a ser expuestos al tapjacking como para minimizar el resto de riesgos presentes tanto en Android como en iOS. Los markets de aplicaciones no son 100% seguros, pero al menos lo son más que un market no oficial, cuyo sistema de verificación es seguramente mucho peor que este.

El sistema de reporting de los markets oficiales, y la opinión mostrada por los usuarios en los comentarios, aunque pueda haber sido tergiversada, es otro buen criterio a la hora de decidirse por instalar o no esa aplicación. No 100% efectivo, nuevamente, pero al menos es una capa extra de seguridad.

Y quizás, para “rematar la faena”, andar al loro de los posibles permisos que pida una aplicación. En el caso del tapjacking, y como hemos visto, se necesita pedir permisos de ventanas de alerta. Sin este permiso, es imposible realizar el ataque, por lo que siempre que lo veamos, deberíamos preguntarnos si en verdad esa aplicación que vamos a instalar necesitaría para algo mostrarnos una alerta.

 

Las nuevas versiones de Android parece que van a implementar por fin la instalación de apps indistintamente del número de permisos que el usuario quiera otorgarle. Es algo que hemos pedido por activa y por pasiva desde hace mucho tiempo, y al menos arroja un futuro prometedor para los que estamos preocupados por la seguridad y privacidad de nuestros dispositivos.

 

________

Realizar este tipo de artículos me lleva varias horas, y en algunos casos, gastos extra que habitualmente suplo de mi bolsillo, o gracias a esa comunidad de patronos que me apoyan realizando donaciones puntuales o periódicas.

Si le gustaría ver más de estos tutoriales y análisis por aquí. 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