La sécurité sur Android : pas si inefficace qu’elle en a l’air…

La popularité d’Android attire de plus en plus de hackers et il ne se passe pas un jour, sans qu’une actualité ne vienne remettre en cause le modèle de sécurité mis en place par Google. Que ce soit les applications du Play Store, ou celles installées via des Markets tiers, des entreprises spécialisées en sécurité s’offusquent de voir un nombre croissant de malwares arriver sur Android.

Ici il n’est pas question de virus, mais bien de malwares, car les applications vont « voler » des données sensibles du téléphone pour ensuite les utiliser à des fins malveillantes. Vous noterez toutefois que les dégâts sont toujours limités grâce aux permissions. Elles permettent de limiter le champs d’action des applications : par exemple si elle ne demande pas l’accès Internet, elle ne pourra pas effectuer une requête distante. Les permissions sont également très utiles pour les utilisateurs qui peuvent doivent s’interroger lorsqu’ils installent une application, en parallèle des avis des autres utilisateurs. Les malwares sont donc dangereux sur Android, mais une très grande partie peuvent être détectés très simplement.

Par ailleurs, en regardant l’actu tech’ vous noterez que chaque jour ou presque de grandes entreprises se font dérober leurs données et Android n’en est pas la cause. Il en est de même pour toutes les entreprises spécialisées dans la sécurité, qui pointent souvent du doigt le secteur des ordinateurs. Android n’est peut-être pas le meilleur élève, mais l’informatique en général a toujours eu son lot de vulnérabilités. Il existe bien évidemment une solution : des logiciels bien plus sécurisés, mais derrière ces belles paroles, l’implémentation n’est pas toujours aisée. N’oublions pas non plus que le secteur des smartphones est tout récent, et offre du pain béni aux entreprises spécialisées en sécurité qui ont très souvent montré leurs limites (conflits d’intérêts, virus créés par leurs soins…).

Android a été bâti sur un modèle de sécurité solide et nous allons essayer de le démystifier (cet article essaie d’être le moins technique possible) :

Votre ordinateur : une porte ouverte

Sur votre ordinateur lorsque vous lancez une application, elle est exécutée par l’utilisateur courant. Par conséquent, si vous démarrez un jeu ou une application quelconque, vous lui donnez accès à l’ensemble de vos fichiers (et ses données potentiellement sensibles), votre historique Internet, votre bibliothèque photos et bien d’autres. Cela peut se révéler extrêmement dangereux, particulièrement chez les utilisateurs de Windows qui ont généralement les droits d’administrateur. On peut assister à un vol de données de manière extrêmement simple et transparente pour l’utilisateur.

Sur Android, l’écosystème fonctionne totalement différemment. Chaque application est lancée par un utilisateur différent, ce qui change alors drastiquement le modèle de sécurité mis en place. Android tire au maximum le modèle de sécurité utilisé dans GNU/Linux, c’est-à-dire celui des utilisateurs et des groupes.

Le modèle de sécurité de Linux

A chaque création d’un utilisateur, un userID (UID) est créé, tout comme pour les groupes avec les groups ID (GID).
Un utilisateur peut appartenir à 0 ou plusieurs groupes et un groupe peut avoir 0 ou plusieurs utilisateurs.

Une ressource (quasiment tout est fichier sur Linux) appartient à un utilisateur (généralement celui qui l’a créée) et à tout moment le propriétaire peut décider de modifier les permissions.

Plusieurs niveaux d’accès sont proposés : lecture (R) / écriture (W) / exécution (X) qui sont attribués à l’utilisateur, ou groupe, mais aussi au reste (un utilisateur qui n’appartient pas au groupe). Les trois niveaux d’accès sont indépendants les uns des autres : on peut avoir le droit d’écrire, sans la lecture, ou les deux par exemple.

