Meaningful Permission Management in Android

Transcripción

1 Meaningful Permission Management in Android L. V. Morales and S. J. Rueda Abstract Android is one of the most targeted mobile platforms, one reason is that it has a big part of the smartphone market. One of the features widely attacked by malware is the Android mechanism to grant permissions to applications. Applications announce their lists of required permissions in their installation packages, and users decide whether to grant those permissions or not. However, most users do not understand the meaning of such permissions. This work proposes the use of categories to help users make a decision; a category represents an application s purpose. It is easy for users to map an application to a category because category names are meaningful. Once a user establishes a mapping application-category, it is possible to automatically evaluate if the permissions an application requests are valid. Keywords Smartphone Security, Permission Management, Access Control. A I. INTRODUCCIÓN UNQUE el objetivo inicial de la telefonía móvil era facilitar la comunicación telefónica, este objetivo se ha diversificado y hoy día es posible enviar mensajes de texto, tener acceso en línea a aplicaciones multimedia y a gran variedad de aplicaciones en internet. El mercado de los teléfonos celulares inteligentes ha crecido de forma consistente en los últimos años y cuenta con varios sistemas operativos móviles, como ios, BlackBerry, Windows Phone, y Android. Este último con el mayor porcentaje del mercado: 72%. [1] Android es un sistema operativo abierto creado por Google y basado en Linux. Google y Android decidieron usar un mecanismo libre para distribución e instalación de aplicaciones: la tienda de aplicaciones en línea, Google Play Store. Si un desarrollador desea publicar una aplicación, solo debe crearla en el formato especificado, pagar una módica suma y subir su programa. En unas cuantas horas la aplicación estará disponible en la tienda. El uso de un mecanismo autoregulado tiene ventajas, como la gran cantidad de aplicaciones disponibles, más de un millón hacia julio de 2013, y la oferta de aplicaciones gratuitas. Por otro lado, un esquema autoregulado también permite a terceros la publicación de aplicaciones maliciosas. Esto, más el gran número de ususarios, convierte a Android en una plataforma muy atacada. En 2012, de 108 amenazas únicas dirigidas a dispositivos móviles, 103 tenían a Android como objetivo [2]. Además, los troyanos son frecuentes, ejecutando acciones con costo monetario para los usuarios [3]. Uno de los objetivos más atacados en la platforma es el mecanismo para otorgar permisos a las aplicaciones, pues esta L. V. Morales, Universidad de Los Andes, Bogotá, Colombia, l.morales825@uniandes.edu.co S. J. Rueda, Universidad de Los Andes, Bogotá, Colombia, sarueda@uniandes.edu.co decisión es delegada a los usuarios, quienes usualmente no cuentan con información para determinar si una aplicación es peligrosa o no. Cuando un usuario empieza el procedimiento para instalación de una aplicación nueva, el programa instalador de Android despliega en la pantalla del dispositivo la lista de permisos que la aplicación requiere para su ejecución y espera el visto bueno del usuario para que el procedimiento continúe. Pero es común que un usuario no lea la lista o no entienda el significado de los permisos que allí aparecen y de todas formas los conceda. Este trabajo propone el diseño y construcción de un mecanismo que guíe al usuario de forma más apropiada: un instalador modificado. Es decir, el instalador de Android con recursos adicionales para dar más información al usuario y presentar una alerta clara ante la posibilidad de instalar malware. Para ello se definen categorías de aplicaciones y perfiles de permisos por cada una. Una categoría representa la tarea principal de una aplicación y un perfil es un conjunto de permisos consistente con las tareas de las aplicaciones en una categoría; hay permisos consistentes con la tarea principal de una aplicación y otros no. Por ejemplo, una aplicación de manejo de fondos (o wallpapers), no necesita permisos para registro de llamadas telefónicas. Para determinar si los permisos requeridos por una aplicación son justificables se pide al usuario que establezca la categoría de dicha aplicación y se verifica si los permisos requeridos aparecen en el perfil previamente definido para la categoría. Los perfiles permiten la clasificación de una aplicación como potencialmente maliciosa o no, y se informa al usuario el resultado. El instalador modificado presenta al usuario una advertencia, con la lista de permisos por los cuales la aplicación es considerada malware. Si la aplicación es considerada benigna, entonces el instalador no muestra ninguna advertencia y no afecta el proceso de instalación. El resto de este artículo está organizado de la siguiente forma: la sección II describe el sistema operativo y su arquitectura de seguridad. La sección III presenta los problemas de seguridad abordados en este documento. La sección IV presenta el diseño e implementación de la propuesta. La sección V describe y analiza los resultados. La sección VI establece una comparación con trabajos anteriores. La sección VII concluye el trabajo. II. ANDROID Esta sección presenta información general sobre el sistema operativo, la arquitectura general de las aplicaciones y la arquitectura de seguridad de Android. A. Sistema Operativo Google adquiere la primera empresa en trabajar en una plataforma para teléfonos móviles abierta, en 2005, continúa

