Análisis Visual del Comportamiento de Aplicaciones para Android

(1)

An´alisis Visual del Comportamiento de

Aplicaciones para Android

Oscar Somarriba, Ignacio Arenaza-Nu˜no, Roberto Uribeetxeberria, Urko Zurutuza

Dpto. de Electr´onica e Inform´atica Mondragon Goi Eskola Politeknikoa

Mondragon Unibertsitatea

Emails: [email protected], {iarenaza,ruribeetxeberria,uzurutuza}@mondragon.edu

Resumen—Los dispositivos móviles inteligentes equipados con funciones avanzadas de computación y comunicaciones han crecido rápidamente. Sin embargo, a pesar de los mecanismos de seguridad existentes, y dada la cantidad creciente de dispositivos conectados a Internet, también han aumentado exponencialmente la cantidad de aplicaciones maliciosas (malware) dirigidas a ellos. En este trabajo mostramos cómo los componentes peligrosos y maliciosos del malware móvil se pueden visualizar de una manera intuitiva a fin de descubrir fácilmente qué funciones de Android pueden desencadenar el fraude. Nuestro enfoque incluye un método para interceptar llamadas a funciones (”hooking”) con el fin de recoger trazas pertinentes de la aplicación durante de tiempo de ejecución. Esto permite la monitorización de llamadas a funciones de la API de Android relacionadas con los permisos de instalación de la misma. Las trazas obtenidas se colectan en un servidor web central donde tiene lugar la visualización del comportamiento de las aplicaciones.

Palabras clave—seguridad en aplicaciones móviles (mobile application security), software malicioso en aplicaciones móviles (mobile malware), análisis Visual (visual analytics), análisis del comportamiento de aplicaciones móviles (application behavior analysis)

I. INTRODUCCION´

La adopción masiva de las comunicaciones móviles en la vida cotidiana ha tra´ıdo una necesidad de establecer en la sociedad una confianza en la infraestructura móvil, y esto supone un gran reto en la actualidad. Esto es debido a que las plataformas móviles, como teléfonos inteligentes y tabletas, as´ı como las aplicaciones móviles están aumentando expo-nencialmente en popularidad. Actualmente existen alrededor de 1 millión de aplicaciones para el Sistema Operativo móvil Android en su sitio web de ventas en l´ınea Google Play, con un estimado de 50 mil millones de descargas [1]. En contraste, el software malicioso (malware) que ataca la plataforma Android ha aumentado considerablemente en los últimos 24 meses en un 100 %. Las nuevas familias de malware Android están evolucionando rápidamente para evitar ser detectados por los escáneres tradicionales basados en firmas. Hay una necesi-dad de mejorar las capacinecesi-dades de detección para superar los nuevos desaf´ıos de detección debido a la ofuscación, y as´ı mitigar o remediar el impacto de la evolución de malware para Android.

Dado que el sistema operativo móvil más popular es An-droid OS de la compañia Google (en la actualidad tiene el 70 %

del mercado), Android es el OS más atacado con un 99 % de los ataques malware según lo publicado por Cisco y Kapersky Labs durante el tercer trimestre Q3 del 2013, y resumido en el reporte de SOPHOS [2]. Esta investigación se enfoca en el seguimiento del comportamiento en tiempo de ejecución de las applicaciones y la visualización de sus funciones maliciosas para descubrir qué tipo de ataques o intenciones existen detrás de estas. La plataforma propuesta de monitorización está compuesta básicamente de cuatro elementos, a saber: (i) una aplicación Android llamada (Sink) que gu´ıa al usuario en la selección y parametrización de la aplicación a supervisar, (ii) un cliente embebido que se inserta en cada aplicación a ser supervisada, (iii) un servicio web encargado de recoger la aplicación a monitorizar, enviar al dispositivo la aplicación instrumentada, y recopilar las trazas que va generando, (iv) y finalmente un componente de visualización que muestra grafos relacionados con el comportamiento de las trazas o llamadas a funciones, relativa a la aplicación monitorizada.

