Blog

Seguridad en Android – Parte II – Amenazas en Android y mecanismos de seguridad (II)

En el post anterior vimos parte de los mecanismos de seguridad ofrecidos por Android. Más en concreto, se vieron los grupos “mecanismos de Linux” y “características del entorno”. En este post vamos a centrarnos en los mecanismos específicos de Android.

Antes de empezar con ello, me gustaría definir qué es un manifiesto en Android y qué es un permiso en Android.

Los manifiestos presentan información esencial sobre una aplicación al sistema Android. Esta información es necesaria antes de que el sistema ejecute el código de aplicación. Entre otras cosas, el manifiesto se encarga de:

  • Describir los componentes de la aplicación (actividades, servicios, broadcast receivers y contents providers). Llama a las clases que ejecutan cada uno de sus componentes y publica sus capacidades. Esto permite al sistema saber las condiciones de los diferentes componentes al ser lanzados.
  • Declara los permisos de la aplicación para administrar bien los privilegios.
  • Declara los permisos que necesitan otras aplicaciones para interactuar con los componentes de la aplicación.

Por otro lado, los permisos son reglas que se definen en el fichero de manifiesto para poder administrar de forma correcta el acceso a recursos restringidos.

Mecanismos de seguridad específicos

Permisos de aplicación

El corazón de la seguridad en el nivel de aplicación es el sistema de permisos, el cual hace cumplir las restricciones necesarias en cada operación que la aplicación puede realizar. El Package Manager se encarga de otorgar permisos a las aplicaciones en la instalación mientras que el framework de la aplicación se encarga de cumplir los permisos del sistema en la ejecución.

Existen alrededor de 100 permisos en Android, los cuales controlan operaciones como: el marcado del teléfono, hacer fotografías, usar Internet, escribir SMS, etc.

Cualquier aplicación Android puede declarar permisos adicionales. Para obtener estos permisos, la aplicación debe solicitarlo explícitamente en su manifiesto.

Los permisos llevan niveles de protección asociados:

  1. Normal. Permisos que no son especialmente peligrosos si se obtienen.
  2. Peligrosos (Dangerous). Permisos más peligrosos que los de tipo 1 o normalmente no solicitados por las aplicaciones. Estos permisos necesitan la confirmación por parte del usuario.
  3. Firma (Signature). Permisos que solo pueden ser otorgados a otros paquetes que se han firmado con la misma firma que la declarada en el permiso.
  4. SignatureOrSystem. Permisos de firma que también se conceden a los paquetes instalados en la imagen del sistema.

La asignación del nivel de protección se deja a la voluntad de los desarrolladores. No obstante, las siguientes directrices son útiles a la hora de decidir el nivel de protección de una aplicación. Los permisos “Normal” deben implicar un riesgo menor y servir únicamente como una llamada de atención al usuario para que se de cuente de que la aplicación requiere acceso a una funcionalidad concreta.  Los permisos “Dangerous” deben ser usados para operaciones que implican un riesgo mayor. Un equilibrio balanceado debe mantener la diferencia entre estas dos categorías para evitar desclasificar operaciones de riesgo como normales, lo que provocaría la concesión equivocada de privilegios. Mientras que si optamos por declarar todos los permisos como “Dangerous”, es igual de peligroso ya que puede hacer que el usuario ignore la importancia del nivel de protección debido a la falta de contraste.

Los permisos de “Signature” están destinados únicamente a las aplicaciones firmadas por el mismo desarrollador.

El proceso que siguen los permisos es el siguiente. En la instalación, los permisos requeridos por la aplicación son concedidos basándose en comprobaciones con la firma de las aplicaciones que declaran esos permisos y la interacción con el usuario. Una vez la aplicación se ha instalado y sus permisos han sido concedidos, no se pueden solicitar más permisos. Una operación que no tenga permisos fallará en el momento de su ejecución. Por lo tanto, a la hora de instalar una aplicación, existen dos opciones, confiar en el desarrollador o no confiar en él. En caso de no confiar en él se recomienda no instalar la aplicación ya que no funcionará de forma correcta.

Además de proteger las APIs, el mecanismo de permisos debe garantizar la seguridad de varios componentes en una aplicación que son: Activity, Service, Content Provider y Broadcast Receivers. Esto se consigue asociando permisos con el componente relevante en su declaración y en el manifiesto.

Una Activity (cualquier pantalla con la que el usuario pueda interactuar) puede especificar una serie de permisos requeridos para cualquier aplicación que desea lanzarla. De forma similar, un Service (estructura de fondo de la aplicación) puede controlar qué aplicaciones están permitidas a enlazarse con él. El Content Provider (encargado de almacenar y compartir datos) define permisos para regular quién tiene autorización para escribir o leer información. Como los permisos de lectura y escritura están definidos de forma individual y no están interconectados, se puede tener buen control sobre el Content Provider.

Los permisos sobre los Broadcast Receivers (ejecutados por el sistema en reacción a los Intents) hacen posible controlar qué componentes se pueden recibir. La implicación de estos permisos es tal que cualquier intento de espiar los Intents que están siendo enviados es evitado y cualquier esfuerzo para enviar componentes no autorizados fallará.

Encapsulación de componentes

La habilidad de encapsular componentes en una aplicación evita cualquier acceso a ella desde otra aplicación (asumiendo que tiene un ID de usuario distinto).

Esto se consigue fundamentalmente definiendo el atributo “exported” del componente. Si este atributo está marcado como false, el componente solo puede ser accedido por el propietario de la aplicación y por otras aplicaciones que compartan el id de usuario con el atributo “share user-ID”. Si está marcado como true, puede ser invocado por otros aplicaciones externas.

Sin embargo, las aplicaciones invocadoras todavía pueden ser controladas con el mecanismo de permisos explicado anteriormente. No obstante, se recomienda marcar este atributo manualmente y no confiar en el comportamiento por defecto del sistema.

Firma de aplicaciones

Cada aplicación en Android está empaquetada en un fichero .apk. Este fichero es similar al estándar Java (.jar). A su vez, el .apk también incluye todos los recursos necesarios como las imágenes. Android requiere que todas las aplicaciones sean firmadas digitalmente. La validez de la firma es correcta mientras que su certificado sea valido y la clave pública adjunta verifique dicha firma.

La firma sirve para verificar que dos o más aplicaciones son del mismo propietario. Esta característica es usada por el mecanismo “sharedUserId” y por el mecanismo de permisos (Signature y SignatureOrSystem).

Con este artículo se da por finalizada la explicación acerca de los mecanismos de seguridad en Android. En el siguiente post seguiremos profundizando en la seguridad en Android.

Espero que os sea de utilidad.

Autor:  Borja Simancas (@borjasr92)

Leave a Reply

*

    No Twitter Messages