2 con el desarrollo, y se une a otras compañías para crear la Open Handset Alliance (OHA) en 2007 [4,5]. Google ha publicado varias versiones del sistema, con mejoras en diferentes aspectos, como gráficos, interacción con el usuario y compatibilidad. Todas las versiones comparten la misma arquitectura de cinco capas. La primera corresponde al kernel de Linux. La segunda capa contiene las librerías nativas escritas en C o en C++ que son utilizadas en otros componentes, entre estas se encuentran las funciones para manejo de elementos multimedia, gráficos, seguridad en la red y exploradores. La tercera capa es el Runtime de Android, que contiene librerías del núcleo de Java y la máquina virtual (MV) Dalvik. Dalvik fue especialmente diseñada para escenarios con recursos restringidos, como memoria o capacidad de procesamiento, tal como un teléfono móvil. Además, el código que Dalvik corre es más compacto que el código para la máquina virtual de java (JVM). La cuarta capa es el framework de las aplicaciones, ofrece APIs para uso de las librerías nativas y para conexión con la MV. En la última capa están las aplicaciones del teléfono [6]. B. Aplicaciones Las aplicaciones para Android se desarrollan en Java o en código nativo y pueden hacer uso de las interfaces que ofrece el framework. Estas se deben empaquetar en el formato definido,.apk, para su instalación. Cada aplicación se compone de: Actividades. Una actividad es cada pantalla de la aplicación que se muestra en el teléfono. Las aplicaciones pueden tener más de una actividad y la terminación de una puede llevar a la iniciación de otra. Servicios. Son componentes para ejecutar acciones en segundo plano, background, sin la interacción del usuario, por un tiempo prolongado. Broadcast Receiver. Le permite a las aplicaciones recibir mensajes enviados por otros procesos. Además, las aplicaciones documentan su configuración en un archivo XML, llamado Android Manifest. Este guarda metadatos sobre una aplicación, como nombre, componentes, la versión mínima del API requerida para ejecución, y las librerías y permisos que necesita. Una aplicación también puede especificar actividades o servicios propios que no pueden ser accedidos por otros procesos. Una aplicación recibe permisos de acceso a los recursos en el momento de su instalación y los conserva durante su ciclo de vida. C. Seguridad en Android El control de acceso a recursos en Android se basa en el mecanismo de Linux. Este asigna identificadores a los sujetos y objetos del sistema y permite la definición de una política de acceso con base en dichos identificadores. Existe un identificador de usuario especial (root) con acceso a todos los recursos de la máquina, incluidos los recursos protegidos y comandos privilegiados. Android ofrece funciones de seguridad que contribuyen a la seguridad del dispositivo, organizadas en las cinco capas de su arquitectura. En la primera capa, el kernel de Linux ofrece a Android su modelo de permisos para control de acceso, aislamiento de procesos y control multiusuario. Android maneja cada aplicación como un usuario independiente, asignando a cada una un identificador diferente. Así mismo, cada aplicación corre como un proceso separado con acceso a recursos diferentes. Solamente el kernel y algunas aplicaciones del núcleo tienen permisos de root, lo cual les da acceso a todos los recursos del sistema. La segunda capa no ofrece características a nivel de seguridad. En la tercera capa existe el concepto de cigoto, un proceso que se crea cuando el sistema operativo se inicia. Este se encarga de crear la primera instancia de la máquina virtual Dalvik y la carga con varias librerías de núcleo que luego serán utilizadas por las aplicaciones. El cigoto también se encarga de crear nuevas instancias de la máquina virtual y nuevos procesos (con id de usuario único) para cada aplicación que se desea ejecutar. Estos procesos solamente tienen permisos de lectura sobre las librerías de núcleo. Si se necesita editar alguna de ellas, se crea una copia de la librería en el proceso, para no afectar el funcionamiento de otras aplicaciones [7]. En las dos últimas capas, el framework regula la interacción entre aplicaciones y cada aplicación especifica los mensajes que puede recibir y procesar para otras aplicaciones. Por otro lado, Android maneja un conjunto de permisos previamente definidos y los asocia con los recursos protegidos del dispositivo. Entre estos permisos se encuentran, acceso a la ubicación, información sobre la conexión de red, correo de voz, información sobre la batería, bluetooth, y mensajes de texto [8]. Los permisos Android se clasifican en clases que indican el peligro que cada uno significa para los datos del usuario. Las clases definidas son [8]: Normal. Permisos que no afectan otras aplicaciones, el sistema o el usuario. El sistema otorga estos permisos automáticamente, sin pedir autorización al usuario. Peligrosos. Permisos que dan acceso a información del usuario o controlan aspectos del hardware que pueden afectar al usuario. Necesitan autorización del usuario para ser otorgados. Firma. Permisos que el sistema otorga si la aplicación que pide el permiso está firmada con el mismo certificado que la aplicación que definió el permiso (Android permite a las aplicaciones definir permisos propios). Firma o Sistema. Se dan estos permisos a aquellas aplicaciones que se encuentran en la imagen del sistema o que cumplen las condiciones del caso anterior. D. Instalación de Aplicaciones Nuevas Un usuario puede instalar aplicaciones por dos vías: el Play Store, la tienda oficial de Android, o el Package Installer (o instalador de Android), programa que corre en el teléfono y que instala las aplicaciones descargadas. Si una aplicación pide permisos considerados peligrosos, tanto el Play Store como el Package Installer despliegan la lista de permisos al usuario y le