Se prevé que esta herramienta pueda ser utilizada por analistas malware con el fin de realizar una inspección visual de las aplicaciones en estudio. Por otra parte, la monitori-zación de una aplicación en el momento de su ejecución es esencial para entender cómo esta interactúa con el dispositivo, con componentes claves tales como las APIs (Application Programming Interfaces) provistas por el sistema. Una API especifica cómo algunos componentes de software (rutinas, protocolos y herramientas) deben actuar cuando estén sujetos a invocaciones de otros componentes. Al rastrear y analizar estas interacciones, podemos ser capaces de dar seguimiento a cómo se comportan las aplicaciones, a cómo manejan datos sensibles e interactuar con el sistema operativo.

I-A. Contribuci´on y organizaci´on del art´ıculo

A lo largo de este art´ıculo se presenta un método para la detección de malware, mediante el análisis visual de la ejecución de las funciones a las que llaman. La subsiguientes partes del trabajo están organizadas como a continuación se detalla. La secciónIIle da al lector las nociones básicas detrás de los componentes utilizados en las siguientes secciones y re-copila el trabajo previo relacionado con la temática. La sección

IIIdescribe la arquitectura de monitorización y visualización del sistema presentado. La secciónIVmuestra los resultados

(2)

presentan las conclusiones e identifican unas posibles l´ıneas futuras de trabajo, respectivamente.

II. ANTECEDENTES YTRABAJOS RELACIONADOS

En los ambientes convencionales de Java, el código fuente es compilado en un conjunto de instrucciones llamado byte-code, el cuál es almacenado en un formato de ficheros .class. Estos ficheros son más tarde le´ıdos por la Máquina Virtual de Java (JVM) al momento de su ejecución. Por otra parte, en Android, el código fuente de Java que ha sido compilado en ficheros .class debe ser convertido en ficheros .dex, frecuen-temente referidos como ficheros ejecutables del tipo Dalvik (Dalvik Executable). Además, Android application package file (apk), es el formato de fichero utilizado para distribuir e instalar software de aplicaciones y middleware en el sistema operativo Android. Las apps se presentan en un fichero con el formato .apk, en un contenedor de la aplicación binaria que consiste en ficheros .dex, AndroidManifest.xml, y los ficheros de recursos de la aplicación. Asimismo, el archivo .apk resultante se firma con una clave (keystore) para establecer la identidad del autor de la app. Existen métodos para realizar el proceso en el sentido inverso. Apktool es un conjunto de herramientas para realizar ingenier´ıa inversa en apps, lo que simplifica el proceso de ensamble y desensamble de ficheros binarios de Android (.apk) a ficheros Smali (.smali), permitiendo la modificación del código fuente. Esto resulta especialmente útil para el análisis de las aplicaciones.

El análisis y detección de malware para Android ha sido un tema candente de la investigación en los últimos años. Un ejemplo de los mecanismos de inspección para la identifica-ción de aplicaciones con malware para Android se presenta en [3], donde también se desarrolló un sistema de instrumentación transparente para la automatización de las interacciones de los usuarios.

Adem´as, en [4] se utiliza un marco de seguridad llamado

XManDroid para extender el mecanismo de seguimiento de

Android, con el fin de detectar y prevenir ataques del tipo escalada de privilegios a nivel de aplicación durante el tiempo de ejecución sobre la base de una pol´ıtica determinada. Adi-cionalmente, los autores en [5] y [6] han propuesto diferentes técnicas de seguridad con respecto a los permisos de las apps. Por ejemplo, en este último, se propone una herramienta para extraer la especificación de permisos del código fuente de Android OS. Por otra parte, las técnicas de detección de malware en dispositivos móviles usualmente se pueden clasificar de acuerdo al modo en el que se realiza el análisis: análisis estático y análisis dinámico. La primera se basa en intentar identificar el código malicioso por descompilación de la aplicación y la búsqueda de cadenas o bloques de códigos sospechosos; en la segunda se analiza el comportamiento de una determinada aplicación utilizando la información de su estado de ejecución. Algunos tipos recientes de detección de malware son: Dendroid [7] como un ejemplo de un análisis estático para dispositivos con Android, y Crowdroid, sistema

Jiang y Zhou [9] se han mapeado los tipos más comunes de violaciones de permisos en un gran conjunto de datos de malware. Por otro lado, en [10], [11] se pueden encontrar estudios más amplios sobre el estado del arte de la seguridad para los dispositivos móviles.

