Seguridad en Dispositivos Móviles

La seguridad en los dispositivos móviles es un tema serio. Día a día muchas personas en todo el mundo compran nuevos dispositivos, ya sean tablets, PDAs, o celulares, y estos los llenan con su información personal y otra información importante, como teléfonos, cuentas bancarias, correos y demás. Los desarrolladores debemos de tener cuidado en como se almacena esta información, ya que cualquier malware que el usuario descargue podría tener acceso a toda la información que nuestra aplicación almacena sobre el usuario. Pensando en esto, en el post veremos algunos puntos de interés en la seguridad de los dispositvos móviles, en particular Android, que ha sido víctima de malware.

Seguridad en Android

Android es un sistema operativo de privilegios separados, en el cual en cada aplicación que corre en él, tiene una identidad de sistema distinta(ID de usuario de Linux e ID de usuario de grupo). Partes del sistema son también separadas en distintas identidades. Así, Linux aisla las aplicaciones unas de otras y del sistema operativo.

Medidas de seguridad adicionales son proporcionadas mediante permisos que refuerzan las restricciones de ciertas operaciones para que un cierto proceso pueda realizar.

Arquitectura de Seguridad

Un punto central de diseño de la arquitectura de seguridad de Android es que ninguna aplicación, por defecto, tiene permiso para realizar alguna operación que puede impactar otra aplicación, el sistema operativo, o el usuario. Esto incluye leer o escribir los datos privados del usuario(como contactos o correos), leer o escribir en los archivos de otra aplicación, realizar accesos a la red, mantener el dispositivo despierto, etc.

Debido a que Android separa las aplicaciones unas de otras, las aplicaciones deben compartir recursos y datos explícitamente. Esto lo hacen declarando permisos que son necesarios para capacidades adicionales que no son proporcionadas por defecto. Las aplicaciones declaran de manera estática los permisos que requieren, y el sistema operativo le pregunta al usuario el consentimiento para esto al momento de que la aplicación se instale. Android no tiene ningún mecanismo para dar permisos de forma dinámica(durante ejecución), debido a que complica la experiencia del usuario.

Firma de la Aplicación

Todas las aplicaciones de Android deben "firmarse" con un certificado, al cual el desarrollador contiene una llave privada. Este certificado identifica el autor de la aplicación. El certificado no necesita ser firmado por una autoridad certificada, es permitido y típico que las aplicaciones de Android usen certificados firmados por sí mismos. El propósito de los certificados en Android es distinguir los autores de aplicaciones. Esto permite al sistema dar o denegar a las aplicaciones acceso a permisos de nivel de firmas, y permitir o denegar a la aplicación una solicitud de recibir el mismo ID de Linux que otra aplicación.

ID de Usuario y Acceso a Archivos

Durante la instalación, Android le da a cada paquete un ID de usuario de Linux distinto. La identidad permanece constante durante la vida de ese paquete en el dispositivo. En un dispositivo diferente, el mismo paquete puede tener un diferente ID de usuario, pero lo único que importa es que cada paquete tenga un ID de usuario distinto en el dispositivo determinado.

Debido a que el refuerzo de seguridad pasa a nivel de proceso, el código de cualquiera de dos paquetes no puede correr normalmente en el mismo proceso, debido a que necesitan correr con ID de usuario de Linux diferentes. Es posible usar el atributo sharedUserId en la etiqueta de manifiesto  AndroidManifest.xml de cada paquete para tenerles asignado el mismo ID de usuario. Haciendo eso, para propósitos de seguridad los dos paquetes son tratados como la misma aplicación, con el mismo ID de usuario y permisos de archivo. Se debe dar note que para poder mantener la seguridad, solo a dos aplicaciones iniciadas con la misma firma ( y solicitando el mismo sharedUserId) se les dará el mismo ID de usuario.

Cualquier información guardada por una aplicación será asignada al ID de esa aplicación, y no será accesible(normalmente) a otros paquetes. Cuando se crea un nuevo archivo mediante getSharedPreferences(String, int), openFileOutput(String, int), openOrCreateDataBase(String, int, SQLiteDatabase.CursorFatory), se pueden usar las flags MODE_WORLD_READABLE o MODE_WORLD_WRITABLE para permitir que otros paquetes lean o escriban el archivo. Cuando se coloquen estas banderas, el archivo sigue siendo propiedad de la aplicación, pero los permisos de lectura y escritura global fueron colocados apropiadamente para que cualquier otra aplicación pueda verlo.

Seguridad en iOS

Despúes del lanzamiento inicial de iOS, Apple hizo avances significativos asegurando como el sistema operativo controla el acceso al código. Esas acciones han hecho más difícil ejecutar exploits en un dispositivo con iOS.

Sandbox

Un software sandbox es un mecanismo que restringe el acceso que el programa tiene. La tecnología sandbox de Apple esta basada en el proyecto TrustedBSD.

El sandbox es un conjunto de controles que limitan el acceso de una aplicación a archivos, preferencias, recursos de red, hardware y demás. Cada aplicación tiene acceso a los contenidos de su propio sandbox, pero no puede acceder el de las otras aplicaciones. Cuando una aplicación es instalada por primera vez en un dispositivo, el sistema crea el directorio principal de la aplicación, coloca unos subdirectorios clave, y establece los privilegios de seguridad para el sandbox.

Data Execution Protection


DEP es una técnica común para evitar que código maliciosa corra. Se ha usado desde Windows XP Service Pack 2, y ha existido en iOS desde la versión 2.0. 


La forma en que el DEP funciona es que permite al procesador diferenciar entre código(lo que se ejecuta) y los datos(cosas como fotos, palabras, etc. que no se supone que deberían ejecutarse). Esto lo hace difícil para el software malintencionado debido a que deberían primero inyectar algún código en una aplicación, disfrazado como datos, y después usar una vulnerabilidad para conseguir que ese código se ejecute.


No es una solución infalible, como se demostró en una competición, donde una persona atravesó el DEP en iOS 4.2.1, para luego hacer exploits en él. Sin embargo, hay que notar que dicho exploit hubiera fallado en contra de dispositivos con iOS 4.3, debido a que implementaban ASLR(Address Space Layout Randomization).



Address Space Layout Randomization


Las técnicas de exploit comunes sobrescriben direcciones retornadas por punteros  a códigos maliciosos. Con el ASLR la previsión de direcciones de memoria es reducida haciendo aleatorio el espacio de direcciones para cada instancia de un programa. Entonces el trabajo del ASLR es prevenir exploits moviendo los puntos de entrada de los procesos a localizaciones aleatorias, lo que disminuye la posibilidad de que un exploit individual tenga éxito. 


ASLR fue añadido en iOS 4.3 y ha incrementado la dificultad para tanto el jailbreak como los exploits al dispositivo. 

iOS vs Android

Una comparación muy interesante que encontré en internet, se puede mostrar en la siguiente infográfica(en inglés):

Infographic by Veracode Application Security

Referencias:

Mobile Security - Android vs. iOS

Security and Permissions
Mobile phone security: What are the risks?
Security Showdown: Android Vs. iOS
Security Implications of iOS