3 preguntan si está de acuerdo con otorgar tales permisos. Para continuar, el usuario debe otorgar todos los permisos en la lista, no es posible aceptar solo algunos de ellos. III. DESCRIPCIÓN DEL PROBLEMA Android implementa los mecanismos de protección descritos en la sección II, sin embargo, esta plataforma es una de las más atacadas por malware % del malware tiene como objetivo dispositivos Android [9]. En 2012, a pesar de no ser la plataforma más vulnerable fue la más atacada, siendo el objetivo de 103 amenazas reconocidas, de un total de 108 amenazas únicas dirigidas a dispositivos móviles [2]. Como se mencionó en la sección I, uno de los problemas para la seguridad de la plataforma es que delega al usuario la asignación de permisos a las aplicaciones al momento de instalarlas. Las aplicaciones peligrosas aprovechan este esquema para declarar permisos excesivos en el archivo manifest, con una probabilidad alta de ser asignados por los usuarios, ya sea porque estos no se percatan de los riesgos que implican o porque no entienden lo que los permisos significan. Después de obtener sus permisos, una aplicación puede ejecutar cualquier tipo de acción sobre los recursos controlados por esos permisos, incluyendo acciones maliciosas, como el envío de mensajes de texto a servicios que cobran y el acceso a internet usando plan de datos en vez de wifi, generando costos para el usuario. Una aplicación también podría acceder a información personal, como la lista de contactos o las cuentas que el usuario tiene en su dispositivo, y enviar dicha información a terceros. El problema es mayor porque el instalador de Android solamente despliega una pequeña advertencia sobre el uso de aplicaciones que pueden costarle dinero al usuario. La Fig. 1 muestra la pantalla que el instalador despliega, con los permisos que una aplicación declara en su manifest. La aplicación en el ejemplo es un juego de tipo Arcade and Action. Aunque el instalador muestra la lista de permisos pedidos por la aplicación, no presenta una alerta que indique al usuario los privilegios y las consecuencias de conceder tales permisos. Otro aspecto a tener en cuenta es que los permisos se presentan de forma individual, lo que hace que un usuario no identifique permisos que, de ser otorgados al mismo tiempo, pueden ser peligrosos. Figura 1. Pantalla que el instalador original despliega mostrando los permisos que una aplicación declara en su manifest. Una categoría está asociada con la tarea principal de una aplicación y dicha tarea implica un perfil de permisos. La Fig. 2 ilustra la relación entre aplicaciones, categorías y perfiles. Si una aplicación en una categoría C declara permisos en su manifest que son considerados peligrosos y no aparecen en el perfil de permisos para dicha categoría, entonces la aplicación se considera potencialmente peligrosa. IV. SOLUCIÓN PROPUESTA Para guiar a un usuario en la decisión de otorgar permisos o negarlos se propone desarrollar una herramienta que ofrezca información con mayor significado sobre los permisos asociados con una aplicación. Para cumplir con este objetivo se decidió clasificar una aplicación en potencialmente peligrosa o no, con base en sus permisos, y desplegar el resultado de la clasificación al usuario. A. Diseño Para desarrollar la herramienta se definió el concepto de categorías de aplicaciones y perfiles de permisos por categoría. Figura 2. Relación entre aplicaciones, categorías y permisos. Cada aplicación pertenece a una categoría y para cada categoría se crea un perfil de permisos consistente con las tareas adelantadas por las aplicaciones de esa categoría. 1) Categorías: Las categorías definidas corresponden a las categorías que se encuentran en la tienda oficial de Android. Para facilitar las búsquedas a los usuarios, la tienda organiza las aplicaciones en cuatro grupos: las más populares,

