ESTRUCTURA Y FORMULACION DE UN MODELO DE SEGURIDAD

Transcripción

1 Ingeniería de Sistemas CIS1310SD03 ESTRUCTURA Y FORMULACION DE UN MODELO DE SEGURIDAD El siguiente documento explicará la estructura y arquitectura del modelo de seguridad propuesto en el Trabajo de Grado. El primer capítulo describe el objetivo del modelo de seguridad a proponer, el segundo capítulo hace referencia a las políticas de seguridad que se tienen en cuenta para el desarrollo del modelo, el tercer capítulo define la arquitectura del modelo de seguridad, teniendo en cuenta: componentes, arquitectura de la plataforma, mecanismos de seguridad existentes, ataques y principios de seguridad de la información. Además, en este capítulo se realiza la identificación de componentes por parte del modelo para los ataques descritos en el Documento de Ataques según Principios de Seguridad. El cuarto capítulo establece las conclusiones a las que se llegó mediante el desarrollo de este documento y por último, el quinto capítulo contiene las referencias para la elaboración del documento. RAUL CALERO ASENCIOS PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C. 2013

2 Contenido 1. OBJETIVO DEL MODELO POLITICAS DE SEGURIDAD Definición Aspectos de una política de seguridad Objetivos de la seguridad en Android Políticas de seguridad para el modelo propuesto SELINUX SEANDROID POLITICAS DEL API DE ADMINISTRACION DEL DISPOSITIVO ARQUITECTURA DEL MODELO DE SEGURIDAD Arquitectura de la plataforma Android Sistema de componentes de aplicación Descripción de la arquitectura APLICACIONES FRAMEWORK DE APLICACION FRAMEWORK DE LIBRERIAS Y TIEMPO DE EJECUCION LIBRERIAS: TIEMPO DE EJECUCION ANDROID: KERNEL DE LINUX Mecanismos de seguridad a nivel de componentes CARACTERISTICAS GENERALES DE SEGURIDAD EN ANDROID SEGURIDAD A NIVEL DE SISTEMA Y KERNEL CARACTERISTICAS DE SEGURIDAD DEL USUARIO SEGURIDAD DE APLICACIONES INVESTIGACIONES REALIZADAS Mejoras de seguridad en Android Modelo de seguridad basado en los ataques y principios DIAGRAMA GENERAL MITIGACION POR CAPAS: APLICACIONES Página 2

3 3.6.3 MITIGACION POR CAPAS: FRAMEWORK DE APLICACION MITIGACION POR CAPAS: LIBRERIAS / TIEMPO DE EJECUCION ANDROID MITIGACION POR CAPAS: KERNEL DE LINUX IDENTIFICACION DE COMPONENTES DEL PRIMER ATAQUE: icalendar IDENTIFICACION DE COMPONENTES DEL SEGUNDO ATAQUE: Android.Stels IDENTIFICACION DE COMPONENTES DEL TERCER ATAQUE: BadNews CONCLUSIONES REFERENCIAS Página 3

4 1. OBJETIVO DEL MODELO El modelo de seguridad tiene como objetivo mitigar los problemas derivados de las vulnerabilidades en dispositivos móviles Android con respecto a los principios de Integridad, Confidencialidad y Disponibilidad. Para lograr este objetivo, el modelo debe identificar correctamente los componentes afectados por los ataques, basados en la descripción del ataque (características) y en la descripción de los componentes que conforman la arquitectura de la plataforma Android versión 4.1 (interacción con otros componentes, responsabilidades, entre otros). 2. POLITICAS DE SEGURIDAD 2.1 Definición 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 [1]. 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 [2]. 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 Aspectos de una política de seguridad Generalmente en la definición de una política de seguridad, se tienen algunos conceptos aplicados, como [3]: Decisión: elección de un curso de acción determinado entre varios posibles. Plan: conjunto de decisiones que definen cursos de acción futuros y los medios para conseguirlos. Consiste en diseñar un futuro deseado y la búsqueda del modo de conseguirlo. Estrategia: conjunto de decisiones que se toman para determinar políticas, metas y programas. Página 4

