Modelo de Seguridad para mitigar los problemas …...navegador de internet Opera. RUFRAUD: malware descubierto en Europa y Rusia, ocultado en fondos de escritorio poplares, u películas

Modelo de Seguridad para mitigar los problemas derivados de las vulnerabilidades en dispositivos móviles Android con respecto a los

principios de Integridad, Confidencialidad y Disponibilidad

Raúl Calero Asencios Pontificia Universidad Javeriana

Facultad de Ingeniería de Sistemas Bogotá, Colombia

Correo-e: [email protected]

Abstract. The focus of this paper is to describe the research made to arise the continuing problem with mobile devices which operate on Android’s platform regarding threads that compromise the integrity, confidentiality and availability of user information. The research proposed a security model based on the platform’s architecture, some security policies and the principles of information security. The security model was designed and proposed to identify the main components interacting when an attack takes place and to recommend some mitigation mechanisms for such attack.

Palabras clave: modelos de seguridad, seguridad, principios de seguridad de la información, arquitectura, plataforma, Android, amenazas, ataques.

1 Introducción La problemática en la cual se basó la investigación realizada trata de las crecientes amenazas a los dispositivos móviles en los últimos años.

La plataforma Android, plataforma bajo la que operan la mayoría de dispositivos móviles a nivel mundial [1] [2], se ha convertido últimamente en el mayor referente de ataques y amenazas a la seguridad de la información. La mayoría de estas amenazas surgen a partir de: malas prácticas de programación por parte de los desarrolladores de aplicaciones (intenciones de beneficio económico por parte de estos), mal uso del dispositivo por parte del usuario, flexibilidad de la plataforma (ya que Android está construido bajo Linux [3] y pertenece a la categoría de código abierto), mecanismos de seguridad deficientes, entre otros.

Este documento describe el trabajo realizado durante la investigación de los ataques a la plataforma Android 4.1 que comprometen los principios de Integridad, Confidencialidad y Disponibilidad de la información. Así mismo, introduce un modelo de seguridad propuesto en dicha investigación para tratar de mitigar las amenazas encontradas a la plataforma.

El documento está dividido en cinco secciones. La segunda sección describe el marco teórico de la investigación, el cual permite introducir el tema en el que se basa la investigación realizada, los conceptos clave, entre otros. La tercera sección, describe los trabajos relacionados al tema de investigación propuesto en el artículo. La cuarta sección, abarca

todo lo relacionado al desarrollo del trabajo que se realizó durante la investigación. La quinta sección describe los resultados obtenidos durante la investigación. La sexta sección comprende las opiniones personales sobre la investigación realizada y la última sección establece las conclusiones a las que se llegó luego de realizar el trabajo y el trabajo futuro.

2 Marco Teórico MODELO DE SEGURIDAD:

Es la expresión formal, matemática de una política de seguridad, se materializa en mecanismos de seguridad. Son los requisitos de un sistema de información o de sus elementos. Existen modelos de seguridad existentes como el Modelo de Bell-Lapadula, Modelo de Biba, Modelo de Clark Wilson y el Modelo de Muralla China [4].

Para que un modelo de seguridad este en los términos de los objetivos del negocio, debe tener en cuenta los riesgos, las políticas de seguridad y los grupos de interés de la organización [5] [6].

MODELO BELL-LAPADULA [7] [8]:

Modelo multinivel propuesto para fortalecer el control de acceso en aplicaciones militares y del gobierno. En estas aplicaciones, generalmente los sujetos son divididos en diferentes niveles de seguridad. Un sujeto puede acceder a objetos hasta ciertos niveles, determinado por su nivel de

2

seguridad, por ejemplo: no cualquiera podría tener acceso a información clasificada como top secret.

El modelo Bell-Lapadula es un modelo enfocado en la confidencialidad y define dos reglas de control de acceso mandatorio (MAC) y una regla de control de acceso discresionado (DAC) con tres propiedades de seguridad:

• La propiedad de seguridad simple: un sujeto en un nivel de seguridad dado no puede leer un objeto de un nivel de seguridad mayor.

• La propiedad estrella: un sujeto en un nivel de seguridad dado no puede escribir en algún objeto de un nivel de seguridad menor.

• La propiedad de seguridad discresionada: el uso de una matriz de acceso para especificar el control de acceso discresionado.

MODELO DE BIBA [9] [10]:

Modelo que describe un conjunto de reglas de control de acceso diseñadas para asegurar la integridad de los datos, los datos y los sujetos son agrupados en niveles ordenados de integridad. El modelo se diseñó para que los sujetos no puedan acceder a objetos en un rango superior al de ellos o a objetos de menor rango.

El modelo de Biba es similar al de Bell-Lapadula, pero este no puede leer hacia abajo ni escribir hacia arriba y además se diferencian en que este se concentra en la integridad de los datos. El modelo se basa en que la preservación de la integridad de los datos tiene tres objetivos:

- Prevenir la modificación de datos por entes no autorizados

- Prevenir la modificación de datos no autorizados por entes autorizados

- Mantener la consistencia interna y externa

MODELO CLARK-WILSON [10]:

Modelo que se preocupa por la integridad de la información, usando políticas de integridad que definen reglas de aseguramiento y reglas de certificación. El principio básico de este modelo, se encuentra bajo la idea de una transacción que es un conjunto de operaciones. Un artículo restringido es considerado una información clave en este modelo, un procedimiento de verificación de integridad, asegura que todos los artículos restringidos son válidos. Los procedimientos de transformación son las transacciones que fuerzan la política de integridad.

MODELO DE MURALLA CHINA [11]:

Modelo de seguridad en donde el acceso a leer y escribir en archivos está dado por pertenencia de los datos en las clases de conflicto de interés y los conjuntos de datos. Es un modelo de seguridad

multilateral y proporciona privacidad e integridad de los datos.

La base del modelo de muralla china es que la gente tiene acceso a información que no genera conflicto con cualquier otra información que ya se posee. En cuanto a lo que un computador concierne, la única información que un usuario posee debe ser:

• La que muestra el computador • A la que el usuario ha accedido previamente

CONTROL DE ACCESO DISCRECIONAL [12]:

Medio para restringir el acceso a los objetos basado en la identidad de: sujetos y/o grupos a los que pertenece. Los controles son discrecionales ya que un sujeto con cierto permiso de acceso, es capaz de pasar ese permiso a cualquier otro sujeto.

Los controles de acceso discrecional son usados para restringir el acceso del usuario a objetos protegidos en un sistema. El usuario también podría estar restringido a un subconjunto de tipos de acceso disponibles para estos objetos protegidos. Los tipos de acceso son las operaciones que un usuario puede ejecutar sobre un objeto en particular (leer, escribir, ejecutar, entre otros).

CONTROL DE ACCESO BASADO EN ROLES [13] [14]:

Los permisos están asociados con roles y los usuarios son asignados a roles apropiados. Esto permite la simplificación de permisos, los roles son creados para diversas funciones de trabajo en una organización y asignados a los usuarios basados en sus responsabilidades y cualidades.

Los roles proporcionan una administración de la seguridad. Existe una diferencia entre los “grupos de usuarios” y los “roles”. Los grupos de usuarios son la unidad de control de acceso usado en la mayoría de sistemas de control de acceso y generalmente son tratados como una colección de usuarios y no de permisos, a diferencia de los roles.

Familias de modelos de referencia de control de acceso basado en roles:

- MODELO BASE: contiene tres conjuntos de entidades llamadas usuarios (U), roles (R) y permisos (P). El usuario es un ser humano y puede ser generalizado para incluir agentes autónomos inteligentes como robots o redes de computadores. Un rol es una función de trabajo dentro de una organización con una semántica asociada a la autoridad y responsabilidad dada al miembro de ese rol. Un permiso es una aprobación de un modo

de acceso en particular a uno o más objetos en un sistema. Los permisos confieren la habilidad de ejecutar ciertas acciones en un sistema. El modelo base debe tratar los permisos como símbolos no interpretados hasta cierto punto, ya que la naturaleza de un permiso es dependiente del sistema y de la implementación.

- JERARQUIAS DE ROLES: son un medio natural para la estructuración de roles para así reflejar las líneas de autoridad y responsabilidad de una organización. La jerarquía de roles involucra la herencia de roles, es decir roles permitidos a usuarios que son un pertenecen a otro tipo de usuario.

ATAQUES A LA PLATAFORMA:

Dentro de las amenazas a la plataforma encontradas, se encuentran las amenazas basadas en aplicación, basadas en web y los adware.

AMENAZAS BASADAS EN APLICACIÓN:

En este caso, los ataques de tipo malware y spyware son los más destacados. El malware en los dispositivos móviles se ha ido incrementando [15]. En este tipo de amenazas, el Toll Fraud Malware (malware diseñado para beneficio del atacante al momento de cobrarle a la víctima el servicio de mensajería PREMIUM y clasificado como FAKEINST) ha sido el que más se ha usado en la plataforma.

Otra característica predominante del malware móvil [16] [17] es la ex filtración de información privada del usuario. La principal razón por la que los desarrolladores crean aplicaciones malware es la remuneración.

Algunos ejemplos comunes de malware para esta clasificación son:

FAKEINST: conocido como instalador falso, es un malware que se hace pasar por aplicaciones populares legitimas tales como WhatsApp Messenger [18] o el navegador de internet Opera.

RUFRAUD: malware descubierto en Europa y Rusia, ocultado en fondos de escritorio populares, películas y aplicaciones de juegos. Este tipo de malware envía mensajes de texto sin el consentimiento del usuario apenas se abre la aplicación [19].

ILEGACY/LEGACY NATIVE: malware de tipo GAMEX, caracterizado por piggybacking [20] en versiones rempaquetadas de aplicaciones que requieren acceso de super usuario. Luego de obtener

privilegios, se comunica con un servidor remoto y empieza a instalar aplicaciones en el dispositivo del usuario[21]. Este tipo de malware garantiza control remoto del dispositivo.

ANDROID.WALKIN WAT: versión troyana de la aplicación Walk and Text disponible en el mercado de aplicaciones de Android [22], la cual roba información personal del teléfono y la envía a un servidor remoto. Con esta información, la aplicación empieza a enviar un mensaje antipiratería a todos los contactos del dispositivo móvil [23] [24].

ADWLAUNCHER DEVICE ADMIN: troyano descubierto en Agosto del 2012, capaz de cambiar el estado de la conexión de red y el fondo de pantalla, crear mensajes, expandir o colapsar la barra de estado e iniciar una llamada telefónica sin la confirmación del usuario y sin usar la interfaz gráfica[25]. Al momento de instalación, esta aplicación pide permisos para acceder a la información de: las tareas que están corriendo en el teléfono, redes, estado de la conexión Wifi del teléfono, información del proveedor de datos. La aplicación no podía ser desinstalada del dispositivo por medio del manejador de aplicaciones de Android. Además, la aplicación recolectaba los nombres de todas las aplicaciones instaladas en el dispositivo y las enviaba a un servidor remoto. Actualmente, la aplicación se encuentra bajo el nombre ADW.Launcher2.

ICALENDAR: aplicación malware que se hace pasar por una aplicación para poder visualizar el calendario que viene por defecto en el dispositivo como un calendario al estilo de la plataforma iOS [26]. Cuando se instala, la aplicación envía un mensaje premium a un servidor remoto en China.

TAPLOGGER: aplicación troyana que captura la información de la contraseña del bloqueo de pantalla del dispositivo y los números ingresados al hacer una llamada telefónica. Sabiendo el contexto del evento tap del sistema operativo Android y la distribución de la vista actual de la pantalla táctil del dispositivo se puede inferir lo que el usuario ingreso [27]. Esta aplicación no requiere permisos de movimiento pero si de red para enviar lo que el usuario ingresa en la pantalla táctil al tocarla a un atacante remoto.

CLEANEDOUT: troyano descubierto en GooglePlay que permitía al atacante controlar remotamente el dispositivo del usuario. Además, intentaba instalar automáticamente un malware para computador si el dispositivo era conectado a un computador con sistema operativo Windows. Descubierta por Kaspersky [28], la aplicación le permitía al atacante conocer el número telefónico del usuario, la localización de este, el contenido de sus mensajes, entre otras cosas [29].

4

TOUCHLOGGER: malware sensorial, que aprovecha la información de los sensores del dispositivo para obtener información privada sensible del usuario. Por medio del acelerómetro, el cual proporciona información sobre el movimiento del teléfono, usándolo para inferir la entrada del usuario al teclado virtual del dispositivo como por ejemplo: contraseñas [30].

HOUNGTOUTOU: malware oculto en aplicaciones Android y distribuido a través del mercado de aplicaciones, conocido también como troyano ADRD. Esta aplicación solicita permisos de usuario adicionales y ejecuta actividades en el background del dispositivo, sin que el usuario se dé cuenta. El objetivo principal del malware son los usuarios en China.

Una vez que se corre una aplicación contaminada con este malware, se envían datos cifrados con información del teléfono a un servidor remoto, recibiendo como respuesta comandos para interactuar con el dispositivo [31].

GEINIMI: troyano surgido en China que compromete una gran cantidad de datos personales en el dispositivo de un usuario y los envía a servidores remotos. Una vez que el malware se instala en el dispositivo, puede recibir comandos de un servidor remoto, que le permiten al dueño del servidor controlar el dispositivo.

Este malware es distribuido a través de aplicaciones de terceros en las tiendas de aplicaciones en China. La información específica que el troyano recolecta del dispositivo consiste en: coordenadas de localización, identificadores únicos del dispositivo y la tarjeta SIM [32].

SOUNDCOMBER: aplicación tiene el permiso de grabar audio y monitorizar la actividad de llamada en el dispositivo, mientras que una segunda aplicación obtiene permisos de Internet. Cuando las aplicaciones colisionan, pueden capturar el número de la tarjeta de crédito (hablado por el usuario durante la llamada) y filtrarlo a un adversario remoto. Esto es conocido como un ataque de colusión en el cual, aplicaciones maliciosas actúan con el fin de fusionar sus conjuntos de permisos y obtener un conjunto de permisos que no han sido aprobados por el usuario [33].

Los ataques de colusión pueden subdividirse según el canal sobre los cuales se comunican [34] [35], por ejemplo: los canales abiertos como sockets frente a los canales cubiertos como bloqueos de archivos o nivel de volumen en el dispositivo.

DROIDREAM (DROIDDREAM LIGHT): malware que puede aparecer cuando se activa un

movimiento en el estado del teléfono como una llamada entrante [36]. Este malware no requiere de ninguna acción por parte del usuario para que el código se ejecute [37]. Algunas aplicaciones afectadas por este malware son: Magic Photo Studio, System Monitor, Quick Photo Grid, Delete Contacts, entre otros.

ACKPOSTS.K: malware que se hace pasar por un lector manga. Una vez que se ejecuta, la aplicación puede:

• Subir todos los contactos de la víctima y toda su información de cuenta a una URL (servidor virtual con un proveedor de computación en la nube)

• Enviar spam a todos los contactos del dispositivo con un link de descarga del malware

• Intentar quitar dinero al usuario

La forma de quitarle dinero al usuario se basa en que la aplicación le muestra al usuario información diciéndole que se acaba de suscribir a películas de adultos y que a menos de que se pague un servicio de cargo monetario, la aplicación divulgará la información de suscripción a todos los contactos del dispositivo del usuario [38].