Entre los sistemas de monitorización de comportamiento de aplicaciones se encuentra una propuestas que permite visualizar mediante grafos las llamadas a funciones de una aplicación determinada, pero los autores lo hacen mediante técnicas de análisis estático [12]. El sistema hace un mapa de todas las funciones disponibles, mientras que este trabajo solo monitoriza y visualiza aquellas funciones que se suceden en tiempo de ejecución, obteniendo además los parámetros que se env´ıan a la función. No se han encontrado propuestas de detección de malware en base a análisis dinámico que opere en el dispositivo del usuario de manera muy ligera y ”online”. Esto es necesario debido a la apertura de la Plataforma Android donde el malware puede también ser instalado a través de apps de otras fuentes, tales como páginas web y de memorias USB, lo que requiere mecanismos de detección que operan en el propio dispositivo.

III. DESCRIPCION DEL SISTEMA´

En esta sección se presenta una solución aplicable para la detección de anomal´ıas producto de la presencia de malware en las aplicaciones, basada en un análisis dinámico combinado con el soporte de un servidor web.

La Figura 1 muestra la estructura de la plataforma de mo-nitorización propuesta. Las etapas para llevar a cabo la misma consisten en los siguientes pasos lógicos: Etapa I: Envió de la aplicación APP y de una lista de permisos que se desean monitorizar al Servidor Web, Etapa II: Instrumentación de la aplicación mediante un proceso de hooking generando APP’, Etapa III: Instalación y activación de la APP’ reemplazando a APP en el dispositivo, Etapa IV: Almacenamiento de las trazas de APP’ en una base de datos, y la Etapa V: Visualización de los grafos relacionados con APP’.

De nuevo, en la Figura1se muestra un diagrama de bloques formado por cuatro componentes: la aplicación Sink, un cliente embebido, un servidor web, y el componente de visualización. III-1. La Aplicación Sink: es una aplicación Android con dos funciones principales: una de gestión de la aplicación a monitorizar, y otra para el manejo de las trazas. La parte del tratamiento de la aplicación, a su vez, está compuesta de un conjunto de actividades como se muestra en la Figura2(d).

En la Figura 2(a) el usuario selecciona la aplicación que desea monitorizar, entre aquellas que no vienen reinstaladas de fábrica. En el siguiente paso se seleccionan los permisos que el usuario estime convenientes a monitorizar, relacionados con la aplicación y considerados como peligrosas según el mapa de funciones API obtenido con PScout [6]. La interfaz gu´ıa después al usuario a lo largo de varias actividades donde se llevan a cabo la subida de la aplicación y lista de permisos a monitorizar al Servidor, descarga de la aplicación modificada,

(3)

Smart Device Server

SINK

partial trace Traces of APP’ Application to hook Hooked application APP Permissions Monitored Android application 1 Embedded client Monitored Android application 2 Embedded client Non Monitored Android application N partial trace Disassembled files Function 1 Function2 Function n List of functions to hook Hooking Process Modified files DrawGraph (Java Program) Databases APP’ Stage I Stage II Stage IV Stage V

Web Service

Database Stage III: Running APP’

Figura 1: Componentes del Sistema de Monitorizaci´on del comportamiento de la Aplicaci´on.

e instalación de la misma. Finalmente, un botón permite iniciar o detener la monitorización de la aplicación en el cualquier instante.

Por otra parte, el Sink permite realizar la gestión de las trazas, ejecutando servicios en segundo plano. Este gestor es el encargado de colectar las trazas enviadas desde los clientes embebidos individuales, ubicados en cada una de las aplicaciones supervisadas, añadiéndoles una marca de tiempo y el hash del ID del dispositivo, y su almacenamiento en una memoria intermedia circular común. Por último, las trazas se env´ıan periódicamente al servicio web donde se almacenan en una base de datos.

III-2. El Cliente Embebido: consiste en un módulo de comunicación que utiliza el protocolo UDP para la transmisión de las trazas de las funciones modificadas invocadas en APP’, al Sink.