5 Política: definiciones establecidas por la dirección, que determina criterios generales a adoptar en distintas funciones y actividades donde se conocen las alternativas ante circunstancias repetidas. Meta: objetivo cuantificado a valores predeterminados. Procedimiento: definición detallada de pasos a ejecutar para desarrollar una actividad determinada. Norma: forma en que realiza un procedimiento o proceso. Programa: secuencia de acciones interrelacionadas y ordenadas en el tiempo que se usan para coordinar y controlar operaciones. Proyección: predicción del comportamiento futuro, basándose en el pasado sin el agregado de apreciaciones subjetivas. Pronóstico: predicción del comportamiento futuro, con el agregado de hechos concretos y conocidos que se prevé influirán en los acontecimientos futuros. Control: capacidad de ejercer o dirigir una influencia sobre una situación dada o hecho. Es una acción tomada para hacer un hecho conforme a un plan. Riesgo: proximidad o posibilidad de un daño, peligro. Cada uno de los imprevistos, hechos desafortunados, entre otros, que puede tener un efecto adverso. Sinónimos: amenaza, contingencia, emergencia, urgencia, apuro. 2.3 Objetivos de la seguridad en Android - Proteger datos de usuario - Proteger recursos del sistema - Proveer asilamiento de aplicaciones Para alcanzar estos objetivos, la plataforma provee características clave de seguridad como: una seguridad robusta a nivel de sistema operativo a través del kernel de Linux, un componente Application Sandbox para todas las aplicaciones, una comunicación entre procesos segura, firma de aplicaciones y unos permisos de usuario y aplicación garantizados. Página 5

6 2.4 Políticas de seguridad para el modelo propuesto SELINUX Documento de Trabajo de Grado - <Proyecto de investigación> Secutiry Enhanced Linux (SELinux) [4], 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 [5], GConf [6], SE-PostgreSQL [7] Página 6

7 2.4.2 SEANDROID Prototipa SELinux para el kernel de Linux en Android [8] [9]. 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 [4]. 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) [10], el cual viene instalado con las librerías de Android y permite los inicios rápidos de procesos de una nueva aplicación [11]. 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 [12] [13]. 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 Página 7

8 - 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 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. Políticas de seguridad soportadas por el API de Administración del dispositivo [12]: Contraseña habilitada Requiere que el dispositivo pregunte por un PIN o contraseña. Tamaño mínimo de la contraseña Establece el número necesario de caracteres para la contraseña. Contraseña alfanumérica requerida Requiere que la contraseña tenga una combinación de letras y números. Estos pueden incluir caracteres simbólicos. Contraseña compleja requerida Requiere que las contraseñas contengan al menos una letra, un digito y un símbolo especial. Introducido en Android 3.0. Mínimo de letras requeridas en una contraseña El mínimo número de letras requeridas en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Mínimo de letras minúsculas requeridas en una contraseña El mínimo número de letras minúsculas requeridas en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Mínimo de caracteres que no son letras requeridos en una contraseña El mínimo número caracteres que no son letras requeridos en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Mínimo de dígitos numéricos requeridos en una El mínimo número de dígitos numéricos Página 8

9 contraseña requeridos en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Mínimo de símbolos requeridos en una contraseña El mínimo número de símbolos requeridos en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Mínimo de letras mayúsculas requeridas en una contraseña El mínimo número de letras mayúsculas requeridas en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0. Tiempo de expiración de la contraseña Cuando la contraseña caducara, expresada como un delta en milisegundos desde cuando un administrador del dispositivo establece el tiempo de expiración. Introducido en Android 3.0. Histórico de restricción de contraseñas Esta política evita que los usuarios vuelvan a usar las últimas contraseñas. Generalmente se usa esta política en combinación con setpasswordexpirationtimeout(), que obliga a los usuarios a actualizar sus contraseñas, después de un periodo de tiempo específico. Introducido en Android 3.0. Máximo de intentos fallidos de contraseña Especifica el número de veces que el usuario puede ingresar una contraseña errónea, antes que el dispositivo borre sus datos. El API de Administración del dispositivo, también permite a los administradores, resetear el dispositivo remotamente a su configuración de fábrica. Bloqueo por máximo tiempo de inactividad Establece el tiempo transcurrido desde que el usuario toco la pantalla o un botón por última vez, antes que el dispositivo bloquee la pantalla. Cuando sucede esto, el usuario debe introducir su PIN o contraseña de nuevo, antes de poder usar su dispositivo y datos de acceso. El valor puede ser entre 1 y 60 minutos. Página 9

10 Requerir cifrado de almacenamiento Especifica que el área de almacenamiento debe ser encriptado, si el dispositivo lo soporta. Introducido en Android 3.0. Deshabilitar cámara Especifica que la cámara debe ser deshabilitada. Esta no debe ser una des habilitación permanente, la cámara puede ser habilitada/ deshabilitada basado en el contexto. Introducido en Android 4.0. Una política de seguridad además puede requerir cifrado del dispositivo de almacenamiento como en Android 3.0 o deshabilitar la cámara como en Android 4.0. Un ejemplo de una aplicación de administración de dispositivos es el Android SDK Manager. Página 10

