Estructura y formulación del Modelo de Seguridad

Transcripción

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
Documento de Trabajo de Grado - <Proyecto de investigación>
Contenido
1.
OBJETIVO DEL MODELO .................................................................................................... 4
2.
POLITICAS DE SEGURIDAD ............................................................................................... 4
2.1
Definición ............................................................................................................................... 4
2.2
Aspectos de una política de seguridad ................................................................................. 4
2.3
Objetivos de la seguridad en Android ................................................................................. 5
2.4
Políticas de seguridad para el modelo propuesto ............................................................... 6
2.4.1
SELINUX ............................................................................................................................ 6
2.4.2
SEANDROID ...................................................................................................................... 7
2.4.3
POLITICAS DEL API DE ADMINISTRACION DEL DISPOSITIVO ............................ 7
3.
ARQUITECTURA DEL MODELO DE SEGURIDAD ...................................................... 11
3.1
Arquitectura de la plataforma Android 4.1 ...................................................................... 12
3.2
Sistema de componentes de aplicación .............................................................................. 13
3.3
Descripción de la arquitectura ........................................................................................... 14
3.3.1
APLICACIONES .............................................................................................................. 14
3.3.2
FRAMEWORK DE APLICACION ................................................................................. 14
3.3.3
FRAMEWORK DE LIBRERIAS Y TIEMPO DE EJECUCION .................................... 15
3.3.3.1
LIBRERIAS: ..................................................................................................................... 15
3.3.3.2
TIEMPO DE EJECUCION ANDROID: .......................................................................... 15
3.3.4
KERNEL DE LINUX ....................................................................................................... 16
3.4
Mecanismos de seguridad a nivel de componentes........................................................... 17
3.4.1
CARACTERISTICAS GENERALES DE SEGURIDAD EN ANDROID ...................... 17
3.4.2
SEGURIDAD A NIVEL DE SISTEMA Y KERNEL ...................................................... 18
3.4.3
CARACTERISTICAS DE SEGURIDAD DEL USUARIO ............................................. 21
3.4.4
SEGURIDAD DE APLICACIONES ................................................................................ 22
3.4.5
INVESTIGACIONES REALIZADAS ............................................................................. 25
3.5
Mejoras de seguridad en Android 4.1 ............................................................................... 25
3.6
Modelo de seguridad basado en los ataques y principios ................................................ 27
3.6.1
DIAGRAMA GENERAL ................................................................................................. 27
3.6.2
MITIGACION POR CAPAS: APLICACIONES ............................................................. 29
Página 2
3.6.3
MITIGACION POR CAPAS: FRAMEWORK DE APLICACION................................. 30
3.6.4
MITIGACION POR CAPAS: LIBRERIAS / TIEMPO DE EJECUCION ANDROID ... 31
3.6.5
MITIGACION POR CAPAS: KERNEL DE LINUX ...................................................... 32
3.6.6
IDENTIFICACION DE COMPONENTES DEL PRIMER ATAQUE: iCalendar .......... 33
3.6.7
IDENTIFICACION DE COMPONENTES DEL SEGUNDO ATAQUE: Android.Stels 34
3.6.8
IDENTIFICACION DE COMPONENTES DEL TERCER ATAQUE: BadNews .......... 35
4.
CONCLUSIONES ................................................................................................................... 36
5.
REFERENCIAS ...................................................................................................................... 37
Página 3
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 4.1.
2.2 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
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
2.4 Políticas de seguridad para el modelo propuesto
2.4.1 SELINUX
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
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.
2.4.3 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
-
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
Mínimo de dígitos numéricos requeridos en una
El mínimo número de dígitos numéricos
Página 8
contraseña
requeridos en una contraseña para todos los
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
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.
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
Requerir cifrado de almacenamiento
Especifica que el área de almacenamiento debe
ser encriptado, si el dispositivo lo soporta.
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
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
3.1 Arquitectura de la plataforma Android 4.1
APPLICATIONS
•HOME
•DIALER
•SMS/MMS
•IM
•BROWSER
•CAMERA
•ALARM
•CALCULATOR
•CONTACTS
•VOICE DIAL
•EMAIL
•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
3.2 Sistema de componentes de aplicación
Ilustración 1: Componentes de una aplicación Android [14]
Página 13
3.3 Descripción de la arquitectura
3.3.1 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 [15].
3.3.2 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
-
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.
3.3.3 FRAMEWORK DE LIBRERIAS Y TIEMPO DE EJECUCION
3.3.3.1 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.
3.3.3.2 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
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.
3.3.4 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
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.
3.4.1 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
-
-
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.
3.4.2 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
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
-
-
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
3.4.3 CARACTERISTICAS DE SEGURIDAD DEL USUARIO
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
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.
3.4.4 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
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
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
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.
3.4.5 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
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
3.6 Modelo de seguridad basado en los ataques y principios
3.6.1
DIAGRAMA GENERAL
Página 27
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
3.6.2
MITIGACION POR CAPAS: APLICACIONES
Página 29
3.6.3
MITIGACION POR CAPAS: FRAMEWORK DE APLICACION
Página 30
3.6.4
MITIGACION POR CAPAS: LIBRERIAS / TIEMPO DE EJECUCION ANDROID
Página 31
3.6.5
MITIGACION POR CAPAS: KERNEL DE LINUX
Página 32
3.6.6
IDENTIFICACION DE COMPONENTES DEL PRIMER ATAQUE: iCalendar
El siguiente diagrama muestra el uso del Modelo de seguridad propuesto para identificar los componentes que se ven afectados en el ataque
iCalendar, descrito en el Documento de Ataques según Principios de Seguridad.
APLICACIONES
SMS/MMS
FRAMEWORK DE
APLICACION
TELEPHONY
MANAGER
INTEGRIDAD
TELEPHONY
MANAGER
CONFIDENCIALIDAD
FRAMEWORK DE
APLICACION
LOCATION
MANAGER
ICALENDAR
DISPONIBILIDAD
KERNEL DE LINUX
APPLICATION
SANDBOX
FRAMEWORK DE
APLICACION
TELEPHONY
MANAGER
KERNEL DE LINUX
WIFI DRIVER
KERNEL DE LINUX
APPLICATION
SANDBOX
CONTROL DE
ACCESO
AUTENTICACION
Página 33
3.6.7
IDENTIFICACION DE COMPONENTES DEL SEGUNDO ATAQUE: Android.Stels
Android.stels, descrito en el Documento de Ataques según Principios de Seguridad.
INTEGRIDAD
FRAMEWORK DE
APLICACION
PACKAGE MANAGER
APLICACIONES
CONTACTOS
LIBRERIAS / TIEMPO
DE EJECUCION
ANDROID
LIBWEBCORE
KERNEL DE LINUX
WIFI DRIVER
LIBRERIAS / TIEMPO
DE EJECUCION
ANDROID
LIBWEBCORE
FRAMEWORK DE
APLICACION
TELEPHONY
MANAGER
APLICACIONES
CONTACTOS
APLICACIONES
SMS/MMS
FRAMEWORK DE
APLICACION
TELEPHONY
MANAGER
CONFIDENCIALIDAD
DISPONIBILIDAD
ANDROID.STELS
CONTROL DE
ACCESO
WIFI DRIVER
KERNEL DE LINUX
APPLICATION
SANDBOX
AUTENTICACION
KERNEL DE LINUX
APPLICATION
SANDBOX
Página 34
3.6.8
IDENTIFICACION DE COMPONENTES DEL TERCER ATAQUE: BadNews
BadNews, descrito en el Documento de Ataques según Principios de Seguridad.
INTEGRIDAD
FRAMEWORK DE
APLICACION
PACKAGE MANAGER
FRAMEWORK DE
APLICACION
TELEPHONY
MANAGER
APLICACIONES
EMAIL
APLICACIONES
HOME
CONFIDENCIALIDAD
BADNEWS
DISPONIBILIDAD
WIFI DRIVER
KERNEL DE LINUX
APPLICATION
SANDBOX
CONTROL DE
ACCESO
TELEPHONY
MANAGER
FRAMEWORK DE
APLICACION
PACKAGE MANAGER
Página 35
4. CONCLUSIONES