AMENAZAS BASADAS EN WEB:

En esta categoría se encuentran los ataques de Phishing, páginas web maliciosas y comprometidas. Phishing es un ataque basado en imitación de sitios web confiables para divulgar información personal o bancaria. Los sitios web comprometidos son sitios web legítimos pero que han sido infectados por alguien y las páginas web maliciosas son las que llevan a aplicaciones maliciosas.

NOTCOMPATIBLE: ejemplo de sitio web comprometido, el cual es descargado automáticamente cuando el navegador de Android visita una página infectada pero en forma de actualización del sistema, para que no haya sospechas por parte del usuario y se pueda completar su instalación.

GGTRACKER: troyano que registra a la víctima a una suscripción de servicios de mensajería PREMIUM, afectando solo a usuarios dentro de los Estados Unidos [39]. Consiste en una aplicación descargada automáticamente al dispositivo móvil luego de visitar páginas web maliciosas que imitan al mercado de aplicaciones de Android [40] y que puede llevar al cargo en la factura del teléfono del usuario.

ANDROID.STELS: malware que se instala en el dispositivo y se comunica con un servidor remoto para recibir comandos, permitiéndole ejecutar archivos, instalar / desinstalar aplicaciones, hacer llamadas telefónicas, mostrar notificaciones y robar la lista de contactos del teléfono o modificarla [41]. La aplicación se descarga después de visitar una página para la actualización del programa Adobe Flash Player (complemento que muchas veces sirve para poder visualizar videos o páginas web) [42] y se encuentra bajo el nombre de FLASHPLAYERUPDATE.

ZERTSECURITY: troyano que afecta usuarios Android en Alemania. El ataque se desempeña como una campaña de Phishing, haciendo pasar como una aplicación de seguridad certificada que solicita al usuario información como su número de cuenta bancaria y PIN [43].

La institución bancaria con la cual se comprometía el ataque es Postbank [44] (banco de Alemania), el cual requería de un número de cuenta y PIN para acceder a la web.

Por medio de la suplantación de identidad y controlando los mensajes enviados al dispositivo del usuario el atacante puede: acceder a la cuenta web y revisar o realizar transacciones.

CHULI (CONFERENCE): ataque conocido como SpearPhishing (un tipo de fraude por email). El ataque se originó cuando se hackeo la cuenta de un grupo activista Tibetano, en donde se engañó a sus miembros haciéndoles creer que habían recibido una actualización sobre una conferencia para activistas Chinos, Tibetanos, Mongoles y Turcos organizada por el Congreso Mundial Uyghur [45]. El email enviado a los miembros contenía como archivo adjunto una carta, que en realidad era un archivo APK malicioso llamado “WC’s Conference.apk”. Cuando se ejecutaba el archivo, se subían todos los mensajes, contactos e historiales de llamadas del dispositivo a un servidor remoto [46].

ADWARE:

Muchas aplicaciones realizan publicidad móvil, las cuales llevan muchas veces a cambios de configuraciones en el dispositivo, cambio de navegador, entre otros. Se ha demostrado que esta publicidad explota los permisos de su aplicación host para recolectar información sobre el usuario, incluyendo datos confidenciales de privacidad como contactos o localización [47]. BADNEWS: se hace pasar como una aplicación inocente, pero en realidad es una red de distribución maliciosa. BadNews es una red de publicidad maliciosa que puede: enviar mensajes de noticias falsas, solicitar a los usuarios instalar aplicaciones y

enviar información confidencial como su número de teléfono y el ID del dispositivo a un servidor remoto. BadNews promueve además o hace publicidad a otras aplicaciones maliciosas para que sean instaladas en el dispositivo [48]. Ejemplos de aplicaciones de este tipo: live.photo.savanna / savageknife. La primera es una aplicación infectada con el adware BadNews, la cual se hace pasar por una aplicación de protector de pantalla para el dispositivo, pero cuando es instalada ataca con publicidad al dispositivo y además toma datos del teléfono como el identificador y lo envía a un servidor remoto [49]. El segundo es un juego infectado con el adware BadNews, el cual solicita al usuario instalación de aplicaciones maliciosas y obtiene información del dispositivo.

SPAMSOLDIER: spammer que usaba dispositivos infectados para enviar mensajes de texto con spam a distintos usuarios sin el consentimiento del dueño del dispositivo. SpamSoldier se propaga a través de mensajes de texto que se anuncian en versiones gratuitas de juegos como Need for Speed [50] o Angry Birds Space [51]. Una vez que el usuario hace click en un enlace de uno de estos mensajes, el dispositivo descarga una aplicación que pretende instalar el juego. Al abrir esta aplicación “instaladora”, el usuario activa SpamSoldier.

Esta aplicación envía spam a una lista de 100 números telefónicos en Estados Unidos y esconde cualquier evidencia de actividad maliciosa, pues el usuario no podrá ver los mensajes enviados desde el dispositivo [52].

MECANISMOS DE SEGURIDAD A NIVEL DE COMPONENTES:

La plataforma Android posee una seguridad multicapas. Además, el sistema está diseñado para que se puedan construir aplicaciones con permisos por defecto y así evitar tomar decisiones acerca de seguridad.

CARACTERISTICAS GENERALES DE SEGURIDAD EN ANDROID:

• Un framework con implementaciones de funcionalidades de seguridad como criptografía, permisos y comunicación entre procesos IPC (Interprocess Communication) segura.

• Tecnologías como ASLR [53], NX, ProPolice [54], safe_iop [55], OpenBSD dlmalloc [56], OpenBSD calloc [56] y mmap_min_addr de Linux [57] para mitigar riesgos asociados con errores de manejo de memoria comunes.

• Sistema de archivos encriptado que puede ser habilitado para proteger datos perdidos o dispositivos robados.

6

• Permisos de usuario garantizado para restringir el acceso a características del sistema y datos de usuario.

• Permisos de aplicación para controlar datos de aplicaciones en una base por aplicación.

SEGURIDAD A NIVEL DE SISTEMA Y KERNEL:

A nivel de sistema operativo, la plataforma Android ofrece la seguridad del Kernel de Linux así como una IPC (comunicación entre procesos) segura, para así permitir la comunicación segura entre aplicaciones que corren en diferentes procesos. Incluso el código nativo está restringido por el Application Sandbox.

Seguridad Linux [58]: el kernel de Linux es usado en millones de ambientes de seguridad, Linux se ha convertido en un kernel confiable y estable. El kernel provee a la plataforma, varias características de seguridad como:

• Un modelo de permisos basado en el usuario • Aislamiento de procesos • Un mecanismo extensible para IPC segura • La habilidad de remover partes del kernel que no

sean necesarias y que sean potencialmente inseguras

Como sistema operativo multiusuario, Linux pretende aislar recursos de usuario para:

• Prevenir que el usuario A lea archivos del usuario B.

• Asegurar que el usuario A no gaste la memoria del usuario B.

• Asegurar que el usuario A no gaste recursos de CPU del usuario B.

• Asegurar que el usuario A no gaste dispositivos del usuario B (por ejemplo: GPS, bluetooth, entre otros)

Application Sandbox [58]: la plataforma Android asigna un ID de usuario único (UID) a cada aplicación y corre cada aplicación en un proceso por separado. Es decir, cada aplicación tiene sus propios permisos. Cada uno de los procesos que provengan de la aplicación será ejecutado en el contexto de ese UID que se encarga del acceso a recursos de bajo nivel.

El kernel presenta seguridad entre aplicaciones y el sistema a nivel de procesos, a través de IDS de usuarios y de grupos asignados a las aplicaciones. Las aplicaciones tienen acceso limitado al sistema operativo. Si la aplicación A trata de hacer algo malicioso como leer datos de la aplicación B o marcar un número telefónico sin permiso, el sistema operativo protege esto, porque la aplicación A no tiene privilegios de usuario apropiados.

El Sandbox es simple y está basado en una separación de procesos de usuario estilo UNIX y permisos de archivos. Como el Application Sandbox se encuentra en el Kernel, el modelo de seguridad se extiende a código nativo y aplicaciones del sistema operativo. Todos los componentes que están arriba del Kernel en la arquitectura de la plataforma corren dentro del Application Sandbox.

En Android no hay restricciones acerca de cómo debe ser escrita una aplicación para brindar seguridad. Para romper la seguridad en el Application Sandbox, se debe comprometer la seguridad a nivel del Kernel de Linux.

Partición del sistema y modo seguro [58]: la partición del sistema contiene el Kernel de Android, así como las librerías del sistema operativo, las aplicaciones y las aplicaciones en tiempo de ejecución. La partición está configurada como solo lectura. Cuando un usuario arranca el dispositivo en modo seguro [59] [60], solo las aplicaciones principales de Android están disponibles, lo cual asegura que el ambiente donde carga el dispositivo del usuario esté libre de software pirata o software que es parecido al de una compañía dedicada a la venta del mismo.

Permisos del sistema de archivos: permisos que aseguran que un usuario no pueda alterar o leer archivos de otro usuario.

Cifrado [58]: la plataforma Android provee un conjunto de APIs criptográficos para el uso de aplicaciones. Aquí se encuentran implementaciones estándar como AES (Advanced Encryptation Standard) [61], RSA (Rivest, Shamir y Adleman) [62] [63], DSA (Algoritmo de firma digital) [64] y SHA [65] [66]. Los APIs son proporcionados para protocolos de comunicación de alto nivel como SSL [67] y HTTPS [68] [69] (protocolos criptográficos de comunicación segura a través de la red o Internet).

Android 4.0 introdujo la clase KeyChain [70] dentro de su API, la cual permite a las aplicaciones usar la credencial de almacenamiento del sistema para acceder a llaves privadas y certificados.

Mejoras de seguridad en el Manejo de Memoria [58]:

Android 1.5+:

• ProPolice [54] para prevenir saturaciones del buffer de pila.

• Safe_iop [55] para reducir desbordamiento de entero.

• Extensiones a OpenBSD dlmalloc [56] para prevenir vulnerabilidades double free [71] [72] (que ocasiona desbordamiento de pila) y para prevenir chunk consolidation attacks [73] [74].

• OpenBSD calloc para prevenir desbordamiento de enteros durante asignación de memoria.

Android 2.3+:

• Protección a vulnerabilidades de formato cadena no controlado [75] (-Wformat-security –Werror=format-security), las cuales radican en el uso sin control de las entradas de los usuarios a un sistema como parámetros de cierta función.

• Hardware-based No eXecute (NX) para prevenir ejecución de código en la pila, separando las áreas de memoria usadas para albergar las instrucciones del procesador (código) y las de almacenamiento de datos.

• Linux mmap_min_addr [57] para mitigar desreferenciación de privilegios null pointer.

Android 4.0+:

• Address Space Layout Randomization (ASLR) [53], para aleatorizar lugares clave en memoria.

Android 4.1+:

• Soporte PIE(Ejecutable independiente de posición) [76] [77], es código de máquina que se coloca en algún lugar de la memoria principal y se usa para bibliotecas compartidas, para que el mismo código de la biblioteca, se pueda cargar en una ubicación en cada espacio de direcciones de programa en el que no se solapará con cualquier otro uso de la memoria.

• Reubicación de solo lectura/ enlazamiento inmediato (-WI, -z, relro –WI, now).

• dmesg_restrict [78] habilitado (para evitar fugas de direcciones Kernel).

• kptr_restrict habilitado (para evitar fugas de direcciones Kernel).

Android 4.2+:

• FORTIFY_SOURCE [79], para realizar limites automáticos de comprobación de funciones peligrosas y así, prevenir desbordamiento de buffer.

Root de dispositivos [58]: en la plataforma Android solo el Kernel y un pequeño subconjunto de aplicaciones núcleo corren con permisos de root. Android no previene a un usuario o aplicación con permisos de root, de modificar el sistema operativo, el Kernel y cualquier otra aplicación. Los permisos root proveen acceso completo a todas las aplicaciones y a todos los datos de las aplicaciones.

Los usuarios que cambian permisos en Android para obtener accesos root en las aplicaciones, incrementan la inseguridad por parte de aplicaciones maliciosas y fallas potenciales en aplicaciones. El cifrado de datos con una llave alojada en el dispositivo, no protege los datos de la aplicación de los usuarios root. Las aplicaciones pueden añadir una capa de protección de datos usando cifrado con una llave que no se aloje en el dispositivo (por ejemplo: en un servidor). Esto

produce seguridad temporal, pero en algún momento la llave debe ser proporcionada a la aplicación y por ende, se convierte accesible a usuarios root.

CARACTERISTICAS DE SEGURIDAD DEL USUARIO:

Cifrado del sistema de archivos [58]: desde la versión 3.0 de la plataforma Android, en adelante, se provee un sistema de cifrado de archivos completo. Toda la información de usuario puede ser cifrada en el kernel, usando la implementación dmcrypt de AES128 (Advanced Encryptation Standard) [61] con CBC y ESSIV:SHA256 [66][65].

La llave de cifrado es protegida por AES128 usando una llave derivada del usuario contraseña, previniendo acceso no garantizado a la información almacenada sin la clave del usuario del dispositivo. Para proveer resistencia contra ataques de fuerza bruta [80] o rainbow tables [81] (un tipo especial de tabla de búsqueda, usada en la recuperación de contraseñas en texto plano de un texto cifrado), la contraseña es combinada con un número aleatorio y un hash usando el algoritmo estándar PBKDF2 [82].

Para proveer resistencia ante ataques de diccionario de contraseñas [83], Android provee reglas de complejidad de contraseñas que pueden ser establecidas por el administrador del dispositivo y ejecutadas por el sistema operativo. El cifrado del sistema de archivos requiere el uso de un usuario - contraseña.

Protección de contraseñas [58]: la plataforma Android puede ser configurada para verificar una contraseña proporcionada por el usuario antes de suministrar acceso al dispositivo. Además de prevenir el uso no autorizado del dispositivo, esta contraseña protege la llave para el cifrado completo del sistema de archivos.

Administración del dispositivo [58]: desde la versión 2.2 de la plataforma Android en adelante, se proporciona el API de Administración del Dispositivo Android, el cual provee características de administración del dispositivo a nivel de sistema. Por ejemplo, la aplicación integrada de correo electrónico utiliza la API de Android para mejorar el apoyo Exchange (herramienta para cuentas de correo). A través de la aplicación de correo electrónico, los administradores pueden hacer cumplir las políticas de contraseñas, incluyendo contraseñas alfanuméricas o PIN numérico a través de dispositivos. Los administradores también pueden borrar de forma remota (restaurar los valores predeterminados de fábrica) teléfonos perdidos o robados.

Almacenamiento de credenciales [58]: la plataforma Android incluye por defecto un conjunto

8

de Autoridades Certificadoras (CAs) que son confiables para operaciones como establecer conexiones SSL dentro de un navegador. Desde la versión 4.0 de la plataforma Android en adelante, los usuarios pueden deshabilitar estas Autoridades Certificadoras preinstaladas dentro de la configuración del sistema. Además, los usuarios pueden agregar CAs o certificados al sistema, importándolas por medio USB.