Prenons deux utilisateurs A et B. A appartient au groupe G1 et B au groupe G2. Si la ressource appartient à l’utilisateur C et qu’il appartient au groupe G1, alors A aura les droits du groupe G1, tandis que B aura ceux du reste (other). Ces trois niveaux permettent ainsi d’avoir un modèle de sécurité fort, qui a fait ses preuves depuis de nombreuses années.

Le modèle de sécurité d’Android

Sur Android, ce concept est utilisé avec brio. Lorsque vous installez une application (qui n’est pas déjà présente sur le système), un nouvel userID est créé et l’application va lui être rattachée. Il en est de même pour l’ensemble des fichiers de l’applications : les images, les préférences, la base de données…, mais aussi l’accès au processus, à la mémoire et aux périphériques utilisés (GPS, Bluetooth…). Par conséquent seul cet utilisateur (et donc cette application) pourra avoir accès à ses éléments. Essayez par exemple d’ouvrir le fichier contenant les préférences depuis un navigateur de fichiers (type Astro) : vous n’y aurez pas accès, car ce n’est pas le même user ID. (Notez qu’il est possible pour un même développeur – même signature – d’avoir le même utilisateur pour ses applications, mais ce n’est pas le comportement par défaut).

Ce modèle a toutefois ses limites lorsque vous utilisez des cartes SD. En effet, il est beaucoup plus simple d’avoir accès au contenu, notamment depuis un périphérique tiers qui n’a plus connaissance des permissions. C’est pour cela, que les applications utilisent cet emplacement pour stocker des photos et des documents non sensibles, alors que les préférences, base de données… restent toujours sur la mémoire interne. C’est également l’une des raisons pour lesquelles Google ne propose plus de lecteur pour les cartes SD sur ses terminaux Nexus.

Pour ce qui est de la communication entre les processus, on retrouve le système mis en place sur le noyau Linux, qui protège même le code écrit en langage natif (pour rappel les applications Android sont codées en Java, mais du code natif en C/C++ peut lui être greffé).

Les permissions

De base une application dispose d’un accès très limité aux ressources du système. Cela permet par exemple de limiter les dégâts d’une attaque dans un navigateur par exemple, car seules les permissions demandées par le navigateur seront accessibles. Google a fait évoluer son système, car jusqu’à Android 1.5, il était par exemple possible d’écrire sur la carte SD sans en demander la permission.

Lors de l’installation d’une application l’utilisateur doit accepter entièrement les permissions demandées. Il n’est pas possible d’en sélectionner seulement certaines. De même, il est impossible de modifier ultérieurement les permissions utilisées. Si une application essaie d’utiliser des fonctions qui ne lui ont pas été accordées le système lui refusera tout simplement l’accès.

Ce système unique fait qu’Android est très innovant en la matière et va limiter les effets indésirables.

Dans un prochain article, nous vous expliquerons le rôle de chacune des permissions.

Le root : attractif, mais très (trop ?) dangereux

Sur tous les systèmes d’exploitation, il existe un super-utilisateur qui possède tous les droits. Sur les systèmes Unix, son nom est « root » (racine en anglais) et peut accéder à n’importe quelle ressource, quelle qu’en soient les permissions. Sans aucune restriction, il peut se révéler être une véritable bombe à retardement si on ne sait pas l’utiliser (un « rm -fr / » supprime par exemple tout le système de fichiers). Par conséquent, si un terminal Android n’est pas rooté lors de son achat, c’est avant tout pour protéger l’utilisateur.

Aujourd’hui de plus en plus d’utilisateurs décident de rooter leur téléphone (= obtenir les droits root), afin de débloquer certaines fonctionnalités. En voici quelques-unes :

• Supprimer les applications système (généralement les bloatwares)
• Utiliser des applications qui nécessitent des privilèges particuliers (les captures d’écran sur Android 1 et 2)
• Modifier la fréquence du processeur
• Améliorer l’autonomie en jouant sur certains paramètres
• Faire des sauvegardes et restaurations d’applications
• Changer le noyau Linux, utiliser des ROM customs
• Installer une version plus récente du système
• …