4 seleccionadas, para tabletas y por categorías. Aunque no todas las aplicaciones aparecen como las más populares o en la selección de la tienda, todas tienen asignada una categoría. A la fecha, la tienda tiene treinta y cuatro categorías, distribuidas en dos grupos principales: Juegos y Aplicaciones. Juegos agrupa categorías como Arcade & Action y Live Wallpaper. Aplicaciones agrupa categorías como Books & Reference, Comics, Education, Photography y Weather. 2) Perfiles: El perfil de permisos de una categoría representa el conjunto de permisos relacionados con la función principal de dicha categoría. Para definir este perfil usamos los permisos declarados en los archivos manifest sobre la muestra de aplicaciones más descargadas de la tienda oficial de Google Google Play y recopiladas por el Laboratorio de Seguridad de Sistemas e Infraestructura de PennState en 2011 y 2013 [10]. La tabla I describe la muestra que se usó para generar los perfiles. La muestra corresponde a las aplicaciones más descargadas en la tienda oficial, agrupadas por categoría. Los archivos manifest se obtienen de los archivos apk de cada aplicación, de los archivos manifest se extraen los permisos declarados, y se consolida el número de veces que un permiso aparece, sobre las aplicaciones de una categoría. Los permisos declarados por la mayoría de las aplicaciones en una categoría se consideran necesarios por dichas aplicaciones para cumplir con sus requerimientos. TABLA I. MUESTRA USADA PARA CONSTRUIR LOS PERFILES. PRESENTA EL NÚMERO DE APLICACIONES POR CATEGORÍA. Categoría No. Categoría No. Arcade & Action 75 Medical 51 Books & Reference 26 Music & Audio 52 Brain & Puzzle 72 News & Magazine 52 Business 26 Photography 51 Casual 74 Productivity 26 Comics 26 Racing 50 Communication 26 Shopping 65 Education 54 Social 69 Entertainment 26 Sports 68 Finance 26 Sports (Games) 54 Health & Fitness 26 Tools 66 Libraries & Demo 26 Transportation 49 Lifestyle 26 Travel & Local 66 Live Wallpaper 53 Weather 49 Live Wallpaper (Games) 26 Widgets 25 Media & Video 55 Widgets (Games) 26 Para construir los perfiles se empezó con un perfil generado de forma automática a partir de los permisos declarados por la mayoría de las aplicaciones en una categoría: si un permiso aparece en el manifest de 55% o más de las aplicaciones de una categoría en la muestra, este es incluido en el perfil. Después de generar los perfiles, se hizo una revisión manual porque los desarrolladores tienden a declarar permisos en exceso para sus aplicaciones (prefieren que sobren permisos y no que falten, pues eso afectaría los requerimientos funcionales de una aplicación). La revisión manual de los perfiles es una tarea que se realiza una sola vez por un grupo de expertos. Después de definidos, los perfiles pueden ser usados en múltiples dispositivos, las veces que sea necesario. Los perfiles deberían ser evaluados periódicamente, para responder a la evolución de las categorías y la plataforma. Otro aspecto que se consideró para la construcción de los perfiles es la lista de permisos peligrosos definida por Android y que incluye los permisos que dan acceso a la información personal del usuario, a un servicio o aplicación que puede significar un costo monetario para el usuario, o que emplean servicios de interfaces API protegidas, como la cámara o el GPS. La lista de permisos peligrosos, usada por el instalador modificado, se basa en la idea de Android, pero le da prioridad a aquellos permisos que dan acceso a la información personal del usuario o generan costos adicionales. Los primeros porque pueden guardar información sobre empresas, transacciones, cuentas bancarias y números telefónicos, entre otros. Los segundos porque pueden generar costos monetarios altos. No se incluyen aquellos permisos que tienen acceso a las interfaces API protegidas como la cámara o el GPS porque el uso de estos recursos requiere permiso explícito del usuario. Esto no pasa con otros recursos como el teléfono, el manejador de mensajes de texto, o la lista de contactos. 3) Clasificación: Para clasificar una aplicación como peligrosa se comparan los permisos que la aplicación declara en su manifest contra los permisos definidos en el perfil de su categoría y la lista de permisos peligrosos. Los criterios para la clasificación son: Si la aplicación requiere permisos peligrosos y dichos permisos no están en el perfil de permisos para su categoría entonces la aplicación es considerada peligrosa. Si la aplicación no requiere permisos peligrosos o si todos los permisos peligrosos que requiere aparecen en el perfil de permisos de su categoría entonces la aplicación es considerada benigna. B. Implementación Dado que el objetivo es alertar al usuario del peligro potencial de una aplicación, con base en los permisos que requiere, se tomó la decisión de modificar el instalador de Android, el Package Installer [11]. Para presentar los cambios al código, primero se explica brevemente la composición de aplicaciones Android. Estas aplicaciones tienen, en general, dos paquetes: el primero guarda aquellas clases Java simples que representan los objetos propios de la aplicación y el segundo las clases que manejan la interfaz gráfica, incluyendo manejo de pantallas y los eventos de diferentes elementos como botones o listas, así como la creación e inicialización de nuevas actividades. El programa original se modificó así: (1) El proyecto se modificó, adicionando los archivos que definen los perfiles de permisos por categoría y la lista de permisos peligrosos. (2) Se adicionaron instrucciones para analizar los permisos declarados en el manifest de la aplicación a instalar, con base en los perfiles de permisos clasificarla como maliciosa o no, y desplegar al usuario una ventana de advertencia con el resultado de la clasificación. (3) También se definieron actividades nuevas asociadas con las pantallas para interactuar con el usuario. Una de las