Desde la versión 4.1 de la plataforma Android, en adelante, se permite a los OEMs (fabricantes de equipo original) añadir hardware de respaldo para almacenamiento KeyChain, el cual une llaves privadas al dispositivo en el que están almacenadas.

Red privada virtual: Android proporciona una incorporación en el cliente VPN [84] [85] (Red Privada Virtual) con soporte para PPTP [86] (Protocolo de Comunicaciones Punto a Punto), L2TP [87] (Layer 2 Tunneling Protocol), e IPsec VPNs. Además, desde la versión 4.0 en adelante, la plataforma introduce la clase VPNService [88] para apoyar las soluciones VPN de terceros. La versión 4.2 de la plataforma Android, permite que un usuario configure una VPN como always on (siempre encendida), para indicar que las aplicaciones puedan conectarse a la red solo por medio del VPN conectado.

SEGURIDAD DE APLICACIONES:

Modelo de permisos de Android [58]: todas las aplicaciones en Android corren en el Application Sandbox. Por defecto, una aplicación puede acceder solo a ciertos recursos del sistema. El sistema gestiona el acceso a recursos por parte de las aplicaciones Android. En caso de que un recurso sea usado incorrecta o maliciosamente, puede afectar la experiencia de usuario, la red o los datos del dispositivo.

Estas restricciones de acceso a recursos se aplican de diversas formas, algunas funciones están restringidas por una falta intencional de APIs a las funcionalidades sensibles (por ejemplo, no hay ninguna API de Android para manipular directamente la SIM CARD). La separación de funciones, en algunos casos, proporciona una medida de seguridad. Las APIs sensibles, están destinadas para el uso de aplicaciones de confianza y son protegidas a través de permisos.

Las APIs protegidas incluyen: funciones de cámara / GPS / funciones de bluetooth / funciones de teléfono / funciones de SMS / conexiones de red y datos

Estos recursos son solo accesibles a través del sistema operativo. Para hacer uso de las APIs protegidas en el dispositivo, una aplicación debe

definir las funcionalidades que necesita en su manifiesto (archivo principal).

Cuando se instala una aplicación, el sistema muestra un diálogo al usuario que indica los permisos requeridos y pregunta si se desea continuar con la instalación. El usuario no puede permitir o denegar permisos individuales, sino en bloque. Los permisos son quitados si una aplicación es desinstalada.

Dentro de la configuración del dispositivo, los usuarios pueden ver los permisos para las aplicaciones que han instalado previamente. En caso de que una aplicación intente usar una función protegida que no se ha declarado en el manifiesto de la aplicación, la falla de permiso resultará en una excepción de seguridad lanzada hacia esta aplicación.

Cuando se define un permiso, un atributo de nivel de protección, le indica al sistema cómo el usuario debe ser informado de las aplicaciones que requieren del permiso o a quien se le permite tener el permiso.

Aplicaciones de terceros (third-party applications): la razón por la que se muestran los permisos de una aplicación al momento de instalarla, es porque el usuario debe determinar si cumple con sus necesidades o no.

La visión de Android es tener usuarios que cambien fácilmente entre aplicaciones a voluntad. Uno de los objetivos de seguridad de Android es transmitir información eficientemente al usuario, lo cual no se puede lograr mostrándole diálogos que el usuario ignorará. Presentando la información solo una vez y solo cuando se necesita, el usuario puede pensar sobre qué está aceptando o denegando.

APIs sensibles a los costos: un API sensible al costo, es cualquier función que pueda generar un costo para el usuario o la red. La plataforma Android ha colocado las APIs sensibles en la lista de APIs protegidas controlados por el sistema operativo. El usuario otorgará permisos a las aplicaciones de terceros que requieran usar las APIs sensibles a los costos.

Acceso a la tarjeta SIM: el acceso a Bajo nivel a la SIM CARD, no está permitido para aplicaciones de terceros. El sistema operativo maneja todas las comunicaciones con la SIM CARD incluyendo el acceso a la información personal. Las aplicaciones tampoco pueden usar comandos AT (ATtention Command) [89] ya que estas son manejadas por la Capa de Interfaz de Radio (Radio Interface Layer) [90], la cual provee una capa de abstracción entre los servicios de telefonía de Android y el hardware de radio.

Información personal: dentro del conjunto de APIs protegidas, se encuentran los APIs que proveen acceso a la información de usuario en Android. Con el uso, los dispositivos acumulan datos de usuario

dentro de aplicaciones de terceros instaladas por el usuario. Para proteger los datos de usuario se pueden usar chequeos de permisos de Android.

Las aplicaciones que recolectan información personal, tienen esos datos solo para esa aplicación en específico.

Dispositivos con entrada de datos sensibles: Android provee dispositivos con entrada de datos sensibles que permiten que las aplicaciones interactúen con la cámara, micrófono o GPS. Para que una aplicación de terceros acceda a estos dispositivos, primero debe tener un acceso implícito provisto por el usuario a través de los permisos de la plataforma.

Metadata del dispositivo: Android restringe el acceso a datos que no son intrínsecamente sensibles, pero que pueden revelar indirectamente características del usuario, sus preferencias y la forma como estos usan su dispositivo. Por defecto, las aplicaciones no tienen acceso a logs del sistema operativo, historial del navegador, números telefónicos o información de identificación de la red o hardware del dispositivo, pero una aplicación podría solicitar acceso a esta información en tiempo de instalación.

Firma de aplicaciones [58]: la firma de código ayuda a los desarrolladores a identificar el autor de la aplicación y actualizar su aplicación sin crear interfaces complicadas ni permisos. Cada aplicación que corre en la plataforma Android debe ser firmada por el desarrollador. Las aplicaciones que se intenten instalar sin haber sido firmadas, serán rechazadas por Google Play [40] o el instalador de paquetes de Android.

En Google Play [40], la firma de aplicaciones sirve para mostrar la confianza que Google [91] tiene con el desarrollador y la confianza que el mismo tiene con su aplicación.

Para poner una aplicación en el Application Sandbox, primero hay que firmarla. La firma define qué ID de usuario se asocia con qué aplicación. La firma de aplicaciones asegura que una aplicación no puede acceder a cualquier aplicación, excepto a través de IPC.

Cuando una aplicación se instala en el dispositivo, el Administrador de Paquetes comprueba que el archivo APK ha sido firmado, con un certificado incluido en ese APK. Si la llave publica del certificado coincide con la llave para firmar cualquier otro APK en el dispositivo, el nuevo APK tiene la opción de especificar en el manifiesto que compartirá un UID (ID de usuario) con los otros APKs firmados igualmente.

Android provee la firma de código usando certificados auto firmados que los desarrolladores

pueden generar sin ayuda externa o permisos. La firma del desarrollador se usa para asegurar una política del mismo origen para las actualizaciones de aplicación. Las aplicaciones no tienen que ser firmadas por una autoridad central (empresa encargada de certificación). Android no realiza verificación de Autoridades Certificadoras para los certificados de aplicación.

Gestión de derechos digitales: la plataforma Android proporciona un marco DRM extensible (Framework de gestión de derechos digitales), el cual permite a las aplicaciones manejar contenidos con derechos protegidos de acuerdo con las restricciones de licencia asociadas al contenido.

INVESTIGACION BASADA EN EL DISEÑO:

Tiene como objetivo contribuir a la solución de problemas relevantes al mismo tiempo que se hacen aportes significativos en un área del conocimiento, mediante el análisis de problemas aun no resueltos en un ambiente del mundo real y su solución de una manera novedosa y rigurosa a través del diseño de artefactos [92].

Esta metodología describe las siguientes fases:

1. Identificación 2. Determinación 3. Diseño y desarrollo 4. Evaluación 5. Comunicación

PRINCIPIOS DE SEGURIDAD DE LA INFORMACION:

La seguridad de la información generalmente está enfocada hacia los sistemas de Tecnologías de Información. Esta seguridad contiene la seguridad tanto física como operacional y organizacional del sistema de información.

A continuación, se describen los principios que conforman la seguridad de la información [93]:

Integridad: es la garantía de la exactitud y completitud de la información y los métodos de su procesamiento. Asegurar que la información puede ser lo suficientemente precisa para su propósito. Este principio, representa uno de los principales indicadores de seguridad de la información.

La integridad de la información, no se basa solo en que el dato sea correcto, sino que además, se pueda confiar en él [94]. Para este principio, se tienen métodos como Hashing [95] , firma electrónica o protección con antivirus.

Confidencialidad: principio de seguridad que genera el requisito de protección contra intentos deliberados o accidentales para realizar lectura de datos no autorizados. La confidencialidad abarca los datos en

10

el almacenamiento, durante el proceso y mientras están en tránsito [96].

Es la garantía de que la información se comparte solo entre personas u organizaciones autorizadas. La violación de este principio, se puede dar cuando los datos no se manejan de manera adecuada [94]. Para esto, se tienen métodos de aseguramiento como tipos de cifrado: simétrico (una clave secreta, se aplica al texto de un mensaje para cambiar su contenido) o asimétrico (un par de claves, una publica disponible para cualquier persona que quiera enviar un mensaje y una privada solo para la persona que la conoce) [97].

Disponibilidad: principio de seguridad que declara que los usuarios autorizados tienen acceso a la información cuando lo requieran y de que el sistema es capaz de recuperarse rápida y completamente en caso de ocurrir un desastre. En este principio se consideran aspectos como: tolerancia a fallos, recuperación, redundancia, entre otros.

Este principio genera el requisito de la protección contra algún modo de causar una denegación de servicios o de datos [96].

Control de acceso: el principio de control de acceso o autorización: se asegura que un usuario autorizado tenga acceso a una información determinada.

Para este principio, se pueden usar por ejemplo ACL’S (colección secuencial de sentencias de permiso o rechazo que se aplican a direcciones o protocolos de capa superior) [98] o DMZ (red local ubicada entre la red interna y externa de una organización) [99].

Autenticación: principio que declara que quién solicita un acceso es quién dice ser. Para poner en práctica este principio, generalmente se verifica la identidad de un usuario, proceso o dispositivo, como un prerrequisito para permitir el acceso a los recursos de un sistema por medio de: contraseñas, dispositivos biométricos, firmas electrónicas, entre otros [96].

No repudio: asegurar que una entidad intervino en una transacción, es decir, que quién genere un evento válidamente, no pueda retractarse. Esto apoya la disuasión, el aislamiento de fallos, la detección y prevención de intrusos y acciones legales. Para tener un control de esto muchas veces se utilizan registro de eventos o logs.

Observancia: principio que se encarga de verificar el adecuado funcionamiento de la seguridad.

POLITICAS DE SEGURIDAD:

Uno de los componentes de los modelos de seguridad son las políticas de seguridad. Una Política de seguridad es un conjunto de requisitos definidos por

los responsables de un sistema, que indica en términos generales que está y que no está permitido en el área de seguridad durante la operación general del sistema [100].

La RFC 1244 define una Política de seguridad como una “declaración de intenciones de alto nivel que cubre la seguridad de los sistemas informáticos y que proporciona las bases para definir y delimitar responsabilidades para las diversas actuaciones técnicas y organizativas que se requerirán” [101].

A grandes rasgos, la formulación de políticas de seguridad conlleva a:

- Un análisis de riesgos, para adecuar políticas al contexto.

- Tener unos encargados para monitorizar las operaciones y los cambios en las políticas de seguridad.

En el caso del Proyecto de investigación, nuestros cambios en las políticas de seguridad se ven relacionados con el versionamiento de la plataforma. Para el alcance de este proyecto, se tuvo en cuenta las políticas definidas por la plataforma Android versión 4.1.

POLITICAS DE SEGURIDAD DE LA PLATAFORMA ANDROID:

SELINUX:

Secutiry Enhanced Linux (SELinux) [102], implementa una política impulsada por control obligatorio de acceso (MAC) para el kernel de Linux. Una decisión de diseño esencial de su arquitectura es que la toma de decisión de una política, se desvincula de la política de aplicación lógica. SELinux usa el módulo de seguridad de Linux (LSM) que ofrece acceso a varios puntos de aplicación de control de bajo nivel de recursos como archivos, IPC local o protecciones de memoria.

Cuando una operación del LSM se da, por ejemplo: se abre un archivo, el módulo SELinux solicita una decisión de política de un servidor de seguridad en el kernel que gestiona las reglas de las políticas y contiene el acceso a las decisiones lógicas. Dependiendo de la decisión del servidor de seguridad, el módulo de seguridad de SELinux deniega o permite la operación para proceder.

En un sistema SELinux cada objeto (archivos, canales IPC, ect) y sujeto (procesos) esta etiquetado con un contexto de seguridad que consiste en una tripleta de atributos (usuario, rol y tipo). Estos atributos determinan a que objetos un sujeto puede acceder.

El refuerzo de tipos (type enforcement) es el mecanismo primario de control de acceso en SELinux y está basado en el tipo de contexto del

atributo. Por defecto, todos los accesos son negados y deben ser garantizados explícitamente a través de reglas de políticas permitir reglas en terminología SELinux.

El atributo usuario y rol forman la base para el control de acceso Role-Bases que se basa en el refuerzo de tipos definiendo que tipo y que combinaciones de rol son válidas para cada usuario en la política.

Políticas dinámicas: SELinux también implementa políticas dinámicas como banderas booleanas que afectan decisiones de políticas condicionales en tiempo de ejecución. Los booleanos y las condiciones deben definir prioridad al despliegue de políticas. Las condiciones/booleanos nuevos no pueden ser añadidas después de que la política ha sido cargada sin recompilar la política entera. Ejemplos de políticas dinámicas: booleanos que cambian entre “modo cumplimiento” y “modo permisivo”. El mecanismo de políticas dinámicas esta implementado en forma de declaraciones if para permitir reglas en la política.

Administradores de objetos espaciales de usuario (USOMs) (Userspace Object Managers): Responsables de asignar contextos de seguridad a los objetos que manejan, consultando el servidor de seguridad SELinux para decisiones de control de acceso y haciendo cumplir estas decisiones. Ejemplos de USOMs: X Windows System Server [103], GConf [104] , SE-PostgreSQL [105]

SEANDROID:

Prototipa SELinux para el kernel de Linux en Android [106] [107]. Distribuye servicios del sistema y aplicaciones en diferentes espacios del dominio de seguridad del kernel, aislando aplicaciones entre sí por medio del servicio de Multi-level security (MLS) de SELinux [102].

• SEAndroid hace del Binder Driver de Android un Manejador de Objetos de Espacio en Kernel (KOMs) (KernelSpace Object Manager), asegurando que todo Binder IPC está sujeto a toda la aplicación de las políticas de SE Android.

• SEAndroid etiqueta los procesos de aplicación con contextos de seguridad específicos de SELinux que se usan luego en el refuerzo de tipos.

• Cuando se encuentra una nueva aplicación Android, los procesos son bifurcados de un proceso del sistema (Zygote) [108], el cual viene instalado con las librerías de Android y permite

los inicios rápidos de procesos de una nueva aplicación [109].

• SEAndroid emplea un mecanismo para obtener el contexto de seguridad de aplicaciones en tiempo de instalación.

• Basados en los permisos que las aplicaciones solicitan o la firma del desarrollador, a las aplicaciones se les asigna un tipo de seguridad.

El mapeo de la meta-información de las aplicaciones a tipos de seguridad está definido en las políticas SEAndroid.