Lorsqu’on vous présente cette amélioration, on vous signale généralement deux dangers : la possibilité de bricker le téléphone (= le rendre inopérant) ou de perdre la garantie constructeur/opérateur (mais il est possible de dé-rooter).

Sauf que derrière ces dangers qui semblent pour beaucoup inoffensifs, il y en a d’autres bien plus dévastateurs. Donner les droits roots à une application, c’est lui permettre :

• D’accéder à vos données personnelles

Tout le système décrit auparavant pour limiter l’accès à la base de données et aux diverses ressources n’existe plus. Le super-utilisateur peut y avoir accès les yeux fermés. Que ce soit vos SMS, vos mails… ou votre compte en banque, il peut tout voir ! La cryptographie permet d’éviter que de telles données soient affichées en clair, mais tous les développeurs n’en font pas usage, selon le caractère de leur application.

• De modifier les permissions des applications

En étant root, le système de permissions est également mis à mal. Le super-utilisateur peut tout à fait demander de supprimer des permissions à une application. Cela semble plutôt bénéfique dans certains cas, mais le « root » peut aussi attribuer des permissions sans que vous ne vous en rendiez compte. C’est donc une arme à double tranchant qui reste la plupart du temps cachée, car à moins de vérifier par vous même le code exécuté par l’application, vous ne saurez jamais exactement son champ d’actions. Rooter son téléphone est avant tout dédié aux développeurs.

Nous allons toutefois relativiser ces propos en précisant que le système mis en place aujourd’hui demande à l’utilisateur avant d’attribuer à une application les droits de super-utilisateur.

Android 4.2 : du mieux

Voyant le nombre de malwares croître, Google a mis en place un système permettant de vérifier les applications sur le Play Store. Avant chaque publication d’une nouvelle apk, si un malware est détecté, l’application sera automatiquement supprimée. Toutefois ce système n’est pas sûr à 100% et n’est efficace que si les applications ont été téléchargées depuis la boutique de Google.

Or la force d’Android est de pouvoir installer du contenu depuis des Markets tiers (Amazon AppShop, YAAM…). Ce même système de détection de malwares est maintenant proposé directement par le système. Lors de l’installation, si Google pense que l’application est un malware, son installation sera tout simplement impossible. Si son contenu semble potentiellement dangereux, l’utilisateur en sera averti et il sera le seul juge de l’intérêt ou non de poursuivre la procédure.

Que peut-on conclure ?

Par conséquent dire qu’Android n’est pas un système sécurisé est une absurdité totale. Au contraire son système de permissions est extrêmement bien pensé et offre à l’utilisateur une vision bien plus claire des fonctions utilisées par l’application que sur n’importe quel autre système d’exploitation mobile.

Contrairement aux autres plateformes, les outils de vérifications de malwares ont leur limites et c’est à l’utilisateur de faire attention avant d’installer une application et se demander si les permissions demandées sont appropriées ou non. Pour ce qui est du root, la question reste extrêmement complexe et ne doit être utilisé que par des utilisateurs avancés.

Il reste toutefois une marge de progression, avec par exemple l’obligation pour les développeurs d’expliquer le rôle des permissions demandées (c’est ce que nous faisons par exemple avec l’application FrAndroid). Android ne pourra jamais basculer vers un modèle autoritaire comme sur l’AppStore, mais un mécanisme plus pointu de détection des malwares serait bienvenu.

Lors des rumeurs sur les fonctionnalités d’Android 4.2 (mais qui n’a finalement pas été intégré), nous parlions de la potentielle intégration de SELinux, qui permettrait d’apporter un niveau de sécurité supplémentaire. Du côté des développeurs, les mécanismes à mettre en place sont assez simples, mais encore faut-il qu’ils soient appliqués (cf vidéo à la Google I/O) !