5 actividades permite desplegar los permisos que la aplicación solicita en su manifest. Otra actividad despliega al usuario dos listas para ayudarle con la asignación de categoría, dado que se espera que asigne la categoría correspondiente a una aplicación. La primera lista tiene los grupos principales, Juegos y Aplicaciones, y la segunda tiene las categorías asociadas con cada grupo. Dada la categoría asignada por un usuario, el instalador busca y carga el perfil de permisos correspondiente. El instalador también carga internamente la lista de permisos peligrosos y la lista de permisos declarados en el manifest de la aplicación. Todas las listas son cargadas en arreglos. Finalmente, se clasifica la aplicación de acuerdo con los criterios presentados en la sección anterior y se despliega el resultado en la interfaz gráfica. Para determinar si una aplicación es maliciosa, se construye la lista de permisos peligrosos, pedidos por la aplicación, y que no están en el perfil de la categoría correspondiente, para construir esta lista se recorren las tres listas descritas en el párrafo anterior. Si la aplicación es peligrosa, el instalador despliega un mensaje de advertencia rodeado por un cuadro rojo y presenta información adicional con relación a los permisos. La Fig. 3 ilustra la pantalla correspondiente a una aplicación peligrosa. Figura 3. Vista de la advertencia que el instalador presenta al usuario si la aplicación es clasificada como peligrosa. Más clara que la pantalla original (ver Fig. 1). El usuario puede proceder con la instalación si lo considera necesario. V. EVALUACIÓN El proyecto se desarrolló en la plataforma Linux con sistema operativo Ubuntu LTS de 64 bits. El código de Android se descargó siguiendo las instrucciones especificadas en la página de AOSP [8] y se utilizó Eclipse como ambiente de desarrollo para realizar los cambios al código. Las modificaciones se ejecutaron en un emulador con Android (Jelly Bean), 500MB de memoria RAM, 200MB de memoria interna y una SdCard de 1GB. Para evaluar la respuesta del Package Installer modificado instalamos múltiples programas. Por ejemplo, Adobe Reader, que pertenece a la categoría de Productividad. Esta aplicación pide permisos de acceso a internet y a dispositivos de almacenamiento externo y ninguno de estos permisos se encuentra en la lista de permisos peligrosos. El instalador modificado la clasifica como benigna por lo que no altera el flujo usual de operaciones para el usuario. Además, se seleccionaron aplicaciones de la muestra del proyecto Genoma [12] y se instalaron en el teléfono de pruebas y en el emulador con el instalador modificado. Por ejemplo, se instalaron las aplicaciones: com.ztf y Battery Monitor, que se encuentran en tiendas de origen chino y hoy día son reconocidas por programas antivirus como malware. La aplicación com.ztf guarda estadísticas de uso de recursos, como internet y mensajes, crea íconos de acceso y trata de cambiar la configuración del Punto de Acceso. La aplicación com.ztf guarda estadísticas de uso de recursos, como internet, llamadas y mensajes, crea íconos de acceso en el wallpaper y trata de cambiar la configuración del APN (Nombre de Punto de Acceso). La instalación de la misma aplicación en el celular envía mensajes de texto sin consentimiento del usuario. Figura 4. Vista de la advertencia que el instalador modificado presenta al usuario cuando se trata de instalar una aplicación clasificada como peligrosa, en este caso com.ztf. Battery Monitor descarga e instala un apk, sin consentimiento del usuario, que recoge información del dispositivo y borra mensajes de texto entrantes y salientes. Después de asignar la categoría Tools a la aplicación com.ztf, el instalador modificado la clasificó como maligna y desplegó la ventana de advertencia indicando que la aplicación solicita permisos de acceso a la lista de contactos, llamadas telefónicas y al servicio de recepción y envío de mensajes. La Fig. 4 muestra la pantalla que el instalador modificado despliega al usuario. Battery Monitor también fue clasificada como peligrosa, pide permisos para instalar y eliminar paquetes. La pantalla de advertencia es similar a la presentada en la Fig. 4. La tabla II muestra los resultados al aplicar automáticamente los perfiles construidos a una muestra que incluye 199 aplicaciones benignas y 222 programas malware. La tabla presenta el número de programas clasificados adecuadamente (VP: verdaderos positivos, VN: verdaderos negativos, FP: falsos positivos y FN: falsos negativos). Los programas benignos fueron seleccionados aleatoriamente de la muestra de aplicaciones más descargadas de la tienda oficial Google Play