11 3. ARQUITECTURA DEL MODELO DE SEGURIDAD El presente capitulo define la arquitectura que conforma el modelo de seguridad propuesto, la primera sección del capítulo describe la arquitectura de la plataforma Android (base fundamental para la elaboración del modelo), la segunda sección presenta un diagrama en donde se ve la relación de los componentes que generalmente interactúan en una aplicación de tipo Android (APK), la tercera sección explica cada uno de los componentes mencionados en la primera sección de este capítulo, la cuarta sección menciona los mecanismos de seguridad existentes en la plataforma, la quinta sección menciona las mejoras en la plataforma de acuerdo a la versión en la que se desarrolló el Trabajo de Grado (Android 4.1) y por último la quinta sección presenta el modelo de seguridad propuesto a partir de las secciones anteriores y de la investigación realizada sobre los ataques encontrados en la plataforma. Página 11

12 3.1 Arquitectura de la plataforma Android 4.1 Documento de Trabajo de Grado - <Proyecto de investigación> APPLICATIONS HOME DIALER SMS/MMS IM BROWSER CAMERA ALARM CALCULATOR CONTACTS VOICE DIAL CALENDAR MEDIA PLAYER ALBUM CLOCK APPLICATION FRAMEWORK ACTIVITY MANAGER WINDOW MANAGER CONTENT PROVIDER VIEW SYSTEM NOTIFICATION MANAGER PACKAGE MANAGER TELEPHONY MANAGER RESOURCE MANAGER LOCATION MANAGER XMPP SERVICE LIBRARIES SURFACE MANAGER MEDIA FRAMEWORK SQLITE OPEN GL ES FREETYPE LIBWEBCORE SGL SSL LIBC ANDROID RUNTIME CORE LIBRARIES DALVIK VIRTUAL MACHINE LINUX KERNEL DISPLAY DRIVER CAMERA DRIVER BLUETOOTH DRIVER FLASH MEMORY DRIVER BINDER IPC DRIVER USB DRIVER KEYPAD DRIVER WIFI DRIVER AUDIO DRIVER POWER MANAGEMENT Página 12

13 3.2 Sistema de componentes de aplicación Ilustración 1: Componentes de una aplicación Android [14] Página 13

14 3.3 Descripción de la arquitectura APLICACIONES La plataforma Android tiene un conjunto de aplicaciones básicas incluyendo un cliente de , 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 [15] FRAMEWORK DE APLICACION 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 [14] [16] [17]: - 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. Página 14

15 - 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 [16] [17]: 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 [18], 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 [19], 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 [16]. Página 15

16 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 [20]. 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 [21]: - Escanear otros dispositivos Bluetooth - Consultar el adaptador Bluetooth local, para los dispositivos Bluetooth conectados - Establecer canales o sockets RFCOMM [22] - 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 [23]. 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 reimplementación de OpenBinder [24], el cual brinda enlaces a funciones y datos de un ambiente de ejecución a otro. Página 16

17 Características [23]: - 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) [25] [26]. Keypad driver (Controlador de teclado): Android soporta una gran variedad de dispositivos de teclado incluyendo funciones especiales (controles de volumen y encendido), teclados QWERTY [27] [28] embebidos y teclados externos tipo computador con todas las funciones [29]. WIFI driver (Controlador de WIFI): componente que tiene funcionalidades de conexión Wifi (acceso a redes wifi), contiene además información de 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 [30]. 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 [31]. 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 [32] [33]. 3.4 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. Página 17

18 - Tecnologías como ASLR [34], NX, ProPolice [35], safe_iop [36], OpenBSD dlmalloc [37], OpenBSD calloc [37] y mmap_min_addr de Linux [38] 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. - 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 [39]: 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 [39]: 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. Página 18