El modelo de seguridad propuesto en este documento, identificó componentes comprometidos a
nivel de principios de seguridad de la información de los ataques que se encontraron en la
investigación. En el Documento de Pruebas del Modelo de Seguridad se explicará como el
modelo propone la mitigación de dichos ataques y se hará la comparación entre las pruebas
funcionales de los ataques y la identificación de componentes que realizó el modelo.
Para cada componente de la arquitectura de este modelo de seguridad, se menciona un
mecanismo de seguridad, el cual se espera logre mitigar el ataque a dicho componente.
Se pudo demostrar por medio de este modelo, que existe más de un principio de seguridad
comprometido por cada componente de la arquitectura.
El modelo de seguridad propone recursos en cada componente para la mitigación de ataques
que comprometan la Integridad, Confidencialidad y Disponibilidad de la 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.
Página 36
5. REFERENCIAS
[1] C. Fernandez, Seguridad en Sistemas Informáticos. España: Ediciones Diaz de Santos S.A, 1988.
[2] P. Holbrook and J. Reynolds, RFC 1244: Site Secutiry Handbook. ISI Editors, 1991.
[3] C. Borghello, “Seguridad Informática: sus implicancias e implementación.” Universidad
Tecnológica Nacional. Argentina, 2001.
[4] 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.
[5] E. Walsh, “Application of the ﬂask architecture to the x window system server.” National
Security Agency, 2007.
[6] J. Carter, “Using gconf as an example of how to create an userspace object manager.” National
Security Agency, 2007.
[7] “sepgsql - Security Enhanced PostgreSQL - Google Project Hosting.” [Online]. Available:
https://code.google.com/p/sepgsql/. [Accessed: 03-Apr-2013].
[8] “NB SEforAndroid 1 - SELinux Wiki.” [Online]. Available:
http://selinuxproject.org/page/NB_SEforAndroid_1. [Accessed: 03-Apr-2013].
[9] S. Smalley, “The case for SE Android.” National Security Agency.
[10] D. Ehringer, “The dalvik virtual machine architecture.” Mar-2010.
[11] “Android Zygote Startup - eLinux.org.” [Online]. Available:
http://elinux.org/Android_Zygote_Startup. [Accessed: 03-Apr-2013].
[12] “Device Administration | Android Developers.” [Online]. Available:
http://developer.android.com/guide/topics/admin/device-admin.html. [Accessed: 03-Apr2013].
[13] “Android Device Policy Administration Tutorial - Marakana.” [Online]. Available:
http://marakana.com/s/post/1291/android_device_policy_administration_tutorial.
[Accessed: 03-Apr-2013].
[14] “Application Fundamentals | Android Developers.” [Online]. Available:
http://developer.android.com/guide/components/fundamentals.html. [Accessed: 12-Mar2013].
[15] “Essentials of the Java Programming Language, Part 1.” [Online]. Available:
http://www.oracle.com/technetwork/java/index-138747.html. [Accessed: 12-Mar-2013].
[16] “Surface Manager | Blog Silex Technologies.” [Online]. Available:
http://silextech.wordpress.com/tag/surface-manager/. [Accessed: 05-Mar-2013].
[17] N. Hari and B. Prasad, “Android architecture.” [Online]. Available:
http://www.slideshare.net/kittu565/android-architecture. [Accessed: 13-May-2013].
[18] “android/platform_external_opencore · GitHub.” [Online]. Available:
https://github.com/android/platform_external_opencore. [Accessed: 02-Mar-2013].
[19] “OpenGL ES 1_X - The Standard for Embedded Accelerated 3D Graphics.” [Online]. Available:
http://www.khronos.org/opengles/1_X/. [Accessed: 02-Mar-2013].
[20] “Camera | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/hardware/Camera.html. [Accessed: 06Mar-2013].
[21] “android.bluetooth | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/bluetooth/package-summary.html.
[Accessed: 06-Mar-2013].
[22] “RFCOMM Layer Tutorial.” [Online]. Available:
http://www.palowireless.com/infotooth/tutorial/rfcomm.asp. [Accessed: 06-Mar-2013].
Página 37
[23] J. Huang, “Android IPC Mechanism.” [Online]. Available:
http://www.slideshare.net/jserv/android-ipc-mechanism. [Accessed: 12-Mar-2013].
[24] “OpenBinder.” [Online]. Available:
http://www.angryredplanet.com/~hackbod/openbinder/docs/html/. [Accessed: 03-Mar2013].
[25] “android.hardware.usb | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/hardware/usb/package-summary.html.
[26] “USB Host and Accessory | Android Developers.” [Online]. Available:
http://developer.android.com/guide/topics/connectivity/usb/index.html. [Accessed: 06-Mar2013].
[27] “Mobile Phone Termonologies.” [Online]. Available:
http://www.bakwaash.com/2011/07/05/mobile-phone-termonologies/. [Accessed: 07-Mar2013].
[28] “Why QWERTY was Invented.” [Online]. Available:
http://home.earthlink.net/~dcrehr/whyqwert.html. [Accessed: 08-Mar-2013].
[29] “Keyboard Devices | Android Open Source.” [Online]. Available:
http://source.android.com/tech/input/keyboard-devices.html. [Accessed: 08-Mar-2013].
[30] “android.net.wifi | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/net/wifi/package-summary.html.
[31] “android.media | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/media/package-summary.html. [Accessed:
09-Mar-2013].
[32] “PowerManager | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/os/PowerManager.html. [Accessed: 08Mar-2013].
[33] “BatteryManager | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/os/BatteryManager.html. [Accessed: 09Mar-2013].
[34] “What is ASLR?” [Online]. Available:
http://netsecurity.about.com/od/quicktips/qt/whatisaslr.htm. [Accessed: 09-Mar-2013].
[35] “X.Org Wiki - ProPolice.” [Online]. Available: http://www.x.org/wiki/ProPolice. [Accessed: 09Mar-2013].
[36] “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/safeiop/wiki/README. [Accessed: 09-Mar-2013].
[37] “Take a closer look at OpenBSD.” [Online]. Available:
http://www.ibm.com/developerworks/aix/library/au-openbsd.html. [Accessed: 10-Mar-2013].
[38] “mmap_min_addr - Debian Wiki.” [Online]. Available:
http://wiki.debian.org/mmap_min_addr. [Accessed: 10-Mar-2013].
[39] “Android Security Overview | Android Open Source.” [Online]. Available:
http://source.android.com/tech/security/index.html. [Accessed: 18-Feb-2013].
[40] “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-onyour-smartphone-tablet/. [Accessed: 12-Mar-2013].
Página 38
[41] “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.
[42] 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.
[43] D. Boneh, “Twenty years of attacks on the RSA cryptosystem.” 1998.
[44] D. Pointcheval, “How to Encrypt Properly with RSA.” 2002.
[45] “FIPS 186 - (DSS), Digital Signature Standard.” [Online]. Available:
http://www.itl.nist.gov/fipspubs/fip186.htm. [Accessed: 12-Mar-2013].
[46] “Digest::SHA - search.cpan.org.” [Online]. Available: http://search.cpan.org/~mshelor/DigestSHA-5.62/lib/Digest/SHA.pm. [Accessed: 13-Mar-2013].
[47] “Unix crypt with SHA-256/512.” [Online]. Available: http://www.akkadia.org/drepper/shacrypt.html. [Accessed: 13-Mar-2013].
[48] “RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2.” [Online]. Available:
https://tools.ietf.org/html/rfc5246. [Accessed: 13-Mar-2013].
[49] “HTTPS Security Improvements in Internet Explorer 7.” [Online]. Available:
http://msdn.microsoft.com/en-us/library/bb250503.aspx. [Accessed: 13-Mar-2013].
[50] “RFC 2818 - HTTP Over TLS.” [Online]. Available: http://tools.ietf.org/html/rfc2818. [Accessed:
13-Mar-2013].
[51] “KeyChain | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/security/KeyChain.html. [Accessed: 13-Mar2013].
[52] “CWE - CWE-415: Double Free (2.4).” [Online]. Available:
http://cwe.mitre.org/data/definitions/415.html. [Accessed: 13-Mar-2013].
[53] “Double Free - OWASP.” [Online]. Available: https://www.owasp.org/index.php/Double_Free.
[54] “Using freed memory - OWASP.” [Online]. Available:
https://www.owasp.org/index.php/Using_freed_memory. [Accessed: 15-Mar-2013].
[55] “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.+ApplicationLevel+Risks/13.5+Heap+Overflows/. [Accessed: 15-Mar-2013].
[56] “CWE - CWE-134: Uncontrolled Format String (2.4).” [Online]. Available:
http://cwe.mitre.org/data/definitions/134.html. [Accessed: 15-Mar-2013].
[57] “Gentoo Linux Documentation -- Position Independent Code internals.” [Online]. Available:
http://www.gentoo.org/proj/en/hardened/pic-internals.xml. [Accessed: 15-Mar-2013].
[58] “2.6. Position Independent Executables.” [Online]. Available: http://linuxfromscratch.xtranet.org/hlfs/view/unstable/glibc-2.4/chapter02/pie.html. [Accessed: 15-Mar-2013].
[59] “Enabling the kernel’s DMESG_RESTRICT feature.” [Online]. Available:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033240.html. [Accessed: 16-Mar2013].
[60] “FORTIFY_SOURCE Semantics | NYU Poly ISIS Lab.” [Online]. Available:
https://isisblogs.poly.edu/2011/04/11/fortify_source-semantics/. [Accessed: 15-Mar-2013].
[61] “Brute force attack - OWASP.” [Online]. Available:
https://www.owasp.org/index.php/Brute_force_attack. [Accessed: 16-Mar-2013].
[62] “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].
Página 39
[63] “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].
[64] “Using password systems - OWASP.” [Online]. Available:
https://www.owasp.org/index.php/Using_password_systems. [Accessed: 16-Mar-2013].
[65] “Virtual Private Networking: An Overview.” [Online]. Available:
http://technet.microsoft.com/en-us/library/bb742566.aspx. [Accessed: 18-Mar-2013].
[66] “VPN Technologies: Definitions and Requirements.” [Online]. Available:
http://www.vpnc.org/vpn-technologies.html. [Accessed: 19-Mar-2013].
[67] “RFC 2637 - Point-to-Point Tunneling Protocol (PPTP).” [Online]. Available:
http://tools.ietf.org/html/rfc2637. [Accessed: 19-Mar-2013].
[68] “RFC 2661 - Layer Two Tunneling Protocol ‘L2TP’.”[Online]. Available:
http://tools.ietf.org/html/rfc2661. [Accessed: 19-Mar-2013].
[69] “VpnService | Android Developers.” [Online]. Available:
http://developer.android.com/reference/android/net/VpnService.html. [Accessed: 17-Mar2013].
[70] “SMS Tutorial: Introduction to AT Commands, Basic Commands and Extended Commands.”
[Online]. Available: http://www.developershome.com/sms/atCommandsIntro.asp. [Accessed:
18-Mar-2013].
[71] “Android - Radio Layer Interface.” [Online]. Available:
http://www.netmite.com/android/mydroid/development/pdk/docs/telephony.html.
[72] “Aplicaciones de Android en Google Play.” [Online]. Available: https://play.google.com/store.
[Accessed: 18-Nov-2012].
[73] “Company – Google.” [Online]. Available: http://www.google.com/about/company/.
[74] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “TaintDroid,”
2010. [Online]. Available: http://dl.acm.org/citation.cfm?id=1924971. [Accessed: 21-Mar2013].
[75] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall, “These aren’t the droids you’re
looking for,” 2011. [Online]. Available: http://dl.acm.org/citation.cfm?id=2046780. [Accessed:
22-Mar-2013].
[76] M. Conti, V. T. N. Nguyen, and B. Crispo, “CRePE,” 2010. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1949355. [Accessed: 22-Mar-2013].
[77] R. Xu, H. Saidi, and R. Anderson, “Aurasium,” 2012. [Online]. Available:
http://dl.acm.org/citation.cfm?id=2362793.2362820. [Accessed: 22-Mar-2013].
[78] M. Backes, S. Gerling, C. Hammer, M. Maffei, and P. von Styp-Rekowsky, “AppGuard — Realtime policy enforcement for third-party applications.” 2012.
[79] “SEforAndroid - SELinux Wiki.” [Online]. Available: http://selinuxproject.org/page/SEAndroid.
[80] T. Harada, T. Horie, and K. Tanaka, “Task Oriented Management Obviates Your Onus on
Linux.” 2004.
[81] S. Smalley and R. Craig, “Security Enhanced (SE) Android: Bringing Flexible MAC to Android.”
2013.
[82] L. Davi, A. Dmitrienko, A.-R. Sadeghi, and M. Winandy, “Privilege escalation attacks on
android,” in Proceedings of the 13th international conference on Information security, Berlin,
Heidelberg, 2011, pp. 346–360.
Página 40
[83] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel, “Semantically Rich Application-Centric
Security in Android,” 2009. [Online]. Available: http://dl.acm.org/citation.cfm?id=1723245.
[84] Y. Zhou, X. Zhang, X. Jiang, and V. W. Freeh, “Taming information-stealing smartphone
applications (on Android),” in Proceedings of the 4th international conference on Trust and
trustworthy computing, Berlin, Heidelberg, 2011, pp. 93–107.
[85] A. Ghosh, “Introducing Android 4.1 (Jelly Bean) preview platform, and more | Android
Developers Blog.” [Online]. Available: http://androiddevelopers.blogspot.com/2012/06/introducing-android-41-jelly-bean.html. [Accessed: 22Mar-2013].
[86] “Security Enhancements in Jelly Bean | Android Developers Blog.” [Online]. Available:
http://android-developers.blogspot.com/2013/02/security-enhancements-in-jelly-bean.html.
[87] “Android 4.1 APIs | Android Developers.” [Online]. Available:
http://developer.android.com/about/versions/android-4.1.html. [Accessed: 22-Mar-2013].
Página 41

Estructura y formulación del Modelo de Seguridad

Transcripción

Documentos relacionados

Descargar Archivo

El Blog de Songo Magazine 5.0

Notinpec No 370

Instructivo

Descargar - Usuario Digital