6 (ver sección IV-A2). Los programas de malware corresponden a la muestra del proyecto Genoma [12]. Esta muestra tiene 1200 programas recopilados durante 14 meses entre 2010 y Los programas fueron descompilados y tras verificar que muchos correspondían a la misma aplicación, con pequeñas variaciones, se revisaron los componentes de cada aplicación. Las aplicaciones del mismo nombre de paquete en el archivo manifest se consideraron como versiones diferentes de la misma aplicación, reduciendo la muestra a 222. Entre las ventajas de la solución propuesta encontramos que el uso de un color llamativo para la advertencia sobre una aplicación potencialmente maliciosa, llama la atención del usuario de forma efectiva. Además, el uso de categorías ofrece un contexto útil para la clasificación de las aplicaciones. Los perfiles de permisos construidos por categoría también podrían ser usados como un criterio adicional en una herramienta para la detección de software malicioso. De igual manera, la tienda oficial podría utilizar los perfiles como otro filtro para evitar la publicación de malware. Una de las limitaciones de esta solución es que la responsabilidad de asignar la categoría recae en el usuario. Sin embargo, dicha selección es simple y no presenta una barrera difícil de superar para el usuario. Una alternativa es incluir la categoría de una aplicación como uno de los datos que el Google Play entregue al package installer. Esta opción libera al usuario de la asignación y solo requiere una pequeña modificación al mecanismo de instalación. También es posible que aparezcan aplicaciones legítimas que no correspondan a un perfil, generando falsos positivos, tal como lo demuestran los resultados de la tabla II. En este caso el usuario estará alerta y cuenta con la posibilidad de continuar si lo considera conveniente. Así mismo, es posible que un programa de malware no corresponda a los permisos definidos por los perfiles, generando falsos negativos. En este caso, el usuario no sería alertado del peligro. Los resultados muestran que el número de falsos negativos es bajo: 31, sobre una muestra de 222 programas de malware. La fidelidad del método propuesto es de 75% - accuracy = (vp + vn)/tam, vp: verdaderos positivos, vn: verdaderos negativos, tam: tamaño de la muestra. En cuanto al desempeño, el instalador modificado recorre tres listas buscando información para clasificar una aplicación (sección IV-B). La complejidad de la solución es de orden O(n 3 ). A pesar de esto, el incremento en tiempo de ejecución no se percibe porque las listas son cortas. Por otro lado, como la lista de permisos se mantiene en memoria para mejorar los tiempos de respuesta, el consumo de RAM es mayor. Al realizar las pruebas en el emulador se encontró que la aplicación modificada ocupa 6.2 MB de memoria. Es posible reducir el tiempo de búsqueda en las listas usando algoritmos más eficientes y el consumo de memoria usando representaciones más compactas. Estas optimizaciones se plantean como trabajo futuro. En resumen, el mecanismo propuesto es ligero, requiere baja capacidad de cómputo y memoria para la clasificación, y genera una alerta clara para el usuario. TABLA II. RESULTADOS DE LA CLASIFICACIÓN BASADA EN CATEGORÍAS Y PERFILES. Benignas Malware Categoría FP VN Tota VP FN Tot Arcade & Action Books & Reference Brain & Puzzle Business Cards & Casino Casual Comics Communication Education Entertainment Finance Health & Fitness Libraries & Demo Lifestyle LiveWallpaper LiveWallpaper(Games) Media & Video Medical Music & Audio News & Magazine Personalization Photography Productivity Racing Shopping Social Sports Sports Tools Transportation Travel & Local Weather Widgets Widgets (Games) Totales VI. TRABAJOS RELACIONADOS Investigaciones anteriores abordan el problema de asignación de permisos a aplicaciones en Android. Kirin [13] clasifica una aplicación como peligrosa o no con base en un conjunto preestablecido de reglas que indican las combinaciones de permisos que son peligrosas. Por ejemplo, una regla establece que la combinación PHONE-STATE, RECORD-AUDIO, INTERNET permite a una aplicación grabar conversaciones telefónicas y enviarlas por internet, como consecuencia si una aplicación pide estos permisos, es considerada peligrosa. Este trabajo extiende la propuesta de Kirin al considerar el propósito de una aplicación para refinar la clasificación y que esta sea más precisa. Barrera et al. [14] estudiaron la relación entre el contexto de una aplicación y los permisos asignados. Los investigadores usaron el algoritmo de redes neuronales, SOM (Self-Organizing Map), para determinar los permisos únicos por categoría. Encontraron que no hay conjuntos de permisos que caractericen las categorías de forma única. Aunque la propuesta presentada aquí caracteriza una categoría por medio de un perfil, no busca hacerlo de forma única. Un perfil puede incluir permisos comunes siempre y cuando soporten las actividades apropiadas