III-3. El Servicio Web: provee los siguientes servicios al Sink: subir aplicaciones, descargar las aplicaciones modifi-cadas y enviar las trazas. Ahora la pieza clave de todo el sistema y donde reside la lógica del método presentado, es la herramienta que instrumenta la aplicación, el proceso conocido como ”hooking”. Este componente mapea los permisos de la aplicación en llamadas a funciones que son marcadas, las cuáles van ser monitorizadas. Por lo tanto, este proceso es una acción automática realizada por el servidor Web cada vez que una aplicación es enviada al mismo.

Las funciones modificadas registrarán el nombre de la aplicación, el nombre de paquete de la aplicación, y el hash de la aplicación y enviará esta información al cliente embebido

junto con el nombre de la funci´on (e.g., sendTextMessage(), getDeviceID(), execSQL(), SendBroadcast(), etc.). A continua-ci´on, todos los ficheros modificados junto con el resto de los recursos desensamblados se reensamblan y se empaquetan en un fichero binario Android .apk. Al terminar la Etapa II, la APP’ es descargada al Sink.

III-4. Visualizaciones: Con el fin de realizar un análisis vi-sual del comportamiento de las aplicaciones se utiliza una base de datos NoSQL basada en grafos, Neo4j1_{. Neo4j almacena los} datos en una estructura orientada a grafos, en lugar de utilizar las tablas relacionales de las bases de datos convencionales. En términos generales, un grafo es una representación de un conjunto de nodos y las relaciones entre ellos unidos por medio de enlaces, (vértices y aristas o arcos, respectivamente). Esto se ilustra en la Etapa V de la Figura 1. De esta manera, se puede plasmar cada uno de los comportamientos de la aplicación analizada con una representación simple pero muy ilustrativa. Los grafos se elaboran mediante relaciones de tipo ”una Aplicación incluye varias Clases que a su vez llaman a Funciones”. El primer nodo superior, ”Aplicación”, contiene el nombre del paquete de la aplicación, que es única para cada una de las aplicaciones existentes, mientras que el segundo nodo, ”Clase”, representa el nombre del componente de Android que ha llamado a la ”API call”, el nodo ”Función”. Una vez se obtiene la información recogida por el servicio Web en la base de datos, toda su estructura de llamadas a fun-ciones puede ser filtrada y tratada. Inicialmente se genera un grafo sin incluir colores empleando el lenguaje Cypher Query

(4)

(a) (b) (c) (d)

Figura 2: Interfaz de Usuario del Sink. (a) Selección de la aplicación, (b) Pasos de la aplicación, (c) Selección de los permisos, y (d) Proceso de monitorización.

Languaje, que permite operar y aplicar transformaciones en el grafo.

