2.3
Limites des mécanismes de sécurité Android
2.3.1
Abus de permission
Les permissions donnent accès aux ressources sensibles du téléphone aux applications. Si l’utilisateur souhaite installer une application, il doit lui accorder toutes les permissions qu’elle a demandées. Si les permissions filtrent l’accès aux ressources sensibles, il n’existe cependant aucune vérification au niveau de l’usage de ces ressources. Seule la confiance aux développeurs de l’application permet de s’assurer qu’il n’y aura aucun abus. Les attaques les plus simples utilisent ainsi les permissions de manière abusive et c’est le cas de la plupart des malware ayant pour but de faire fuir des données sensibles du téléphone. Un exemple récent est une application ayant été détectée comme un logiciel espion4
qui cible des manifestants à Hong Kong [26]. L’application demande un ensemble assez large de permissions pour espionner les utilisateurs des téléphones sur lesquels l’application est installée. Les permissions demandées donnent accès aux SMS, aux appels, à la localisation de l’utilisateur, au micro pour enregistrer l’utilisateur, etc.
Une application avec trop de permissions peut paraître suspecte aux yeux des utilisateurs avertis. Afin de ne pas éveiller la suspicion des utilisateurs, une solution pour les développeurs de malware consiste à utiliser d’autres applica- tions présentes sur le système pour mener l’attaque ou à diviser l’attaque entre plusieurs applications qui collaboreront pour exécuter l’attaque.
2.3.2
Permissions : attaques par délégation et attaques
par collusion
Une attaque par délégation [49] consiste à déléguer l’exécution de la tâche nécessitant une permission que l’application malveillante ne possède pas à une autre application qui elle la possède. Par exemple, une application n’ayant pas la permission de communiquer sur le réseau pourrait se servir du navigateur pour poster des informations ou télécharger des fichiers. Les échantillons de BadNews [91] font par exemple appel au navigateur du téléphone afin de lan- cer le téléchargement d’applications sur le téléphone. Une attaque par collusion consiste en une coopération entre plusieurs applications pour mener une attaque. Il n’existe aucun malware utilisant ce type d’attaque à notre connaissance. Ce- pendant, J. Boutet et T. Leclerc ont montré la faisabilité d’une telle attaque dans [28].
2.3.3
Communication entre composants via les intents
Les intents sont des messages échangés entre les composants des appli- cations pour transmettre des requêtes. La possibilité d’envoyer des intents entre deux deux composants de deux applications différentes apporte une sur- face d’attaque supplémentaire. Dans [34], Chin et al. décrivent en se basant sur
leur analyse du fonctionnement des întents des scénarios d’attaques qui pour- raient exploiter cette surface d’attaque afin d’espionner les échanges de message entre application, les bloquer, les modifier, élever ses privilèges et influencer sur le comportement d’une application.
Interception des messages diffusés dans le système
Les broadcast intents sont des messages diffusés dans tout le système. Ils peuvent ainsi avoir un ou plusieurs destinataires. L’une des vulnérabilités qu’introduit ce type de communication est la possibilité d’observer les infor- mations diffusées dans le système et éventuellement les intercepter, bloquer ou modifier. Lorsqu’une application diffuse un broadcast intent, elle définit un ensemble d’attributs qui permettent au système d’identifier les composants BroadcastReceiver présents dans le système qui attendent ce type de mes- sage. Pour observer les messages attendus par le composant BroadcastReceiver d’une application, il suffit ainsi à une application malveillante de déclarer un composant du même type avec le même intent-filter. Pour observer les mes- sages reçus par le composant BillingReceiver déclaré dans le listing 2.2, une application malveillante n’a qu’à déclarer un composant du même type en préci- sant que ce composant n’accepte que les intents avec un attribut action dont la valeur associée est com.android.vending.billing.RESPONSE_CODE.
Un broadcast intent peut être transmis de manière simultané à tous les destinataires ou en suivant un ordre. Dans le cas de ce dernier, l’intent est transmis d’un composant à l’autre dans un ordre défini par le système. Chaque composant BroadcastReceiver peut ainsi modifier ou bloquer les informations transmises avant que le message ne soit transmis au prochain destinataire. Si une application malveillante se trouve au milieu de la chaîne de transmission, elle peut donc modifier le contenu de l’intent émis et envoyer de fausses données aux composants en attente du message. Elle peut également décider de ne pas faire suivre le message et empêcher les autres composants de le recevoir. Détournement des intents à destination des composants Activity et Service
Lorsqu’une application émet un intent, il peut soit définir explicitement le destinataire soit laisser le système le définir à sa place. Dans le deuxième cas, l’émetteur n’a aucune garantie sur l’identité du destinataire ce qui donne ainsi la possibilité de détourner les messages du destinataire légitime. Une application malveillante souhaitant intercepter un implicit intent n’a donc qu’à déclarer un composant ayant un intent filter correspondant à l’intent qu’il souhaite détourner. Par exemple, une application malveillante souhaitant détourner le partage de page effectuée dans le listing 2.1 n’a qu’à déclarer un composant Activity avec un intent filter correspondant aux attributs de l’intent à intercepter : un attribut action et un attribut data auxquels sont associés respectivement les valeurs ACTION_SEND et text/plain.
2.3. LIMITES DES MÉCANISMES DE SÉCURITÉ ANDROID 23 Si le détournement est théoriquement possible, il n’a en réalité qu’une proba- bilité de succès. Lorsqu’il existe plusieurs destinataires possibles de l’intent, un choix qui est indépendant de l’application malveillante est effectué. Si l’intent a été émis pour un composant de type Activity, le système demande à l’utili- sateur de choisir le destinataire parmi la liste des applications pouvant recevoir l’intent. Si l’intent a été émis pour un composant de type Service, le système effectuera lui-même le choix et ce choix est effectué de manière aléatoire. Vol/abus des permissions
Nous avons écrit en section 2.1.2.2 que les intents pouvaient également servir à transmettre des permissions pour accéder à des données au destinataire du message. Positionner le flasg FLAG_GRANT_WRITE_URI_PERMISSION donne par exemple l’accès en lecture aux données liées à l’intent au destinataire du message. Une application malveillante interceptant des intents transmettant des permissions peut ainsi abuser de ces permissions et voler ou modifier les données auxquelles les permissions donnent accès.
Intents malveillants
Le but de cette attaque est d’envoyer des requêtes malveillantes à traiter par un composant cible. Un composant qui peut recevoir des intents d’autres appli- cations n’est pas seulement exposé aux applications que son développeur pensait servir mais à toutes applications sur le système. Cette exposition à toutes les applications du système offre ainsi une surface d’attaque aux applications mal- veillantes qui elles aussi peut demander au composant de traiter une requête, même si cette requête est malicieuse. Les navigateurs web sous Android ont par exemple un composant Activity qui ouvre les URL à la demande d’autres ap- plications. Cette fonctionnalité peut ainsi être détournée par une application qui n’a pas accès au réseau afin de faire fuir des données ou télécharger des fichiers. Pour cela l’application malveillante émettra un intent à destination du naviga- teur afin que ce dernier ouvre une adresse web. Les échantillons de BadNews [91] utilisent par exemple cette approche afin de télécharger des applications sur le téléphone.
2.3.4
Failles logicielles : élévation de privilège
Comme tout programme, le système Android a également des failles logi- cielles. Exploiter certaines d’entre elles permet d’élever les privilèges d’une ap- plication et ainsi exécuter des opérations sensibles que nous ne pouvions faire. Obtenir les droits root permet par exemple de modifier le contenu de la partition systemsous Android pour installer des applications système ou les remplacer.
Le noyau Android étant basé sur un noyau Linux, il hérite ainsi de ses vulnérabilités. Certaines d’entre elles [5, 4] ont par exemple été exploitées obtenir des accès root sur les téléphones.
Des failles permettant d’élever les privilèges des applications existent égale- ment dans l’espace utilisateur. D’après les travaux de Y. Zhou et X. Jiang [113], six vulnérabilités permettant d’élever les privilèges des applications existaient au moment de leur analyse (voir tableau 2.2) et quatre d’entre elles étaient ef- fectivement utilisées par les malware pour élever leurs privilèges : Asroot [1], exploid [31], RATC / Zimperlich [93] et GingerBreak [32]. Plus récemment, J. Forristal a présenté à la Black Hat 2013 une vulnérabilité [51] concernant la vérification des signatures des applications Android à l’installation. La vulnéra- bilité permet d’installer une version modifiée d’une application dont la signature reste celle de la version originale. Si la vulnérabilité ne permet pas d’obtenir les droits root (aucune application ne tourne avec l’UID root), elle rend cependant caduque les protections offertes par la signature en section 2.2.2. Un développeur malveillant peut faire exécuter son code avec les mêmes droits que l’application originale qu’il a modifiée. Il peut également faire tourner son code dans le même processus ou avec le même UID qu’une autre application. S’il n’est pas pos- sible d’obtenir les droits root, il est cependant possible d’obtenir les droits des applications system. Ces applications ont accès à plus de permissions que les applications tierces et de plus sont persistantes sur le système. Un utilisateur ne peut les enlever sans avoir un accès root sur son téléphone.
Bien que Google mette à jour régulièrement le code d’Android, les construc- teurs eux mettent plus de temps à proposer des mises à jour pour leur téléphone. La fenêtre d’exploitation des vulnérabilités est ainsi bien plus large que sur les ordinateurs.
Nous avons présenté dans cette section, les limitations des mécanismes de sécurité sous Android. Ces limitations peuvent être classées en trois groupes. Le premier groupe concerne les limites de la sécurité offerte par les permissions. Le second concerne les risques introduits par les communications entre composants via les intents. Le troisième groupe concerne les failles logicielles dans le code d’Android qui permettent d’élever les privilèges des applications dans le système. Dans la section suivante, nous présentons les malware Android et les menaces qu’ils représentent.