7 de la categoría estudiada. ASESD, Android Security Enforcement with a Security Distance Model [15], asigna valores de peligrosidad a cada uno de los permisos de Android, y calcula el nivel de peligrosidad de una aplicación con base en los valores asignados a los permisos que la aplicación requiere en su manifest. La clasificación basada en categorías es más flexible pues considera permisos que a pesar de ser peligrosos son consistentes con la función de una aplicación, en cuyo caso existe una razón legítima para ser usados. Otros investigadores han estudiado la asignación de permisos en contextos diferentes, como navegadores [16], sistemas operativos [17] y servicios convergentes [18]. En todos los casos se busca soportar el principio de privilegios mínimos [19]. Nuestros perfiles pueden ayudar, en el caso de Android, al ofrecer a los desarrolladores un mecanismo para la generación de permisos mínimos de acuerdo con el propósito de una aplicación. VII. CONCLUSIONES Aunque Android incluye mecanismos de protección, heredados de proyectos basados en software libre y de Linux, es un objetivo muy atacado por los creadores de malware, siendo el sistema operativo móvil para el cual hay un mayor número de programas de malware. Los desarrolladores de malware aprovechan el mecanismo de asignación de permisos en esta plataforma para obtener permisos sobre recursos para los que no deberían tener acceso. En el esquema de asignación de permisos de Android, una aplicación puede pedir permisos que no son necesarios para su función y la responsabilidad de otorgar dichos permisos recae sobre el usuario durante la instalación. El instalador de aplicaciones de Android presenta al usuario los permisos que una aplicación solicita y espera su aprobación. Sin embargo, es común que el usuario no entienda el significado real, ni las consecuencias de la aprobación de ciertos permisos. Este trabajo propone el uso de un instalador modificado para orientar al usuario de forma más adecuada. El instalador modificado cuenta con un mecanismo basado en perfiles de permisos para clasificar una aplicación como malware o no, y una advertencia gráfica clara, para alertar a un usuario sobre aplicaciones que piden permisos peligrosos. Este instalador se convierte en un recurso que ofrece a un usuario ayuda adicional para tomar una decisión informada al permitir la instalación de una aplicación. Además, los perfiles construidos pueden ayudar a los desarrolladores de aplicaciones Android en la tarea de definición de los permisos mínimos para una aplicación. Este tema se deja como trabajo futuro. REFERENCIAS [1] Gartner Group. Gartner newsroom: Smartphone sales increased. [Online]. Available: [2] Symantec, Internet security threat report, Symantec, Tech. Rep., [3] Android devices in U.S. face more malware attacks than PCs. [Online]. Available: [4] J. Markoff, I, robot: The man behind the google phone, New YorkTimes, [5] L. Darcey and S. Conder, Android Wireless Application Development Volumne I: Android Essentials. Addison-Wesley, [6] Dalvik VM Internals on 2008 Google I/O Session, [7] D. Ehringer. The dalvik virtual machine architecture. [8] Android Open Source Project, Android Developers. [Online]. Available: [9] D. Maslennikov and Y. Namestnikov. Kaspersky: Boletín de seguridad estadística general de [Online]. Available: [10] Systems and Internet Infrastructure Security Lab at PennState University, Smartphone application analysis. [Online]. Available: [11] Android Open Source Project, Android Source. [Online]. Available: [12] Android Malware Genome Project at North Carolina State University. Dataset release. [Online]. Available: [13] W. Enck, M. Ongtang, and P. McDaniel, On lightweight mobile phone application certification, in Computer and Communications Security (CCS), [14] D. Barrera, H. G. Kayacik, P. van Oorschot, and A. Somayaji, A methodology for empirical analysis of permission-base security models and its application to android, in Computer and Communications Security (CCS), [15] W. Tang, G. Jin, J. He, and X. Jiang, Extending android security with a security distance modelo, in International Conference on Internet Technology and Applications, [16] C. Reis, A. Barth, and C. Pizano, Browser security: Lessons from google chrome, Communications of the ACM, [17] T. Jaeger, J. Liedtke, and N. Islam, Operating system protection for fine-grained programs, in USENIX Security Symposium, [18] J. C. Yelmo, C. Martínez, J. M. del Álamo and M.A. Monjas, Protection of Personal Information in User-centric Coverged Service Platforms, IEEE Latin America Transactions. Vol. 8, No.2, April [19] J. Saltzer and M. Schroeder, The protection of information in computer systems, Proceedings of the IEEE, vol. 63, no. 9, pp , September Laura Victoria Morales Medina received a Systems and Computing Engineering degree from Universidad de Los Andes, Bogotá, Colombia, in She currently is a Master s student in the Information Security program at the same University. Her research interests include secure application development, security management, and mobile security. Sandra Julieta Rueda Rodríguez received a Systems and Computing Engineering degree from Universidad de Los Andes, Bogotá, Colombia, in 1994, and the Ph.D. in Computer Science and Engineering from The Pennsylvania State University, Pennsylvania, USA, in She is an assistant professor at Los Andes University, Bogotá, Colombia, since Her research interests are security of software systems access control, policy analysis, and policy generation. AGRADECIMIENTOS Agradecemos a los investigadores de los proyectos Análisis de Aplicaciones en Teléfonos Inteligentes del SIIS Lab de Pennsylvania State University [10] y Genoma del Malware de North Carolina State University [12] por darnos acceso a sus repositorios de datos.