SEAndroid, además provee soporte para políticas MAC en la capa de middleware (MMAC). MMAC consiste en tres mecanismos:

• MAC en tiempo de instalación: lleva a cabo una política basada en chequeo al momento de la instalación de nuevas aplicaciones y niega la instalación, cuando la aplicación solicita una combinación definida de permisos

• Revocación de permisos: este mecanismo anula el servicio de chequeo por defecto de Android, con una decisión basada en políticas para permitir/denegar a una aplicación aprovechar un permiso garantizado

• Intención MAC: que protege con una aplicación de (listado blanco) el envío de Intentos (intents) a Actividades (Activities), Receptores de Broadcast (Broadcast Receivers) y Servicios (Services). Las reglas del (listado blanco) están basadas en el tipo de seguridad del emisor y el receptor del mensaje de Intento, así como los datos del mensaje.

POLITICAS DEL API DE ADMINISTRACION DEL DISPOSITIVO:

El API de Administración del dispositivo se usa para escribir aplicaciones de administración de dispositivos que los usuarios instalan en sus dispositivos. La aplicación de administración del dispositivo hace cumplir las políticas de seguridad [110] [111].

Una vez que se instala la aplicación de administración de dispositivos, el dispositivo está sujeto a las políticas de este. El administrador puede:

• Preguntar al usuario para establecer una nueva contraseña.

• Bloquear inmediatamente el dispositivo. • Realizar un restablecimiento de fábrica en el

dispositivo, borrar los datos del usuario (si tiene permiso).

Si el usuario no activa la aplicación de administración de dispositivos, esta se mantiene en el dispositivo pero en un estado inactivo. Así, los usuarios no serán sujetos a sus políticas. Si un usuario incumple con una política de la aplicación de administración de

12

dispositivos, una vez está instalada, la aplicación decide cómo manejar esto.

Para desinstalar una aplicación de administración de dispositivo, los usuarios necesitan primero desactivar la aplicación como un administrador del dispositivo.

ARQUITECTURA DE LA PLATAFORMA:

La arquitectura de la plataforma Android está definida en tres capas: la capa de aplicaciones, la capa de framework de aplicación, la capa de librerías y tiempo de ejecución de Android y la capa del Kernel de Linux.

APLICACIONES:

La plataforma Android tiene un conjunto de aplicaciones básicas incluyendo un cliente de email, un programa de SMS (Short Message Service: para enviar y recibir mensajes de texto), calendario, mapas, navegador, contactos, entre otros. Todas las aplicaciones se escriben usando el lenguaje de programación Java [112].

FRAMEWORK DE APLICACIÓN:

La arquitectura de la plataforma Android, está diseñada para simplificar la reutilización de componentes. Los desarrolladores tienen acceso completo al mismo framework de APIs usados por las aplicaciones núcleo del sistema.

Esta capa está compuesta por los siguientes componentes [113] [114] [3]:

• View System (Sistema de vista): se pueden usar para construir una aplicación, incluyendo listas, rejillas, cajas de texto, botones e incluso navegadores web embebidos, entre otros componentes.

• Content Provider (Proveedor de contenido): permite que las aplicaciones accedan a datos de otras aplicaciones (por ejemplo: contactos), o que compartan su propia información. Maneja un conjunto de datos de aplicación compartidos, por ejemplo: se puede almacenar información en un archivo del sistema, una base de datos SQLite en la web o cualquier ubicación de almacenamiento persistente que la aplicación pueda acceder. Los proveedores de contenido también son útiles para leer y escribir datos que son privados para una aplicación y no compartidos.

• Telephony Manager (Administrador del teléfono): provee acceso a la información acerca de los servicios telefónicos del dispositivo. Contiene servicios y estados del teléfono, así como acceso a información de suscriptor. Las aplicaciones pueden recibir notificaciones sobre el cambio de estado del teléfono.

• Resource Manager (Administrador de recursos): provee acceso a recursos sin código como gráficos y archivos de diseño. Ejemplos: cadenas de texto traducidas a diferentes idiomas, imágenes, sonidos o layouts.

• Notification Manager (Administrador de notificaciones): permite a todas las aplicaciones desplegar alertas personalizadas en la barra de estados del sistema.

• Activity Manager (Administrador de actividades): maneja el ciclo de vida de las aplicaciones y provee una navegación común.

• Location Manager: provee acceso a los servicios del sistema de localización del dispositivo, permite a las aplicaciones obtener actualizaciones de la localización geográfica del dispositivo.

• Package Manager: maneja información relacionada con los paquetes de aplicación que están instalados actualmente en el dispositivo.

• Sensor Manager: permite manipular los elementos de hardware del teléfono como acelerómetro, sensor de luminosidad, sensor de presión, de proximidad, de temperatura, entre otros.

FRAMEWORK DE LIBRERIAS Y TIEMPO DE EJECUCION:

LIBRERIAS:

Dentro de las librerías de Android, se encuentran las siguientes [114] [3]:

System C Library (Sistema de librerías de C): una implementación derivada del sistema de librerías estándar de C (libc) atenta a los dispositivos que tengan Linux embebido.

Media libraries (Librerías media): basados en OpenCORE de PacketVideo [115], librerías que soportan reproducción y grabación de muchos formatos populares de audio y video, así como archivos de imágenes estáticas, como MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.

Surface Manager (Administrador de superficie): maneja el acceso a subsistemas de despliegue y a las capas de gráficos 2D y 3D de muchas aplicaciones.

LibWebCore (Librerías Web): moderno motor de navegador web que refuerza el navegador de Android y una vista web integrable.

SGL: el motor de gráficos 2D.

3D libraries (Librerías 3D): una implementación basada en los APIs OpenGL ES 1.0 [116], las librerías usan la aceleración del hardware 3D o la incluida (software 3D rasterizer altamente optimizado).

Freetype: mapa de bits y fuente vectorial para representaciones (renderizado).

SQLite: un potente y ligero motor de base de datos relacional disponible para todas las aplicaciones.

TIEMPO DE EJECUCION ANDROID:

Android incluye un conjunto de librerías principales que proveen la mayoría del funcionamiento disponible en las librerías del lenguaje de programación Java.

Cada aplicación de Android corre en su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik está hecho para que cada dispositivo pueda correr muchas máquinas virtuales eficientemente. La máquina virtual de Dalvik ejecuta archivos en un formato ejecutable dalvik (.dex), que esta optimizado para la cantidad de memoria mínima del sistema [114].

La máquina virtual está basada en registros y corre clases compiladas por un compilador del lenguaje Java que ha sido transformado al formato (.dex) por la herramienta incluida en el sistema “dx”.

Este componente además se hace cargo de la distribución de tareas por medio de hilos y del manejo de memoria de bajo nivel.

KERNEL DE LINUX:

Android está basado en la versión 2.6 de Linux para sistema de servicios principales como seguridad, manejo de memoria, manejo de procesos, red y drivers. El Kernel actúa como una capa de abstracción entre el hardware y el resto de la pila de software.

Display driver (Controlador de despliegue): en este componente se tiene en cuenta tanto el despliegue como los gráficos, las vistas y las entradas en el dispositivo.

Camera driver (Controlador de la cámara): es manejado por un servicio de cámara, accedido mediante la clase Camera, para configurar ajustes de captura de imagen, iniciar/ detener vista previa, sacar fotos y recuperar los marcos para la codificación del video. Para acceder al dispositivo de Cámara, se debe declarar el permiso de “CAMERA” en el manifiesto (archivo principal) de Android [117].

Bluetooth driver (Controlador de bluetooth): contiene funcionalidades como escaneo de dispositivos, conexión con dispositivos y manejo de transferencia de datos entre dispositivos. Los APIs

existentes para Bluetooth permiten a las aplicaciones [118]:

• Escanear otros dispositivos Bluetooth • Consultar el adaptador Bluetooth local, para los

dispositivos Bluetooth conectados • Establecer canales o sockets RFCOMM [119] • Conectarse a sockets específicos en otros

dispositivos • Transferir datos desde y hacia otros dispositivos

Para establecer una comunicación bluetooth usando los APIs, una aplicación debe declarar el permiso de “BLUETOOTH”.

Android IPC Binder: mecanismo de comunicación interproceso, por medio de este componente un proceso de Android llama a una rutina en otro proceso de Android, identificando el método a invocar y enviando los parámetros entre procesos [120]. Ejemplo de comunicación inter-procesos: Activity Manager (Administrador de actividades) – Windows Manager (Administrador de Ventana) – Alarm Manager (Administrador de Alarmas).

En el IPC Binder, cada proceso tiene su propia dirección de memoria, se provee el aislamiento de datos y se prevé interacción directa perjudicial entre procesos. El componente IPC Binder es la re-implementación de OpenBinder [121], el cual brinda enlaces a funciones y datos de un ambiente de ejecución a otro.

Características [120]:

• Driver que facilita la comunicación entre procesos.

• Alto desempeño por memoria compartida. • Pool de hilos por proceso para solicitudes de

procesamiento. • Conteo de referencias y mapeo de referencias de

objetos a través de procesos. • Llamados sincrónicos entre procesos.

USB driver (Controlador de USB): comunicación con los periféricos de hardware USB. En Android se manejan dos modos: periféricos USB y accesorios USB (hardware que implementa el protocolo accesorio de Android). En el modo accesorio USB, el hardware USB externo actúa como el huésped USB (host USB) [122] [123].

Keypad driver (Controlador de teclado): Android soporta una gran variedad de dispositivos de teclado incluyendo funciones especiales (controles de volumen y encendido), teclados QWERTY [124] [125] embebidos y teclados externos tipo computador con todas las funciones [126].

WIFI driver (Controlador de WIFI): componente que tiene funcionalidades de conexión Wifi (acceso a redes wifi), contiene además información de

14

velocidad de la red de Internet, direcciones IP, estado de negociaciones e información acerca de otras redes disponibles. Android tiene APIs que incluyen las funcionalidades de escanear, añadir, guardar, terminar e iniciar conexiones Wifi [127].

Audio driver (Controlador de audio): componente que maneja varias interfaces de audio. Android tiene APIs para reproducir y grabar archivos media de audio. Por ejemplo: acceso a volumen y modo de timbre, acceso a formatos de audio, entre otros. Las clases y métodos de interacción con el audio del dispositivo se encuentran en la API android.media de Android [128].

Power management (Manejo de energía): componente que permite el control del estado de energía del dispositivo, por ejemplo: estados (cargando/descargando), completo, desconocido, fuente de energía (USB, wireless, cargador de corriente alterna), entre otros [129] [130].

MEJORAS DE SEGURIDAD EN ANDROID 4.1:

Para mejorar la experiencia de usuario, la plataforma Android 4.1 tiene unas mejoras de seguridad [131] [132] [133]:

Servicios aislados: especificando android:isolatedProcess=”true” en la etiqueta <service> del API de Android, un servicio correrá en su propio proceso de ID usuario aislado que no tiene permisos por su cuenta.

Manejo de memoria: nuevas constantes en los métodos para el manejo de memoria, específicamente para conocer acerca del estado de la memoria.

Proveedores de contenido: un nuevo método a nivel de API de Android acquireUnstableContentProviderClient(), permite acceder a un cliente proveedor de contenido que puede ser inestable, de tal forma que una aplicación no se bloqueará si el proveedor de contenido lo hace.

Descubrimiento de servicio Wi-Fi directo: nueva API proporciona detección de servicios pre-asociada permitiendo a las aplicaciones obtener más información de los dispositivos cercanos sobre los servicios que soportan, antes de intentar conectarse.

Manejo de ancho de banda de la red: nueva API provee la habilidad de detectar conexiones a puntos de acceso móvil (tethering), cuando un dispositivo hace las funciones de un punto de acceso a la red o router.

Cifrado de aplicaciones: las aplicaciones con costo en el mercado de aplicaciones de Google están

cifradas con una llave específica del dispositivo antes de ser almacenadas en el dispositivo.

Nuevos permisos:

READ_EXTERNAL_STORAGE: provee acceso de lectura protegido a almacenamiento externo. En Android 4.1 por defecto, todas las aplicaciones aún tienen acceso de lectura. Hay una nueva opción de desarrollador para activar la restricción de acceso de lectura.

READ_USER_DICTIONARY: permite que una aplicación lea el diccionario del usuario. Esto solo puede ser requerido por un editor de diccionario como la aplicación de configuración del dispositivo.

READ_CALL_LOG: permite que una aplicación lea el registro de llamadas del sistema que contiene información sobre las llamadas entrantes y salientes.

WRITE_CALL_LOG: permite que una aplicación modifique el registro de llamadas del sistema almacenado en el dispositivo.

WRITE_USER_DICTIONARY: permite que una aplicación escriba en el diccionario del usuario.

3 Trabajos relacionados Para la investigación realizada, se buscaron trabajos relacionados en el área y se encontró lo siguiente:

APEX [134]:

Framework que permite dar permisos a una aplicación imponiendo restricciones en el uso de los recursos y que es compatible con el actual mecanismo de seguridad de Android [135]. Cuando un usuario instala una nueva aplicación en su dispositivo Android, debe confiar que no se usen de mala manera los recursos de su dispositivo.

Al momento de instalar una aplicación, Android presenta una lista de permisos requeridos por esta que deben ser permitidos si el usuario quiere seguir con la instalación. Esto se puede ver como una decisión todo o nada y una vez que el usuario da los permisos a la aplicación, no hay forma de revocarlos.

Apex le da al usuario muchas opciones de restricción del uso de los recursos de su dispositivo por aplicaciones diferentes. El usuario podrá dar algunos permisos o negar otros. Aparte de esto, Apex permite al usuario imponer restricciones en tiempo de ejecución del uso de los recursos. Para esto se creó Poly, un instalador de aplicaciones en Android, el cual permite especificar las restricciones para cada permiso en el tiempo de instalación usando una interfaz gráfica simple y fácil de usar.

Se modificó el framework de Android para instalación de aplicaciones, para que al momento de instalar una nueva aplicación, el usuario pueda hacer click en permisos individuales y especificar sus restricciones. Cuando el usuario hace click en un permiso, se le muestran las opciones de permitir, negar y restricción de permiso (acá solo se ha especificado por ejemplo el número de veces usadas y el tiempo del día que se le dará permiso a la aplicación).

Como trabajo futuro se espera realizar restricciones de permisos más robustas, en donde usuarios expertos que tengan conocimiento sobre cómo escribir políticas de uso puedan editar sus propias políticas.

ANDROMALY [136]:

Framework para detectar malware en dispositivos móviles Android basado en el sistema de detección de intrusos Host-Based (HIDS), el cual extrae y analiza un conjunto de especificaciones indicando el estado del dispositivo en tiempo de ejecución. La base del proceso de detección de malware consiste en el análisis, monitoreo, colección y pre-procesamiento de varias medidas del sistema como el consumo de CPU, el número de paquetes a través del Wi-Fi, el número de procesos y el nivel de batería.

Después de la colección de datos, las medidas se envían a un análisis por varias medidas de detección que evalúan la amenaza. El framework emplea técnicas de aprendizaje de máquina para realizar el sistema de detección de malware. El detector continuamente monitorea las especificaciones y eventos obtenidos del sistema y luego aplica el estándar de Aprendizaje de Maquina de clasificación, clasificando las observaciones como normal(benigno) o anormal(malicioso).