19 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 [39]: 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 [40] [41], 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 [39]: 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) [42], RSA (Rivest, Shamir y Adleman) [43] [44], DSA (Algoritmo de firma digital) [45] y SHA [46] [47]. Los APIs son proporcionados para protocolos de comunicación de alto nivel como SSL [48] y HTTPS [49] [50] (protocolos criptográficos de comunicación segura a través de la red o Internet). Android 4.0 introdujo la clase KeyChain [51] 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 [39]: Android 1.5+: - ProPolice [35] para prevenir saturaciones del buffer de pila. - Safe_iop [36] para reducir desbordamiento de entero. - Extensiones a OpenBSD dlmalloc [37] para prevenir vulnerabilidades double free [52] [53] (que ocasiona desbordamiento de pila) y para prevenir chunk consolidation attacks [54] [55]. - OpenBSD calloc para prevenir desbordamiento de enteros durante asignación de memoria. Android 2.3+: - Protección a vulnerabilidades de formato cadena no controlado [56] (-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. Página 19

20 - 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 [38] para mitigar desreferenciación de privilegios null pointer. Android 4.0+: - Address Space Layout Randomization (ASLR) [34], para aleatorizar lugares clave en memoria. Android 4.1+: - Soporte PIE(Ejecutable independiente de posición) [57] [58], 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 [59] habilitado (para evitar fugas de direcciones Kernel). - kptr_restrict habilitado (para evitar fugas de direcciones Kernel). Android 4.2+: - FORTIFY_SOURCE [60], para realizar limites automáticos de comprobación de funciones peligrosas y así, prevenir desbordamiento de buffer. Root de dispositivos [39]: 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. Página 20

21 3.4.3 CARACTERISTICAS DE SEGURIDAD DEL USUARIO Documento de Trabajo de Grado - <Proyecto de investigación> Cifrado del sistema de archivos [39]: 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) [42] con CBC y ESSIV:SHA256 [47][46]. 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 [61] o rainbow tables [62] (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 [63]. Para proveer resistencia ante ataques de diccionario de contraseñas [64], 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 [39]: 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 [39]: 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 [39]: la plataforma Android incluye por defecto un conjunto 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 [65] [66] (Red Privada Virtual) con soporte para PPTP [67] (Protocolo de Comunicaciones Punto a Punto), L2TP [68] (Layer 2 Tunneling Protocol), e IPsec VPNs. Además, desde la versión 4.0 en adelante, la Página 21

22 plataforma introduce la clase VPNService [69] 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 [39]: 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 del teléfono - Funciones SMS/MMS - 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. Página 22

23 Ilustración 2: Despliegue de permisos al instalar una aplicación en Android 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 Página 23

24 incluyendo el acceso a la información personal. Las aplicaciones tampoco pueden usar comandos AT (ATtention Command) [70] ya que estas son manejadas por la Capa de Interfaz de Radio (Radio Interface Layer) [71], 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 [39]: 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 [72] o el instalador de paquetes de Android. En Google Play [72], la firma de aplicaciones sirve para mostrar la confianza que Google [73] 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 Página 24

25 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 INVESTIGACIONES REALIZADAS Aparte los mecanismos mencionados anteriormente 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 [74] [75] [76] [77] [78]. 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 [79] o Tomoyo [80] para mitigar ataques de escalamiento de privilegios a bajo nivel [81] [82]. Por otro lado, Saint [83] o TISSA [84], 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. 3.5 Mejoras de seguridad en Android 4.1 Para mejorar la experiencia de usuario, la plataforma Android 4.1 tiene unas mejoras de seguridad [85] [86] [87]: 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. Página 25

26 Descubrimiento de servicio Wi-Fi directo: nueva API proporciona detección de servicios preasociada 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. Página 26

27 3.6 Modelo de seguridad basado en los ataques y principios DIAGRAMA GENERAL Página 27

28 El diagrama anterior, muestra la arquitectura del modelo de seguridad. El modelo de seguridad que se propone en este Trabajo de Grado está enfocado en ataques que comprometan los principios de Integridad, Confidencialidad y Disponibilidad de la información. La arquitectura muestra los principales problemas en relación a estos tres principios que presenta cada componente. Para la definición de componentes que conforman la arquitectura, se tuvo en cuenta aquellos que en realidad se ven comprometidos al momento de realizar los ataques a la plataforma Android 4.1. Cabe resaltar que la arquitectura propuesta para el Modelo de Seguridad, se basó en la arquitectura de la plataforma. A continuación, se explicarán los mecanismos y recursos de seguridad que provee el Modelo de Seguridad propuesto, para mitigar ataques a la plataforma Android 4.1. Página 28

29 3.6.2 MITIGACION POR CAPAS: APLICACIONES Página 29

30 3.6.3 MITIGACION POR CAPAS: FRAMEWORK DE APLICACION Página 30

31 3.6.4 MITIGACION POR CAPAS: LIBRERIAS / TIEMPO DE EJECUCION ANDROID Página 31

32 3.6.5 MITIGACION POR CAPAS: KERNEL DE LINUX Página 32