Para ello, un experto debe completar y encadenar un conjunto de reglas que ayudan a resaltar el comportamiento malicioso conocido (por ejemplo, la llamada a la función SendMessageText(). Para ello, se buscan los nodos en la parte inferior del grafo relacionado con las llamadas a funciones API consideradas maliciosas. Las reglas incluyen la búsqueda y representación de funciones maliciosas (representadas en rojo), sospechosas o maliciosas pero no cr´ıticas (en naranja) y benignas (en verde). Cuando se detecta un comportamiento malicioso como el env´ıo de mensajes SMS a un número de pago premium sin el consentimiento del usuario, se procede a representar el nodo bajo inspección en color rojo como señal de alerta usando Cypher.

IV. RESULTADOS

En esta sección se muestran los resultados de utilizar la plataforma de monitorización y visualización para algunos ejemplos. En este art´ıculo, exploramos 3 diferentes apps con el fin de evaluar todo el marco de trabajo:

Skype-free IM & video calls La aplicaci´on popular Angry Birds El malware Fake player

IV-A. Las Trazas

Despu´es de ejecutar las aplicaciones arriba mencionadas durante 2-3 de minutos cubriendo todas las funcionalidad de la aplicaci´on, el servidor Web recolecta un gran volumen de trazas de cada una de las mismas.

IV-B. An´alisis Visual de las Trazas

Como se ha dicho anteriormente, un conjunto de reglas predefinidas por expertos nos permite identificar las funciones

API ”sospechosas”, y en función de sus parámetros, se asignan colores a éstas. Al hacerlo, nos permite identificar rápidamente las funciones y asociarla con elementos relacionados. Al aplicar la clasificación de funciones en base a un color para cada nodo del grafo, esto permite la construcción de un ”mapa visual”que describe y ayuda al análisis de su funcionamiento. Además, este grafo es adecuado para guiar el analista durante el examen de clasificación de una muestra de malware peli-grosa debido a que el sombreado rojo de los nodos indican estructuras maliciosos identificados por la infraestructura de monitorización. Esta revisión debe realizarse entre todos los nodos de las funciones llamadas en el nivel más bajos de cada rama del árbol del grafo. Sin embargo, con el fin de colorear completamente el grafo de la aplicación hasta llegar al nodo ra´ız, hay que recurrir a realizar un análisis de abajo hacia arriba (”bottom-top”) del vecindario de cada función invocada y las asociadas. Por lo tanto, si una de las ramas del grafo es coloreada en rojo, a continuación, la app se considera como potencialmente maliciosa.

En particular, los grafos de las aplicaciones como Skype, Angry Birds, y Fake Player se muestran en la Fig. 3 lo cual proporciona al usuario una indicación del estado de seguridad de éllos. Para ello, se han creado reglas Cypher para colorear aquellos nodos que contienen una llamada a función de env´ıo de SMS en rojo, y llamadas a funciones para obtener y mostrar publicidad (Adware) en naranja.

Como resultado, el grafo generado para la aplicaci´on Skype no muestra ninguna amenaza y sus nodos aparecen coloreados en verde, tal y como se muestra en la Fig.3(a).

Por otra parte, en la Fig. 3(b) existe una aplicación con Adware, por lo que varios nodos de esta aplicación están coloreados en naranja, mientras en contraste las funciones maliciosas que identifican un malware se colorean en rojo,

(5)

como se muestra en la Figura 3(c) para la aplicaci´on Fake Player.

V. CONCLUSIONES

En este trabajo se propone una arquitectura de supervisión con el objetivo de monitorizar aplicaciones Android a gran escala, sin modificar el firmware del mismo, sin la necesidad de obtener permisos de administrador del dispositivo, y que resulta en un grafo de visualización donde se destacan las llamadas a función correspondientes a los comportamientos de malware predefinido. La plataforma está compuesta por cuatro componentes: el cliente embebido, el Sink, el servicio web y la visualización. Antes de que una aplicacón sea supervisada, el Sink la transfiere al Servicio Web, que se encarga de la inserción de los hooks añadiendo el cliente embebido en el interior la aplicación. Finalmente el Sink descargará la apli-cación recién instrumentada. Cuando una función modificada es llamada, se construye una traza parcial que será pasada al cliente embebido que a su vez la enviará al Sink. Este recoge los trazas parciales de todas las aplicaciones supervisadas, las completa, y las sube mediante el servicio Web. El Servidor finalmente transforma las trazas y las almacena en una base de datos de grafos.

Por último, se aplican un conjunto de reglas predefinidas con el fin de obtener una visualización donde se pone de relieve o resalta la conducta maliciosa de la aplicación super-visada. La infraestructura desarrollada es capaz de monitorizar simultáneamente varias aplicaciones en distintos dispositivos y la recopilación de todos las trazas se da en un mismo lugar. Las pruebas realizadas en este trabajo muestran que las aplicaciones pueden ser preparadas para ser supervisadas en cuestión de minutos y las aplicaciones modificadas se comportan como estaban originalmente diseñadas. Además, se ha mostrado que la infraestructura se puede utilizar para de-tectar comportamientos maliciosos en aplicaciones, tales como el monitorizado del malware Fake Player. Las evaluaciones del Sink han revelado que nuestro sistema de supervisión es reactivo, no pierde ninguna de las trazas parciales, y tiene un impacto muy pequeño en el rendimiento de las aplicaciones supervisadas.

VI. TRABAJOS FUTUROS

Como trabajo futuro, la plataforma se puede ampliar para ser capaz de supervisar las funciones Android conocidas como Intents, enviadas por la aplicación que permitir´ıan a una aplicación llamar a funciones que no requieren ningún tipo de permiso espec´ıfico (como por ejemplo que una función llame a un navegador sin que la aplicación tenga permisos de Internet). No ser capaz de monitorear Intents significa que la infraestructura no es capaz de realizar un seguimiento, de si la aplicación supervisada inicia otra aplicación durante un corto per´ıodo de tiempo para realizar una tarea determinada, e.g., para abrir un navegador web para mostrar la EULA (end-user license agreement). Además, esto permitir´ıa saber cómo la aplicación bajo prueba se comunica con el resto de las

aplicaciones de terceras partes y las aplicaciones instaladas en el dispositivo.

Asimismo se puede ampliar el modelo anti-malware descrito en este trabajo, desarrollando una arquitectura que lo comple-mente mediante la detección automática de malware móvil como por ejemplo con el uso de VirusTotal, realizando as´ı un paso de filtrado previo. En definitiva, se podr´ıa obtener un sistema mas versátil disponiendo en el móvil de una aplicación que reporte anomal´ıas (i.e., desviación del patrón de tráfico de las aplicaciones de red) a un servidor anti-malware en su red.

REFERENCIAS

[1] Businessinsider, “businessinsider.” Available Online, 2014.

[2] Sophos, “Sophos mobilebile security threat report.” Available On-line, 2014. http://www.sophos.com/en-us/medialibrary/PDFs/other/

sophos-mobile-security-threat-report.ashx.

[3] M. Karami, M. Elsabagh, P. Najafiborazjani, and A. Stavrou, “Behavioral analysis of android applications using automated instrumentation,” in Software Security and Reliability-Companion (SERE-C), 2013 IEEE 7th International Conference on, pp. 182–187, June 2013.

[4] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R. Sadeghi, “Xmandroid: A new android evolution to mitigate privilege escalation attacks,” Technical Report TR-2011-04, Technische Universit¨at Darms-tadt, Apr. 2011.

[5] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy, J. S. Foster, and T. Millstein, “Dr. android and mr. hide: Fine-grained permissions in android applications,” in Proceedings of the Second ACM Workshop on Security and Privacy in Smartphones and Mobile Devices, SPSM ’12, (New York, NY, USA), pp. 3–14, ACM, 2012.

[6] K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie, “Pscout: Analyzing the android permission specification,” in Proceedings of the 2012 ACM Conference on Computer and Communications Security, CCS ’12, (New York, NY, USA), pp. 217–228, ACM, 2012.

[7] G. Suarez-Tangil, J. E. Tapiador, P. Peris-Lopez, and J. Blasco, “Den-droid: A text mining approach to analyzing and classifying code structu-res in android malware families,” Expert Syst. Appl., vol. 41, pp. 1104– 1117, Mar. 2014.

[8] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, “Crowdroid: Behavior-based malware detection system for android,” in Proceedings of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices, SPSM ’11, (New York, NY, USA), pp. 15–26, ACM, 2011. [9] X. Jiang and Y. Zhou, Android Malware. Springer New York, 2013. [10] M. La Polla, F. Martinelli, and D. Sgandurra, “A survey on security

for mobile devices,” Communications Surveys Tutorials, IEEE, vol. 15, pp. 446–471, First 2013.

[11] G. Suarez-Tangil, J. Tapiador, P. Peris-Lopez, and A. Ribagorda, “Evo-lution, detection and analysis of malware for smart devices,” Communi-cations Surveys Tutorials, IEEE, vol. PP, no. 99, pp. 1–27, 2013. [12] H. Gascon, F. Yamaguchi, D. Arp, and K. Rieck, “Structural detection

of android malware using embedded call graphs,” in Proceedings of the 2013 ACM workshop on Artificial intelligence and security, pp. 45–54, ACM, 2013.

(6)

(a) Grafo de Skype.

(b) Grafo del juego Angry Birds.

(c) Grafo del malware Fake Player.

Figura 3: Grafos de las aplicaciones bajo prueba. (a) Diagrama Superior: Grafo de Skype, (b) Diagrama Intermedio: Grafo de la aplicaci´on Angry Birds, y (c) Diagrama Inferior: Grafo del malware Fake Player.