Luego se decidió evaluar los clasificadores candidatos: k-Means, Regresion, Histogramas, Arboles de decisión, Redes Bayesianas, entre otros. La evaluación de los clasificadores del aprendizaje de maquina se divide en dos: entrenamiento y prueba. En la fase de entrenamiento, se provee al sistema un conjunto de vectores de entrenamiento con especificaciones benignas y maliciosas. El algoritmo genera un clasificador entrenado, luego durante la fase de prueba, una colección diferente es clasificada por el clasificador entrenado, se evalúa el rendimiento del clasificador.

OTROS TRABAJOS:

Aparte los mecanismos mencionados anteriormente en la segunda sección provistos por la plataforma, se han establecido muchos artículos para mitigar ataques en la capa de middleware de Android, en donde el objetivo principal es ampliar esta capa con un control especifico de ataque [113] [114] [115] [116] [117].

Aunque muchas de estas soluciones son aproximaciones, es decir no se han terminado de poner en prueba (muchas no se encuentran en el mercado de aplicaciones de Android o no están finalizadas), muchas de estas, permiten mejorar el control de acceso a nivel de kernel; como es el caso de SEAndroid [118] o Tomoyo [119] para mitigar ataques de escalamiento de privilegios a bajo nivel [120] [121].

Por otro lado, Saint [122] o TISSA [123], proponen soluciones para hacer frente a los requisitos de seguridad y problemas específicos de los desarrolladores de aplicaciones, aplicaciones de terceros (compañías terceras) o usuarios finales. Ya que este tipo de stakeholders almacena datos sensibles en el dispositivo. Los requerimientos de seguridad de los stakeholders, además dependen del contexto en el que se encuentren. Por ejemplo: la política de seguridad en una empresa puede dictar que solo ciertas aplicaciones pueden ser accedidas durante horas laborales o mientras que el dispositivo se encuentra en el lugar de trabajo.

4 Desarrollo del trabajo El trabajo desarrollado tenía como objetivo general:

• Proponer un modelo de seguridad a nivel de la plataforma Android versión 4.1 que identifique los principales problemas de seguridad con sus respectivos componentes que involucran los principios de seguridad de: Integridad, Confidencialidad y Disponibilidad.

La metodología utilizada para cumplir con el objetivo propuesto en el trabajo fue la de Investigación basada en el diseño, descrita en el marco teórico.

Para cada fase metodológica, se plantearon unos objetivos específicos y unas actividades.

Fase metodológica 1:

Identificación del problema y motivación

Objetivos específicos:

• Analizar los diferentes tipos de ataques en la plataforma Android versión 4.1.

• Clasificar los ataques encontrados basados en los tres principales principios de seguridad de la información.

• Realizar una investigación acerca de la arquitectura de la plataforma Android versión 4.1 y sus componentes.


Definición de los objetivos de la solución

16


• Identificar los resultados y beneficios esperados después de la propuesta del modelo de seguridad.

• Definir los objetivos del proyecto con base a las características de formulación de objetivos SMART [137].


Diseño y desarrollo


• Identificar los componentes arquitectónicos de la plataforma Android versión 4.1 afectados por los ataques encontrados.

• Investigar acerca de la estructura y formulación de los modelos de seguridad.

• Diseñar un modelo de seguridad a partir de los ataques y principios afectados.


Demostración


• Realizar la trazabilidad de los principales ataques de seguridad en la plataforma Android versión 4.1.

• Probar el modelo para dos de los ataques de seguridad identificados frente a desarrolladores expertos.


Evaluación


• Determinar la utilidad del modelo de seguridad propuesto a partir de la retroalimentación de los desarrolladores involucrados en la fase anterior y los resultados obtenidos de esta.

• Establecer comparaciones entre el uso del modelo para identificar ataques o problemas de seguridad según componentes y la trazabilidad realizada en la arquitectura de la plataforma Android versión 4.1.

• Identificar posibles correcciones en el modelo de seguridad.


Comunicación


• Hacer una documentación sobre la investigación realizada y el modelo de seguridad, que este a disposición de la comunidad académica.

• Divulgar el trabajo realizado y los resultados obtenidos a la comunidad académica mediante un artículo científico.

En la elaboración del trabajo, se puso énfasis en la fase de diseño y desarrollo y demostración del modelo de seguridad. Al confrontar estas dos fases metodológicas, se obtuvieron resultados descritos en la siguiente sección de este artículo. Las fases metodológicas de diseño y desarrollo y demostración, se explicarán detalladamente a continuación:

FASE DE DISEÑO Y DESARROLLO:

Para cumplir con cada uno de esos objetivos se tuvieron en cuenta las siguientes actividades:

Analizar la interacción de los ataques en los componentes de la plataforma Android versión 4.1:

Para realizar esta actividad primero se desarrolló una descripción de los componentes que conforman la arquitectura (actividad desarrollada en una fase metodológica anterior a la de diseño y desarrollo) y luego se analizó la interacción de los componentes al realizar un ataque.

Con este análisis se llegó a la conclusión de que un ataque involucraría más de un componente, por ejemplo: cuando un ataque realiza un envío de un mensaje de texto premium sin consentimiento del usuario, esto no solo afecta el componente Administrador del teléfono sino el Application Sandbox al permitir la solicitud de los permisos que le proveen al ataque acceso a la información del dispositivo del usuario.

Investigar acerca de los modelos de seguridad existentes actualmente y sus características:

Esta actividad se llevó a cabo mediante una búsqueda en las principales fuentes de información del Trabajo de Grado descritas anteriormente (bases de datos, journals, blogs de seguridad, sitios web y libros de seguridad informática). La búsqueda se enfatizó en la función principal de cada modelo y la forma como mitigaban las amenazas para las cuales fueron propuestos.

La investigación realizada dio como resultado:

• MODELO DE BELL – LAPADULA [8] [7] • MODELO DE BIBA [9]

• MODELO DE CLARK – WILSON [10] • MODELO DE MURALLA CHINA [11]

A partir de los resultados obtenidos, se definieron características generales que debía tener el modelo de seguridad propuesto en el Trabajo de Grado:

• Objetivo del modelo • Principios de seguridad en los que se debía

enfatizar el modelo • Representación

Investigar acerca de la estructura y formulación un modelo de seguridad:

Esta actividad estuvo basada en la anterior y tuvo en cuenta aspectos generales a la hora de formular un modelo de seguridad como ¿Qué conforma un modelo de seguridad? ¿Cómo establecer un modelo de seguridad?,

Se partió de la definición de modelo como la expresión formal, matemática de una política de seguridad que se materializa en mecanismos de seguridad [5].

Mediante esta actividad, se analizaron los resultados obtenidos de la actividad anterior y se realizó una investigación acerca de la formulación de un modelo de seguridad, donde se encontró lo siguiente:

• Diseño de modelos de seguridad a partir de la arquitectura.

• Para que un modelo de seguridad este en los términos de los objetivos del negocio, debe tener en cuenta los riesgos, las políticas de seguridad y los grupos de interés de la organización.

A partir de esto se pudo definir el modelo que se usaría en el Trabajo, el cual tenía las siguientes características:

• Es una adaptación del modelo de seguridad a partir de la arquitectura, puesto que es un modelo para seguridad para dispositivos móviles y la mayoría de modelos de seguridad existentes se basan en organizaciones y en equipos de oficina tradicionales como por ejemplo: computadores, routers, servidores, entre otros.

• El primer componente del modelo de seguridad iba ser el objetivo, es decir lo que se quería proteger.

• El segundo componente del modelo de seguridad iban a ser las políticas de seguridad (lo que está permitido o no hacer). En este caso estas políticas de seguridad estarían regidas por la plataforma Android 4.1, que es la plataforma para la cual se realizó el modelo.

• El tercer componente del modelo de seguridad iba ser la arquitectura, basada en la arquitectura de la plataforma Android 4.1, con la adición de los principios de seguridad involucrados y los componentes que comprometen cada principio.

Desarrollo del modelo de seguridad: definir los

ataques encontrados por cada componente, sus

consecuencias y los principios que se ven afectados:

Para el desarrollo de esta actividad se tuvieron en cuenta actividades de fases anteriores como la búsqueda de información de los ataques a la plataforma, con sus descripciones y consecuencias y la información encontrada acerca de los principios que conforman la seguridad de la información.

Se clasificaron los ataques por principios de seguridad comprometidos de acuerdo a su descripción.

TIPO DE ATAQUE

ATAQUE I C D CA A NR O

BASADOS EN APLICACIÓN

ADWLAUNCHER DEVICE ADMIN

+ + + +

ANDROID.walkin + + + +

TAP LOGGER + + + +

RUFRAUD + +

LEGACY NATIVE (LENA) + + + +

TOUCH LOGGER + + + +

GEINIMI + + + +

SOUNDCOMBER + + + + +

DROIDDREAM + + +

ICALENDAR + + + + +

HONGTOUTOU + + +

CLEANEDOUT + + +

ACKPOSTS.K + + + + +

BASADOS EN WEB

NOTCOMPATIBLE + + + +

GGTracker + +

ANDROID.STELS + + + + +

ZERT SECURITY + + + + + +

CHULI (CONFERENCE) + + +

ADWARE SPAM SOLDIER + + +

BAD NEWS + + + +

Tabla 1: Tabla de clasificación de ataques

TABLA DE EQUIVALENCIAS

I INTEGRIDAD

C CONFIDENCIALIDAD

18

D DISPONIBILIDAD

CA CONTROL DE ACCESO

A AUTENTICACION

NR NO REPUDIO

O OBSERVANCIA

Tabla 2: Tabla de equivalencias

A partir de la tabla de clasificación de ataques por principios de seguridad, se obtuvo que:

• Para el Trabajo de Grado se tuvieron en cuenta 20 ataques que comprometían a la plataforma a nivel de los siete principios de seguridad de la información.

• 4 de los ataques, es decir un 20% del total, comprometen tres principios de seguridad de la información.

• Solo 2 ataques, es decir un 10% del total, comprometen menos de tres principios de seguridad de la información.

• Ningún ataque compromete menos de 2 principios de seguridad de la información.

• El 65% de los ataques encontrados, compromete más de tres principios de seguridad de la información.

• Los principios mayormente afectados por los ataques son los de: Confidencialidad (95%), Control de acceso (90%), Integridad (70%), Disponibilidad (60%).

Al final de esta actividad, se estableció el primer componente del modelo de seguridad, que era el objetivo del modelo. Este objetivo estaría enfocado a los principios de Integridad, Confidencialidad y Disponibilidad a partir de los ataques realizados.

Investigar acerca de las políticas de seguridad en la plataforma Android versión 4.1:

Esta actividad se desarrolló mediante búsquedas en blogs de seguridad y algunos artículos encontrados en las bases de datos sobre refuerzos en las políticas de seguridad que la plataforma ofrece. De esta actividad se encontró que existen políticas propias del Kernel de Linux y políticas que los usuarios pueden implementar como por ejemplo: la Administración del dispositivo, en donde una organización pueden definir políticas de uso de los dispositivos móviles.

El resultado de esta investigación llevo a definir que las políticas de seguridad existentes en la plataforma son:

• SELinux [102] • SEAndroid [138]

• Políticas de Administración del dispositivo

Desarrollo del modelo de seguridad: definir las políticas de seguridad del modelo:

Esta actividad estuvo basada en la anterior, puesto que la mayoría de políticas de un modelo de seguridad para dispositivos móviles, debe regirse a la plataforma. En este caso, luego de la investigación realizada y a la exhaustiva búsqueda de otro tipo de políticas aplicables al modelo de seguridad para dispositivos móviles, se pudo definir que:

• Las políticas que conformarían el modelo están basadas en las políticas de seguridad existentes: SELinux y SEAndroid.

Desarrollo del modelo de seguridad: elaborar la arquitectura del modelo de seguridad con componentes, ataques y principios involucrados:

Esta actividad estuvo basada en la descripción de los componentes que conforman la arquitectura de la plataforma, los ataques encontrados con su descripción y los principios involucrados en cada ataque.

Para el modelo de seguridad, se realizó una arquitectura por capas, en donde por cada capa se identificaron los problemas de Integridad, Confidencialidad y Disponibilidad de los datos y los componentes que comprometían cada uno de estos principios.

Ilustración 1: Diagrama general

La Ilustración 1 muestra el diagrama general del modelo de seguridad, en donde por cada capa se identificaron los principios de seguridad (objetivo del modelo) y los componentes que se veían comprometidos por dichos principios. Cabe resaltar que en el diagrama no se encuentran todos los componentes que conforman cada capa:

Aplicaciones, Framework de aplicación, Librerías y tiempo de ejecución Android y Kernel de Linux.

El desarrollo de la arquitectura del modelo de seguridad, solo tomo en cuenta los componentes que interactuaban cuando se comprometía alguno de los tres principios de seguridad de la información (Integridad, Confidencialidad y Disponibilidad).

A partir del diagrama establecido, el modelo de seguridad propone mecanismos y recursos de seguridad para mitigar problemas por capas basados en los tres principios mencionados anteriormente en la plataforma Android 4.1:

Ilustración 2: Capa de aplicaciones

La Ilustración 2 muestra los mecanismos de mitigación a nivel de la capa de aplicaciones propuestos por el modelo de seguridad, basado en los tres principios de seguridad de la información más importantes.

Ilustración 3: Framework de aplicación

La Ilustración 3 muestra los mecanismos de mitigación a nivel del Framework de aplicación propuestos por el modelo de seguridad, basado en los

tres principios de seguridad de la información más importantes.

Ilustración 4: Librerías / Tiempo de ejecución

Android

La Ilustración 4 muestra los mecanismos de mitigación a nivel de Librerías y tiempo de ejecución de Android propuestos por el modelo de seguridad, basado en los tres principios de seguridad de la información más importantes.

Ilustración 5: A nivel de Kernel de Linux

La Ilustración 5 muestra los mecanismos de mitigación a nivel de Kernel de Linux propuestos por el modelo de seguridad, basado en los tres principios de seguridad de la información más importantes.

FASE DE DEMOSTRACION: Para la fase de demostración, primero se escogieron tres ataques para ser probados en el modelo de seguridad propuesto, luego se realizarían pruebas funcionales de los tres ataques y al final se confrontarían los resultados encontrados por ambos.

Luego de realizar la clasificación de los ataques, mencionada anteriormente en la Tabla 1, se escogieron tres ataques para probarlos en el modelo de seguridad. Dichos ataques se tuvieron en cuenta luego de una priorización basada en tres criterios:

20

Primer criterio: los ataques tenían que comprometer los principios de alcance del Trabajo de Grado, es decir, se tuvo en cuenta ataques que involucrarán los principios de Integridad, Confidencialidad y Disponibilidad de la información.

Segundo criterio: se debe contar con información que permita la realización del ataque (procedimientos, lugar de descarga de la aplicación, entre otras cosas).

Tercer criterio: los ataques debían comprometer el mayor número de principios de seguridad de la información dentro de su clasificación, en donde tres de esos principios debían ser los mencionados en el primer criterio.

A partir de esto, se establecieron los criterios por cada clasificación:

TIPO DE ATAQUE

ATAQUE PRIMER CRITERIO

SEGUNDO CRITERIO

TERCER CRITERIO

BASADOS EN APLICACION

SOUNDCOMBER + - +

ICALENDAR + + +

ACKPOSTS.K + - +

Tabla 3: Priorización de la primera clase de ataques

TIPO DE ATAQUE


SEGUNDO CRITERIO

TERCER CRITERIO

BASADOS EN WEB

ZERT SECURITY + - +

ANDROID.STELS + + -

Tabla 4: Priorización de la segunda clase de ataques

TIPO DE ATAQUE


SEGUNDO CRITERIO

TERCER CRITERIO

ADWARE

SPAM SOLDIER

- + -

BAD NEWS + + +

Tabla 5: Priorización de la tercera clase de ataques

Por medio de esto, se definieron los tres ataques para el proceso de pruebas funcionales y confrontación con el modelo de seguridad:

TIPO DE ATAQUE ATAQUE

BASADOS EN APLICACIÓN

iCalendar

BASADOS EN WEB Android.Stels

ADWARE BadNews

Tabla 6: Ataques escogidos para las pruebas funcionales y del modelo

La fase de demostración, abarcaba además, las pruebas del modelo de seguridad y las pruebas funcionales de los ataques, descritas a continuación:

PRUEBAS DEL MODELO DE SEGURIDAD:

Después de escoger los ataques, se probó el modelo y se obtuvo como resultado:

Para el primer ataque iCalendar, el modelo de seguridad identificó los componentes: SMS/MMS – TELEPHONY MANAGER – LOCATION MANAGER – APPLICATION SANDBOX – WIFI DRIVER (ver Ilustración 6).

Ilustración 6: Prueba del ataque iCalendar en el modelo de seguridad

Para el segundo ataque Android.stels, el modelo de seguridad identificó los componentes: PACKAGE MANAGER – CONTACTOS – LIBWEBCORE – TELEPHONY MANAGER – WIFI DRIVER – SMS/MMS – APPLICATION SANDBOX (ver Ilustración 7).

Ilustración 7: Prueba del ataque Android.stels en el modelo de seguridad

Para el tercer ataque BadNews, el modelo de seguridad identificó los componentes: PACKAGE MANAGER – TELEPHONY MANAGER – WIFI

DRIVER – EMAIL – HOME - APPLICATION SANDBOX (ver Ilustración 8).

Ilustración 8: Prueba del ataque BadNews en el modelo de seguridad

PRUEBAS FUNCIONALES:

Para realizar esta actividad se usaron las herramientas: Dex2jar, JD-GUI (Java decompiler), AndroidAssistant, Winzip y el dispositivo móvil provisto por la Pontificia Universidad Javeriana, el cual tenía las siguientes características:

• Modelo: SAMSUNG galaxy NEXUS S • Versión de Android: Sistema Operativo

Android 4.1.1 JellyBean (se actualizó el sistema operativo del dispositivo)

• Versión de banda base: I9020AUCKJ1 • Versión de núcleo: 3.0.8 –g6656123 android –

build@vpbs1 #1 • Numero de compilación: IMM76D • Memoria: 16GB, 512 MB de RAM

Las pruebas del primer ataque iCalendar, demostraron lo siguiente:

• La aplicación envía un MENSAJE DE TEXTO a un número de mensajería premium ubicado en China sin el consentimiento del usuario y luego deja de funcionar.

• La aplicación bloquea cualquier intento de respuesta para que el usuario no se dé cuenta que está enviando el mensaje.

• La aplicación además solicita permisos de: ubicación, mensajes, comunicación de red, espacio de almacenamiento, llamadas telefónicas y envío de mensajes de texto.

• La aplicación se sigue ejecutando aun después de haber sido finalizada su ejecución.

Las pruebas del segundo ataque Android.stels, demostraron lo siguiente:

• La aplicación es descargada de una página web consultada desde el dispositivo y se hace pasar por un programa legítimo (Adobe Flash Player).

• Para su instalación, la aplicación solicita permisos de: mensajes, información personal, comunicación de red, espacio de almacenamiento, servicios que cuestan dinero y llamadas telefónicas.

• Después de que se instala y ejecuta, la aplicación deja de funcionar, pero sigue consumiendo recursos en el dispositivo.

• La aplicación no se encuentra dentro del dispositivo junto a las demás aplicaciones instaladas (no aparece el icono de la aplicación).

• Luego de la primera vez que se ejecuta, la aplicación abre el navegador del dispositivo con la página web del servidor remoto del cual recibe comandos. Dicha página no puede ser vista desde el dispositivo infectado.

• La aplicación elimina todos los contactos existentes del dispositivo.

Las pruebas del tercer ataque BadNews, demostraron lo siguiente:

• Las aplicaciones live.photo.savanna y SavageKnife, se descargan en el dispositivo como aplicaciones de protector de pantalla y de juego respectivamente.

• Para su instalación, la aplicación live.photo.savanna solicita permisos de: espacio de almacenamiento, comunicación de red, llamadas telefónicas, herramientas del sistema (alertas), estado de la red, controles de hardware, herramientas del sistema (ejecutar automáticamente al iniciar e instalar accesos directos).

• La aplicación no aparece junto a las demás aplicaciones instaladas en el dispositivo.

• Para ejecutar la aplicación se debe cambiar el fondo de pantalla del dispositivo.

• Después de cambiar el fondo de pantalla del dispositivo, la aplicación ejecuta procesos sin el consentimiento del usuario.

• Luego de la revisión de código, se detectó que la aplicación envía datos del dispositivo a un servidor remoto. Los datos que envía la información son: el identificador, el operador de telefonía, el modelo del dispositivo, el lenguaje y la información de las aplicaciones instaladas en el dispositivo.

• La instalación de la segunda aplicación: SavageKnife, solicita los siguientes permisos: espacio de almacenamiento, comunicación de red, llamadas telefónicas, herramientas del sistema (inactividad del dispositivo), estado de la red, controles de hardware, herramientas del sistema (ejecutar automáticamente al iniciar,

22

eliminar procesos de fondo e instalar accesos directos).

• La aplicación muestra publicidad en el dispositivo después de la primera vez que se ejecuta o se juega.

• Desde ese momento, cuando se ejecuta cualquier otra aplicación, se sigue mostrando publicidad.

• La aplicación ejecuta Gmail [139] para enviar a la persona un correo electrónico con archivos adjuntos que aparentemente son spam.

FASE DE EVALUACION:

Para cumplir con esta fase metodológica se desarrolló una actividad la cual no estaba contemplada dentro de las establecidas al inicio del trabajo y dentro de la metodología que se propuso. Asimismo, no se pudieron desarrollar algunas actividades establecidas para esta fase metodológica, por motivos explicados en la siguiente sección del presente artículo.

Para la elaboración de esta fase, se usó la lista de chequeo Construx Software para arquitectura [140] que se modificó para que estuviera enfocada al Trabajo de investigación realizado.

5 Resultados obtenidos La confrontación de resultados entre las pruebas realizadas en el dispositivo móvil y las pruebas de identificación de componentes por parte del modelo de seguridad produjeron lo siguiente:

Para el primer ataque iCalendar, el modelo de seguridad no tuvo en cuenta un aspecto del ataque, los demás, fueron identificados correctamente. De los seis aspectos más importantes que se demostró que caracterizaban el ataque iCalendar, el modelo identificó cinco de estos correctamente (ver Tabla 7).

ATAQUE MODELO DE SEGURIDAD

Envío de mensaje de texto a numero premium

SMS/MMS

TELEPHONY MANAGER

Solicitud de permiso de ubicación

APPLICATION SANDBOX

LOCATION MANAGER

Solicitud de permiso de mensajes

APPLICATION SANDBOX

TELEPHONY MANAGER

SMS/MMS

Solicitud de permiso de comunicación de red

APPLICATION SANDBOX

WIFI DRIVER

Solicitud de llamadas telefónicas

APPLICATION SANDBOX

TELEPHONY MANAGER

Ejecución después de cerrar aplicación

¿?

Tabla 7: Confrontación del ataque iCalendar

Para el segundo ataque Android.stels, el modelo de seguridad no tuvo en cuenta dos aspectos del ataque, los demás, fueron identificados correctamente. De los once aspectos más importantes que se demostró que caracterizaban el ataque Android.stels, el modelo identifico nueve de estos correctamente (ver Tabla 8).


Descarga de aplicación de una página web desde el

dispositivo

LIBWEBCORE

WIFI DRIVER

Solicitud de permiso de mensajes

APPLICATION SANDBOX

TELEPHONY MANAGER

SMS/MMS

Solicitud de permiso de información personal

APPLICATION SANDBOX

TELEPHONY MANAGER

CONTACTOS


APPLICATION SANDBOX

WIFI DRIVER

Solicitud de permiso de espacio de almacenamiento

¿?

Servicios que cuestan dinero

APPLICATION SANDBOX

TELEPHONY MANAGER

SMS/MMS

Solicitud de permiso de llamadas telefónicas

APPLICATION SANDBOX

TELEPHONY MANAGER

La aplicación sigue consumiendo recursos en el

dispositivo

¿?

La aplicación no aparece junto a las demás aplicaciones

instaladas

PACKAGE MANAGER

La aplicación abre el navegador del dispositivo con

la página web del servidor remoto

LIBWEBCORE

WIFI DRIVER

Eliminación de los contactos TELEPHONY MANAGER

del dispositivo CONTACTOS

Tabla 8: Confrontación del ataque Android.stels

Para el tercer ataque BadNews, el modelo de seguridad no tuvo en cuenta cinco aspectos del ataque, los demás, fueron identificados correctamente. De los trece aspectos más importantes que se demostró que caracterizaban al ataque BadNews, el modelo identifico nueve de estos correctamente (ver Tabla 9).


Solicitud de permiso de espacio de almacenamiento

¿?


APPLICATION SANDBOX

WIFI DRIVER

Solicitud de permiso de llamadas telefónicas

APPLICATION SANDBOX

TELEPHONY MANAGER

Solicitud de permiso de herramientas del sistema

(alertas)

¿?

Solicitud de permiso de controles de hardware

¿?

Solicitud de permiso herramientas del sistema (ejecución automática al iniciar e instalar accesos

directos)

APPLICATION SANDBOX

HOME

La aplicación no aparece junto a las demás aplicaciones

instaladas

PACKAGE MANAGER

La aplicación ejecuta procesos sin el consentimiento del

usuario

¿?

Envío de datos del dispositivo a un servidor remoto

WIFI DRIVER

TELEPHONY MANAGER

PACKAGE MANAGER

Solicitud de permiso herramientas del sistema

(inactividad del dispositivo)

¿?

Solicitud de permiso estado de la red

APPLICATION SANDBOX

WIFI DRIVER

Publicidad en el dispositivo HOME

PACKAGE MANAGER

Ejecución de Gmail para PACKAGE MANAGER

envío de correo electrónico WIFI DRIVER

EMAIL

Tabla 9:Confrontación del ataque BadNews

Mediante un análisis de las tablas 7, 8 y 9, se pudo determinar que:

• Dependiendo del comportamiento de los ataques, el modelo identifica los componentes que comprometen Integridad, Confidencialidad y Disponibilidad de la información.

• Cada ataque puede comprometer el mismo componente basado en un diferente principio.

• En los tres ataques se comprometió el componente Application Sandbox, algo que se esperaba puesto que dicho componente es el encargado de manejar los permisos en la plataforma.

• En los tres ataques se comprometió el componente Telephony Manager, lo que evidencia que la mayoría de ataques en la plataforma Android afecta la información personal del usuario.

• El componente WiFi Driver es común en los tres ataques, lo cual demuestra la falta de niveles de seguridad por parte de la plataforma hacia este componente.

• Tanto las amenazas basadas en web, como las amenazas de aplicación y los adware se originan muchas veces por la falta de información de uso correcto del dispositivo por parte del usuario.

Luego de analizar los resultados de la confrontación entre ataques y modelo de seguridad, se realizaron las sugerencias de posibles mitigaciones a los ataques encontrados por parte del modelo de seguridad, donde se estableció lo siguiente:

Para mitigar el ataque iCalendar, el modelo propone a nivel de capas que se tenga en cuenta: En la capa más baja de Kernel de Linux: • Denegación de permisos que no sean necesarios

al momento de instalación de la aplicación por parte del Application Sandbox [58].

En la capa del Framework de aplicaciones: • Denegación de permisos de “Llamadas

telefónicas”, “Tus mensajes” y “Estado actual del teléfono”, cuando la aplicación los solicite.

• Denegación del permiso “Tu ubicación” cuando la aplicación lo solicite.

• Desactivar opción de “Usar satélites GPS”, por parte del dispositivo cuando se esté usando la aplicación.

En la capa de aplicaciones: • Uso de políticas dinámicas SELinux [102], para

cambiar en tiempo de ejecución los modos

24

permisivos del dispositivo con respecto a las solicitudes que realiza la aplicación.

Para mitigar el ataque Android.stels, el modelo propone a nivel de capas que se tenga en cuenta: En la capa más baja de Kernel de Linux: • Conexión solo a redes con seguridad Wifi

Protegida (WPA o WPA2) [141] [142]. En la capa de librerías / tiempo de ejecución Android: • Deshabilitar la opción de “Recordar claves” en el

dispositivo, para que el navegador no las recuerde.

• Sitios web con certificado HTTPS [69] [68] [143] (acceder solo a sitios web con certificado HTTPS desde el dispositivo).

• Habilitar la opción de “Mostrar advertencias de Seguridad” en el navegador del dispositivo, cuando se abran páginas web.

En la capa de Framework de aplicaciones: • Remover servicios de aplicaciones innecesarios

mediante un asistente para procesos y servicios (aplicación).

En la capa de aplicaciones: • Denegar permisos de lectura de información del

teléfono (en donde se pueda obtener información por ejemplo: de los contactos del dispositivo).

Para mitigar el ataque BadNews, el modelo propone a nivel de capas que se tenga en cuenta: En la capa de Framework de aplicaciones: • Denegación de permisos de “Llamadas

telefónicas”, “Tus mensajes” y “Estado actual del teléfono”, cuando la aplicación los solicite.

En la capa de aplicaciones: • Configurar el servidor de correos para bloquear o

remover correos que contengan archivos adjuntos que se usan generalmente para lanzar amenazas.

Después de realizar las sugerencias de mitigación, se evaluó el modelo con base en la lista de chequeo Construx Software para arquitectura [140], descrita en la siguiente Ilustración:

Ilustración 9: Lista de chequeo para evaluar el

modelo de seguridad

Luego de evaluar la arquitectura del modelo de seguridad, se identificó lo siguiente:

• La arquitectura cumple con una adecuada visión del sistema, puesto que permite ver la diferencia de capas y de componentes en cada capa.

• La arquitectura cumple con una organización y una vista general concisa del sistema puesto que especifica dentro de cada capa los componentes comprometidos por los principios de Integridad, Confidencialidad y Disponibilidad.

• La arquitectura está diseñada para acomodarse a cambios, puesto que se pueden agregar nuevos principios a tener en cuenta en el modelo o nuevos componentes en cada capa.

• Los elementos de la arquitectura están claramente representados puesto que están representados como componentes y capas.

• La arquitectura puede ser implementada para el ambiente objetivo, puesto que está basada en la arquitectura de la plataforma Android 4.1 y el uso del modelo de seguridad tiene como alcance solo dispositivos móviles bajo esta plataforma.

• La arquitectura hace una diferencia entre las capas que la componen: Aplicaciones, Framework de aplicación, Librerías y tiempo de ejecución de Android y Kernel de Linux.

• La arquitectura cumple con la distribución por capas.

• La arquitectura tiene buena cohesión pues permite identificar componentes comprometidos fácilmente y es coherente en cuanto a los principios y componentes identificados.

• La arquitectura tiene deficiencias en cuanto a diseño porque no es independiente de la tecnología que se usa para implementarla. La

arquitectura del modelo de seguridad está enfocada a la plataforma Android.

• La arquitectura no cumple con una estrategia de manejo de errores, puesto que está orientada a identificar componentes comprometidos para luego sugerir una posible mitigación de estos.

• La arquitectura cumple con soportar la metodología que se estableció para el desarrollo del proyecto (Investigación basada en el Diseño), pues es parte de un modelo de seguridad, el cual genera conocimiento en la comunidad académica.

• Los objetivos del sistema están indicados claramente pues el modelo de seguridad se compone de objetivos, políticas y de la arquitectura realizada.

6 Opiniones personales Los cambios realizados sobre las actividades de las fases metodológicas de Demostración y Evaluación del trabajo se debieron en gran medida a la falta de información acerca de los ataques a la plataforma y la falta de tiempo para la realización de la investigación.

Los diferentes temas que existen para la línea de conocimiento de este Trabajo son muy extensos y muy interesantes. Muchos de estos temas además son nuevos y generan un reto en el estudiante, puesto que la mayoría de la información y documentación no se encuentra en libros sino en Internet (congresos de seguridad, blogs, revistas, entre otros).

Se recomienda este tema de investigación a los estudiantes que vayan a realizar su Trabajo de Grado, puesto que la cantidad de información que se genera a partir de este tema es casi incremental. Los ataques a la seguridad de la información se incrementan a medida que la tecnología cambia y cada día se genera conocimiento en este tema.

7 Conclusiones y trabajo futuro Como conclusiones se logró establecer lo siguiente:

• La aproximación de identificación de componentes que interactúan a la hora de realizar los ataques propuestos para el modelo de seguridad es apropiada, pero hay algunos elementos que no fueron tomados en cuenta por el mismo.

• El modelo de seguridad propuesto puede ser usado para identificar posibles problemas futuros con respecto a la Integridad, Confidencialidad y Disponibilidad en la plataforma.

• El modelo de seguridad propuesto sirve como base para la elaboración de nuevos

• componentes y nuevos mecanismos de seguridad que deben ser implementados en la

• plataforma para lograr mitigar las amenazas en los componentes que este identificó.

• La confrontación realizada entre el modelo de seguridad y las pruebas funcionales permite establecer el nivel de confianza que se puede tener del modelo de seguridad a la hora de identificar componentes de la arquitectura que comprometen los principios de Integridad, Confidencialidad y Disponibilidad.

• El modelo de seguridad propuesto tuvo propuesto tuvo fallas en la identificación de componentes en algunos casos porque el comportamiento de los ataques puede variar dependiendo del modelo del dispositivo móvil en que se pruebe y la configuración que se tenga del dispositivo.

• Algunos de los ataques que se tuvieron en cuenta en la investigación, pueden reducir su impacto en el dispositivo del usuario, si se usa de manera “correcta” dicho dispositivo

• Los ataques escogidos para las pruebas fueron de gran ayuda pues comprometían los principios más importantes de la seguridad de la información y porque contemplaban aspectos que el modelo de seguridad no tomaba en cuenta

• Gracias a la investigación realizada en este Trabajo de Grado, se pudo determinar que la mayoría de ataques que se realizan a la plataforma Android, comprometen los tres principios más importantes de la seguridad de la información

• Se puedo comprobar que a nivel de la plataforma, Android posee muchas vulnerabilidades en cuanto a permisos y mecanismos de seguridad.

• Los mecanismos de seguridad propuestos por el modelo de seguridad deben ser probados para determinar en qué porcentaje se mitigan los ataques a la plataforma

• Se pudo demostrar por medio de este modelo, que existe más de un principio de seguridad comprometido por cada componente de la arquitectura de la plataforma Android 4.1.

• El modelo de seguridad propone recursos en cada componente para la mitigación de ataques que comprometan la Integridad, Confidencialidad y Disponibilidad de la

26

información a partir de mecanismos de seguridad existentes en la arquitectura y de otros mecanismos que no existen, pero que se sugieren como un cambio en el siguiente versionamiento de la plataforma y que podrían ayudar a solucionar los problemas de seguridad identificados por el modelo.

Como trabajo futuro al presente trabajo de investigación, se propone:

• La elaboración de componentes adicionales que se puedan integrar a la arquitectura del modelo de seguridad propuesto y que mitiguen los ataques encontrados en la investigación.

• Desarrollos de software teniendo como base el modelo de seguridad para mejorar el modelo de permisos de Android y evitar que las amenaces encontradas se presenten en los dispositivos.

• Manuales para el desarrollo de aplicaciones en Android teniendo en cuenta los principios de seguridad identificados en el modelo y los componentes que interactúan cuando se comprometen esos principios.

• Desarrollo de nuevas políticas de seguridad que se puedan implementar en las versiones futuras de la plataforma Android y que disminuyan las amenazas en los dispositivos móviles.

Referencias

[1] H. McCracken, “Who’s Winning, iOS or Android? All the Numbers, All in One Place,” Time.

[2] “Android outscores iOS in U.S. smartphone sales, says report | Mobile - CNET News.” [Online]. Available: http://news.cnet.com/8301-1035_3-57577431-94/android-outscores-ios-in-u.s-smartphone-sales-says-report/. [Accessed: 26-Apr-2013].

[3] N. Hari and B. Prasad, “Android architecture.” [Online]. Available: http://www.slideshare.net/kittu565/android-architecture. [Accessed: 13-May-2013].

[4] “Modelo de seguridad.” [Online]. Available: https://www.ccn-cert.cni.es/publico/serieCCN-STIC401/es/m/security_model.htm. [Accessed: 17-Nov-2012].

[5] S. M. Bonilla and J. A. Gonzalez, “MODELO DE SEGURIDAD DE LA

INFORMACION,” vol. 3, pp. 6–14, Jan. 2012.

[6] “ESET Latinoamérica – Laboratorio » Blog Archive » Cómo implementar modelos de seguridad de la información.” [Online]. Available: http://blogs.eset-la.com/laboratorio/2012/08/22/como-implementar-modelos-seguridad-informacion/. [Accessed: 28-Nov-2012].

[7] L. Lapadula, “Secure Computer Systems: Mathematical Foundations.” 1996.

[8] “Bell LaPadula Model.” [Online]. Available: http://www.cs.unc.edu/~dewan/242/f96/notes/prot/node13.html. [Accessed: 20-Nov-2012].

[9] N. Balon and I. Thabet, “The Biba Security Model.” 2004.

[10] “Bell-La Padula, Biba and Clark-Wilson Security Models « commondork.” [Online]. Available: http://www.commondork.com/2010/05/16/bell-la-padula-biba-and-clark-wilson-security-models/. [Accessed: 28-Nov-2012].

[11] “The Chinese Wall security policy.” [Online]. Available: http://www.gammassl.co.uk/topics/chinesewall.html. [Accessed: 28-Nov-2012].

[12] “NCSC-TG-003 A GUIDE TO UNDERSTANDING DISCRETIONARY ACCESS CONTROL IN TRUSTED SYSTEMS 30 September 1987.” [Online]. Available: https://www.fas.org/irp/nsa/rainbow/tg003.htm. [Accessed: 18-Jun-2013].

[13] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman, “Role-Based Access Control Models.” IEEE Computer, 1996.

[14] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli, “Proposed NIST standard for role-based access control,” Acm Trans Inf Syst Secur, vol. 4, no. 3, pp. 224–274, Aug. 2001.

[15] “Android Under Siege: Popularity Comes at a Price.” TREND MICRO, 2012.

[16] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang, “Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets.” North Carolina State University, 2012.

[17] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A Survey of Mobile Malware in the Wild.” University of California, Berkeley, 2011.

[18] “WhatsApp  :: Home,” WhatsApp.com. [Online]. Available: http://www.whatsapp.com/?l=es. [Accessed: 18-Nov-2012].

[19] “Update: RuFraud: European Premium SMS Toll Fraud on the Rise | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2011/12/11/european-premium-sms-fraud/. [Accessed: 18-Nov-2012].

[20] “What is piggybacking? - Definition from WhatIs.com.” [Online]. Available: http://whatis.techtarget.com/definition/piggybacking. [Accessed: 18-Nov-2012].

[21] “State of Mobile Security 2012.” [Online]. Available: https://www.lookout.com/resources/reports/state-of-mobile-security-2012. [Accessed: 19-Nov-2012].

[22] “Walk and Text-Transparent - Aplicaciones de Android en Google Play.” [Online]. Available: https://play.google.com/store/apps/details?id=com.incorporateapps.walktext&hl=es. [Accessed: 15-Nov-2012].

[23] “Android.Walkinwat | Symantec.” [Online]. Available: http://www.symantec.com/security_response/writeup.jsp?docid=2011-033008-4831-99. [Accessed: 15-Nov-2012].

[24] “Walk and Text, otra aplicación Android con versión troyana.” [Online]. Available: http://www.idg.es/pcworldtech/mostrarNoticia.asp?id=108190&seccion=actualidad. [Accessed: 17-Nov-2012].

[25] “Android.Adwlauncher Technical Details | Symantec.” [Online]. Available: http://www.symantec.com/security_respo

nse/writeup.jsp?docid=2012-082308-1823-99&tabid=2. [Accessed: 18-Nov-2012].

[26] “iOS: A visual history,” The Verge. [Online]. Available: http://www.theverge.com/2011/12/13/2612736/ios-history-iphone-ipad. [Accessed: 07-Apr-2013].

[27] Z. Xu, K. Bai, and S. Zhu, “TapLogger: inferring user inputs on smartphone touchscreens using on-board motion sensors,” in Proceedings of the fifth ACM conference on Security and Privacy in Wireless and Mobile Networks, New York, NY, USA, 2012, pp. 113–124.

[28] “Kaspersky Lab US | Antivirus & Internet Security Protection Software.” [Online]. Available: http://usa.kaspersky.com/. [Accessed: 07-Apr-2013].

[29] “Security Alert: CleanedOut | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2013/02/07/security-alert-cleanedout/. [Accessed: 05-Apr-2013].

[30] L. Cai and H. Chen, “TouchLogger: Inferring Keystrokes On Touch Screen From Smartphone Motion.” University of California.

[31] “Security Alert: HongTouTou, New Android Trojan, Found in China | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2011/02/15/security-alert-hongtoutou-new-android-trojan-found-in-china/. [Accessed: 05-Apr-2013].

[32] “Security Alert: Geinimi, Sophisticated New Android Trojan Found in Wild | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2010/12/29/geinimi_trojan/. [Accessed: 20-Mar-2013].

[33] K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang, “Soundcomber: A Stealthy and Context-Aware Sound Trojan for Smartphones.” Indiana University Bloomington, 2011.

28

[34] S. Bugiel, L. Davi, A. Dmitrienko, and T. Fischer, “Towards Taming Privilege-Escalation Attacks on Android.” Fraunhofer SIT, Darmstadt, Germany, 2012.

[35] C. Marforio, H. Ritzdorf, A. Francillon, and S. Capkun, “Analysis of the Communication between Colluding Applications on Modern Smartphones.” 2012.

[36] “DroidDream Becomes Android Market Nightmare | PCWorld.” [Online]. Available: http://www.pcworld.com/article/221247/droiddream_becomes_android_market_nightmare.html. [Accessed: 22-Mar-2013].

[37] “Droid Dream Light: un nuevo virus infecta 25 ‘apps’ de Android | Navegante | elmundo.es.”[Online]. Available: http://www.elmundo.es/elmundo/2011/06/01/navegante/1306923142.html. [Accessed: 22-Mar-2013].

[38] “Sibling Rivalry: The Ackposts Family. | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2013/04/10/sibling-rivalry-the-ackposts-family/. [Accessed: 08-Apr-2013].

[39] “UPDATE: Security Alert: Android Trojan GGTracker Charges Premium Rate SMS Messages | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2011/06/20/security-alert-android-trojan-ggtracker-charges-victims-premium-rate-sms-messages/. [Accessed: 18-Nov-2012].

[40] “Aplicaciones de Android en Google Play.” [Online]. Available: https://play.google.com/store. [Accessed: 18-Nov-2012].

[41] “Android.Stels | Symantec.” [Online]. Available: http://www.symantec.com/security_response/writeup.jsp?docid=2013-032910-0254-99. [Accessed: 06-Apr-2013].

[42] “Adobe - Instalación de Adobe Flash Player.” [Online]. Available: http://get.adobe.com/es/flashplayer/. [Accessed: 06-Apr-2013].

[43] “ZertSecurity | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2013/05/06/zertsecurity/. [Accessed: 08-Apr-2013].

[44] “Postbank: Willkommen auf der Startseite. Kostenloses Girokonto, günstiger Kredit, Angebote für Sparen und Anlegen - und vieles mehr!” [Online]. Available: https://www.postbank.de/. [Accessed: 08-Apr-2013].

[45] “Mission Statement of the WUC » World Uyghur Congress,” World Uyghur Congress -. [Online]. Available: http://www.uyghurcongress.org/en/?cat=150. [Accessed: 08-Apr-2013].

[46] “To Tibet, with Love | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2013/03/28/to-tibet-with-love/. [Accessed: 08-Apr-2013].

[47] M. C. Grace, W. Zhou, X. Jiang, and A.-R. Sadeghi, “Unsafe exposure analysis of mobile in-app advertisements,” in Proceedings of the fifth ACM conference on Security and Privacy in Wireless and Mobile Networks, New York, NY, USA, 2012, pp. 101–112.

[48] “The Bearer of BadNews | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2013/04/19/the-bearer-of-badnews-malware-google-play/. [Accessed: 08-Apr-2013].

[49] “92598: Live Wallpaper - Savannah for Android (live.photo.savanna) Trojaned Distribution.” [Online]. Available: http://www.osvdb.org/show/osvdb/92598. [Accessed: 27-Apr-2013].

[50] “need for speed free - Google Play.” [Online]. Available: https://play.google.com/store/search?q=need+for+speed+free&c=apps. [Accessed: 08-Apr-2013].

[51] “Angry Birds Space - Aplicaciones Android en Google Play.” [Online]. Available: https://play.google.com/store/apps/details?id=com.rovio.angrybirdsspace.ads&feature=search_result#?t=W251bGwsMSwxLDEsImNvbS5yb3Zpby5hbmdyeWJpcm

Rzc3BhY2UuYWRzIl0. [Accessed: 08-Apr-2013].

[52] “Security Alert: SpamSoldier | The Official Lookout Blog.” [Online]. Available: https://blog.lookout.com/blog/2012/12/17/security-alert-spamsoldier/. [Accessed: 08-Apr-2013].

[53] “What is ASLR?” [Online]. Available: http://netsecurity.about.com/od/quicktips/qt/whatisaslr.htm. [Accessed: 09-Mar-2013].

[54] “X.Org Wiki - ProPolice.” [Online]. Available: http://www.x.org/wiki/ProPolice. [Accessed: 09-Mar-2013].

[55] “README - safe-iop - safe_iop - a safe integer operation library for C - Safe Integer Operation Library for C - Google Project Hosting.” [Online]. Available: https://code.google.com/p/safe-iop/wiki/README. [Accessed: 09-Mar-2013].

[56] “Take a closer look at OpenBSD.” [Online]. Available: http://www.ibm.com/developerworks/aix/library/au-openbsd.html. [Accessed: 10-Mar-2013].

[57] “mmap_min_addr - Debian Wiki.” [Online]. Available: http://wiki.debian.org/mmap_min_addr. [Accessed: 10-Mar-2013].

[58] “Android Security Overview | Android Open Source.” [Online]. Available: http://source.android.com/tech/security/index.html. [Accessed: 18-Feb-2013].

[59] “How To Boot Into Android Safe Mode On Your Smartphone / Tablet | Redmond Pie.” [Online]. Available: http://www.redmondpie.com/how-to-boot-into-android-safe-mode-on-your-smartphone-tablet/. [Accessed: 12-Mar-2013].

[60] “Use Android’s ‘Safe Mode’ to Disable Apps and Troubleshoot Problems.”[Online]. Available: http://lifehacker.com/5965022/how-to-reboot-your-android-phone-or-tablet-

into-safe-mode. [Accessed: 12-Mar-2013].

[61] D. Osvik, A. Shamir, and E. Tromer, “Cache Attacks and Countermeasures: the Case of AES.” Weizmann Institute of Science and Applied Mathematics, 20-Nov-2005.

[62] D. Boneh, “Twenty years of attacks on the RSA cryptosystem.” 1998.

[63] D. Pointcheval, “How to Encrypt Properly with RSA.” 2002.

[64] “FIPS 186 - (DSS), Digital Signature Standard.” [Online]. Available: http://www.itl.nist.gov/fipspubs/fip186.htm. [Accessed: 12-Mar-2013].

[65] “Digest::SHA - search.cpan.org.” [Online]. Available: http://search.cpan.org/~mshelor/Digest-SHA-5.62/lib/Digest/SHA.pm. [Accessed: 13-Mar-2013].

[66] “Unix crypt with SHA-256/512.” [Online]. Available: http://www.akkadia.org/drepper/sha-crypt.html. [Accessed: 13-Mar-2013].

[67] “RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2.” [Online]. Available: https://tools.ietf.org/html/rfc5246. [Accessed: 13-Mar-2013].

[68] “HTTPS Security Improvements in Internet Explorer 7.” [Online]. Available: http://msdn.microsoft.com/en-us/library/bb250503.aspx. [Accessed: 13-Mar-2013].

[69] “RFC 2818 - HTTP Over TLS.” [Online]. Available: http://tools.ietf.org/html/rfc2818. [Accessed: 13-Mar-2013].

[70] “KeyChain | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/security/KeyChain.html. [Accessed: 13-Mar-2013].

[71] “CWE - CWE-415: Double Free (2.4).” [Online]. Available: http://cwe.mitre.org/data/definitions/415.html. [Accessed: 13-Mar-2013].

30

[72] “Double Free - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Double_Free. [Accessed: 13-Mar-2013].

[73] “Using freed memory - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Using_freed_memory. [Accessed: 15-Mar-2013].

[74] “13.5 Heap Overflows :: Chapter 13. Application-Level Risks :: Network security assessment :: Networking :: eTutorials.org.” [Online]. Available: http://etutorials.org/Networking/network+security+assessment/Chapter+13.+Application-Level+Risks/13.5+Heap+Overflows/. [Accessed: 15-Mar-2013].

[75] “CWE - CWE-134: Uncontrolled Format String (2.4).” [Online]. Available: http://cwe.mitre.org/data/definitions/134.html. [Accessed: 15-Mar-2013].

[76] “Gentoo Linux Documentation -- Position Independent Code internals.” [Online]. Available: http://www.gentoo.org/proj/en/hardened/pic-internals.xml. [Accessed: 15-Mar-2013].

[77] “2.6. Position Independent Executables.” [Online]. Available: http://linuxfromscratch.xtra-net.org/hlfs/view/unstable/glibc-2.4/chapter02/pie.html. [Accessed: 15-Mar-2013].

[78] “Enabling the kernel’s DMESG_RESTRICT feature.” [Online]. Available: https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033240.html. [Accessed: 16-Mar-2013].

[79] “FORTIFY_SOURCE Semantics | NYU Poly ISIS Lab.” [Online]. Available: https://isisblogs.poly.edu/2011/04/11/fortify_source-semantics/. [Accessed: 15-Mar-2013].

[80] “Brute force attack - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Brute_force_attack. [Accessed: 16-Mar-2013].

[81] “Testing for Brute Force (OWASP-AT-004) - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Testing_for_Brute_Force_(OWASP-AT-004). [Accessed: 16-Mar-2013].

[82] “RFC 6070 - PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors.” [Online]. Available: http://tools.ietf.org/html/rfc6070. [Accessed: 16-Mar-2013].

[83] “Using password systems - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Using_password_systems. [Accessed: 16-Mar-2013].

[84] “Virtual Private Networking: An Overview.” [Online]. Available: http://technet.microsoft.com/en-us/library/bb742566.aspx. [Accessed: 18-Mar-2013].

[85] “VPN Technologies: Definitions and Requirements.” [Online]. Available: http://www.vpnc.org/vpn-technologies.html. [Accessed: 19-Mar-2013].

[86] “RFC 2637 - Point-to-Point Tunneling Protocol (PPTP).” [Online]. Available: http://tools.ietf.org/html/rfc2637. [Accessed: 19-Mar-2013].

[87] “RFC 2661 - Layer Two Tunneling Protocol ‘L2TP’.”[Online]. Available: http://tools.ietf.org/html/rfc2661. [Accessed: 19-Mar-2013].

[88] “VpnService | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/net/VpnService.html. [Accessed: 17-Mar-2013].

[89] “SMS Tutorial: Introduction to AT Commands, Basic Commands and Extended Commands.” [Online]. Available: http://www.developershome.com/sms/atCommandsIntro.asp. [Accessed: 18-Mar-2013].

[90] “Android - Radio Layer Interface.” [Online]. Available: http://www.netmite.com/android/mydroid

/development/pdk/docs/telephony.html. [Accessed: 18-Mar-2013].

[91] “Company – Google.” [Online]. Available: http://www.google.com/about/company/. [Accessed: 18-Mar-2013].

[92] R. Gonzalez and A. Pomares, “LA INVESTIGACIÓN CIENTÍFICA BASADA EN EL DISEÑO COMO EJE DE PROYECTOS DE INVESTIGACIÓN EN INGENIERÍA.” Pontificia Universidad Javeriana - Bogotá, Colombia, 2012.

[93] M. Whitman and H. Mattord, Principles of Information Security, 4th ed. Course Technology, 2011.

[94] “What is ‘Information Security’.”[Online]. Available: http://security.practitioner.com/introduction/infosec_2.htm. [Accessed: 18-Mar-2013].

[95] D. Knuth, Sorting and Searching, Second., vol. 3. Massachusetts: Addison-Wesley, 1998.

[96] G. Stoneburner, C. Hayden, and A. Feringa, “Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A,” Natl. Inst. Stand. Technol. Nist, no. COMPUTER SECURITY, p. 33, Jun. 2004.

[97] “Descripción del cifrado simétrico y asimétrico.” [Online]. Available: http://support.microsoft.com/kb/246071/es. [Accessed: 18-Nov-2012].

[98] “Managing Authorization and Access Control.” [Online]. Available: http://technet.microsoft.com/en-us/library/bb457115.aspx. [Accessed: 18-Nov-2012].

[99] “SolutionBase: Strengthen network defenses by using a DMZ | TechRepublic.” [Online]. Available: http://www.techrepublic.com/article/solutionbase-strengthen-network-defenses-by-using-a-dmz/5756029. [Accessed: 18-Nov-2012].

[100] C. Fernandez, Seguridad en Sistemas Informáticos. España: Ediciones Diaz de Santos S.A, 1988.

[101] P. Holbrook and J. Reynolds, RFC 1244: Site Secutiry Handbook. ISI Editors, 1991.

[102] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Towards a Framework for Android Security Modules : Extending SE Android Type Enforcement to Android Middleware.” Intel Collaborative Research Institute for Secure Computing, 2012.

[103] E. Walsh, “Application of the flask architecture to the x window system server.” National Security Agency, 2007.

[104] J. Carter, “Using gconf as an example of how to create an userspace object manager.” National Security Agency, 2007.

[105] “sepgsql - Security Enhanced PostgreSQL - Google Project Hosting.” [Online]. Available: https://code.google.com/p/sepgsql/. [Accessed: 03-Apr-2013].

[106] “NB SEforAndroid 1 - SELinux Wiki.” [Online]. Available: http://selinuxproject.org/page/NB_SEforAndroid_1. [Accessed: 03-Apr-2013].

[107] S. Smalley, “The case for SE Android.” National Security Agency.

[108] D. Ehringer, “The dalvik virtual machine architecture.” Mar-2010.

[109] “Android Zygote Startup - eLinux.org.” [Online]. Available: http://elinux.org/Android_Zygote_Startup. [Accessed: 03-Apr-2013].

[110] “Device Administration | Android Developers.” [Online]. Available: http://developer.android.com/guide/topics/admin/device-admin.html. [Accessed: 03-Apr-2013].

[111] “Android Device Policy Administration Tutorial - Marakana.” [Online]. Available: http://marakana.com/s/post/1291/android

32

_device_policy_administration_tutorial. [Accessed: 03-Apr-2013].

[112] “Essentials of the Java Programming Language, Part 1.” [Online]. Available: http://www.oracle.com/technetwork/java/index-138747.html. [Accessed: 12-Mar-2013].

[113] “Application Fundamentals | Android Developers.” [Online]. Available: http://developer.android.com/guide/components/fundamentals.html. [Accessed: 12-Mar-2013].

[114] “Surface Manager | Blog Silex Technologies.” [Online]. Available: http://silextech.wordpress.com/tag/surface-manager/. [Accessed: 05-Mar-2013].

[115] “android/platform_external_opencore · GitHub.” [Online]. Available: https://github.com/android/platform_external_opencore. [Accessed: 02-Mar-2013].

[116] “OpenGL ES 1_X - The Standard for Embedded Accelerated 3D Graphics.” [Online]. Available: http://www.khronos.org/opengles/1_X/. [Accessed: 02-Mar-2013].

[117] “Camera | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/hardware/Camera.html. [Accessed: 06-Mar-2013].

[118] “android.bluetooth | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/bluetooth/package-summary.html. [Accessed: 06-Mar-2013].

[119] “RFCOMM Layer Tutorial.” [Online]. Available: http://www.palowireless.com/infotooth/tutorial/rfcomm.asp. [Accessed: 06-Mar-2013].

[120] J. Huang, “Android IPC Mechanism.” [Online]. Available: http://www.slideshare.net/jserv/android-ipc-mechanism. [Accessed: 12-Mar-2013].

[121] “OpenBinder.” [Online]. Available: http://www.angryredplanet.com/~hackbo

d/openbinder/docs/html/. [Accessed: 03-Mar-2013].

[122] “android.hardware.usb | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/hardware/usb/package-summary.html. [Accessed: 07-Mar-2013].

[123] “USB Host and Accessory | Android Developers.” [Online]. Available: http://developer.android.com/guide/topics/connectivity/usb/index.html. [Accessed: 06-Mar-2013].

[124] “Mobile Phone Termonologies.” [Online]. Available: http://www.bakwaash.com/2011/07/05/mobile-phone-termonologies/. [Accessed: 07-Mar-2013].

[125] “Why QWERTY was Invented.” [Online]. Available: http://home.earthlink.net/~dcrehr/whyqwert.html. [Accessed: 08-Mar-2013].

[126] “Keyboard Devices | Android Open Source.” [Online]. Available: http://source.android.com/tech/input/keyboard-devices.html. [Accessed: 08-Mar-2013].

[127] “android.net.wifi | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/net/wifi/package-summary.html. [Accessed: 08-Mar-2013].

[128] “android.media | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/media/package-summary.html. [Accessed: 09-Mar-2013].

[129] “PowerManager | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/os/PowerManager.html. [Accessed: 08-Mar-2013].

[130] “BatteryManager | Android Developers.” [Online]. Available: http://developer.android.com/reference/android/os/BatteryManager.html. [Accessed: 09-Mar-2013].

[131] A. Ghosh, “Introducing Android 4.1 (Jelly Bean) preview platform, and more | Android Developers Blog.” [Online]. Available: http://android-developers.blogspot.com/2012/06/introducing-android-41-jelly-bean.html. [Accessed: 22-Mar-2013].

[132] “Security Enhancements in Jelly Bean | Android Developers Blog.” [Online]. Available: http://android-developers.blogspot.com/2013/02/security-enhancements-in-jelly-bean.html. [Accessed: 19-Mar-2013].

[133] “Android 4.1 APIs | Android Developers.” [Online]. Available: http://developer.android.com/about/versions/android-4.1.html. [Accessed: 22-Mar-2013].

[134] M. Nauman, S. Khan, and X. Zhang, “Apex: extending Android permission model and enforcement with user-defined runtime constraints,” in Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, New York, NY, USA, 2010, pp. 328–332.

[135] W. Enck, M. Ongtang, and P. McDaniel, “Understanding Android Security,” Ieee Secur. Priv., vol. 7, no. 1, pp. 50 –57, Feb. 2009.

[136] A. Shabtai, U. Kanonov, Y. Elovici, C. Glezer, and Y. Weiss, “‘Andromaly’: a behavioral malware detection framework for android devices,” J Intell Inf Syst, vol. 38, no. 1, pp. 161–190, Feb. 2012.

[137] “How to set and write SMART objectives.” [Online]. Available: http://www.hr.ecu.edu.au/mps/html/mps-smart.cfm. [Accessed: 18-Nov-2012].

[138] S. Smalley and R. Craig, “Security Enhanced (SE) Android: Bringing Flexible MAC to Android.” 2013.

[139] “Gmail: Email from Google.” [Online]. Available: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2. [Accessed: 30-Apr-2013].

[140] “Construx checklist for Architecture.” Construx SOFTWARE.

[141] “Glossary | Wi-Fi Alliance.” [Online]. Available: http://www.wi-fi.org/knowledge-center/glossary/wpa2%25E2%2584%25A2. [Accessed: 29-Apr-2013].

[142] “IEEE 802.11, The Working Group Setting the Standards for Wireless LANs.” [Online]. Available: http://www.ieee802.org/11/. [Accessed: 29-Apr-2013].

[143] “HTTPS Everywhere FAQ,” Electronic Frontier Foundation. [Online]. Available: https://www.eff.org/https-everywhere/faq. [Accessed: 29-Apr-2013].

Documents

Modelo de Seguridad para mitigar los problemas …...navegador de internet Opera. RUFRAUD: malware descubierto en Europa y Rusia, ocultado en fondos de escritorio poplares, u películas