Menaces et failles du système Android

Transcription

1 Projet d'approfondissement Menaces et failles du système Android Auteur : Carlo Criniti carlo@criniti.name Responsable : Pr. Markus Jaton markus.jaton@heig-vd.ch 10 juin 2011

2 EXECUTIVE SUMMARY Carlo Criniti Executive Summary Depuis quelques années, le marché des smartphones ne cesse de croître. Ce type d'appareils est vendu en plus grande quantité que les ordinateurs et le nombre de téléphones mobiles intelligents devrait bientôt dépasser le nombre d'appareils classiques. Android semble être le système le plus prometteur dans ce marché. Un pirate est habituellement motivé par deux facteurs, l'argent et les données. Avec les smartphones, il trouve les deux aspects sur la même cible. Les motivations d'attaquer ce type de téléphones ne manquent pas et cela s'en ressent au vu du nombre croissant de malwares développés et de vulnérabilités découvertes. Les problèmes majeurs de ces systèmes sont leur immaturité, la faible quantité de contrôles disponibles et mis en place ainsi que le manque de formation des utilisateurs. En eet, ceux-ci sont persuadés qu'un smartphone ne peut pas être attaqué et que les données qu'il contient sont protégées. Cette étude décrit les diérentes menaces auxquelles peuvent être soumis les utilisateurs de téléphones mobiles intelligents, en particulier sur Android. Pour ce faire, un threat model est développé. Celui-ci est général à l'utilisation d'android et doit être adapté en cas d'utilisation spécique. Parmi les menaces au risque le plus important, on peut citer l'accès logiciel aux données (en lecture ou en écriture), l'accès physique aux données, l'obtention d'informations personnelles non contenues dans l'appareil, la capture d'identiants d'authentication forte et l'exécution de services payants. Une société utilisant des smartphones doit connaître ces risques et décider d'un traitement adéquat pour ceux-ci. Il est important de réaliser que, bien qu'android soit un système relativement sûr s'il est mis à jour, l'utilisateur non formé représente la plus grande vulnérabilité exploitable. Un certain nombre de contre-mesures peuvent être mises en place pour réduire le risque de ces menaces. Les plus importantes sont la formation de l'utilisateur, l'utilisation d'un logiciel de sécurité (antivirus, administration à distance), le chirement des communications et des données ainsi qu'un verrouillage automatique du téléphone et une limitation des applications que l'utilisateur peut installer. Il y a également quelques précautions à prendre lors du développement d'applications Android. En eet, il est primordial de sécuriser les entrées/sorties de ces logiciels, que ce soit de la communication réseau ou IPC, ou simplement une lecture de chiers de données.

3 CONVENTIONS D'ÉCRITURE ET ABRÉVIATIONS Carlo Criniti Avant-propos Remerciements Je tiens à remercier le professeur responsable de cette étude, Monsieur Markus Jaton, pour son encadrement et sa disponibilité tout au long de ce projet, ainsi que les futurs lecteurs pour leur attention. Je souhaite également remercier Madame Amy Chabot pour sa patience et son soutien durant la réalisation de ce travail. Abréviations Les abréviations suivantes sont utilisées dans ce document : 3G 3rd Generation mobile telecommunications ADB Android Debug Bridge AES-CBC Advanced Encryption Standard - Cipher Block Chaining APK Android Package BTS Base Transceiver Station CSRF Cross-Site Request Forgery (D)DoS (Distributed) Denial of Service EXT4 Extended lesystem 4 FAT File Allocation Table GPS Global Positioning System GSM Global System for Mobile communications HTTP(S) Hypertext Transfert Protocol (Secure) IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IPC Inter-Process Communication MMS Multimedia Messaging Service MMU Memory Management Unit mtan mobile Transaction Authentication Number PIN Personal Identication Number PoC Proof of Concept RFS Robust File System RSA Rivest, Shamir and Adleman SDK Software Development Kit SDLC Software Development Life Cycle SHA Secure Hash Algorithm SIP Session Initiation Protocol SIM Subscriber Identity Module SMS Short Message Service SQL Structured Query Language SSL/TLS Secure Sockets Layer / Transport Layer Security URI Uniform Resource Identier VPN Virtual Private Network XSS Cross-site scripting

4 CONVENTIONS D'ÉCRITURE ET ABRÉVIATIONS Carlo Criniti Remarques Les captures d'écran utilisées dans ce document ont été réalisées sur un Samsung Galaxy S ainsi qu'un HTC Desire, tous deux équipés de Android 2.2 (Froyo). Les applications discutées dans ce travail sont accessibles grâce à l'adresse Internet fournie. De plus, des QRCode 1 sont également présents pour un accès facilité depuis le téléphone mobile. Ceux-ci peuvent être lus grâce une application telle que Barcode Scanner accessible aux adresses suivantes : QRCode :

5 TABLE DES MATIÈRES Carlo Criniti Table des matières 1 Introduction 7 2 Contexte 8 3 Problématique 10 4 Approche de l'étude 12 5 Limites de l'étude 14 6 Mécanismes de sécurité d'android Séparation des utilisateurs Accès aux chiers Unité de gestion mémoire (MMU) Langage typé Permissions des applications Signature des applications Déverrouillage par pattern Services et Internet Bluetooth Suppression et mise à jour d'applications à distance Assets A1 - Finances A2 - Equipement réseau, consommation réseau A3 - Fonctionnement du téléphone A4 - Intégrité des informations A5 - Informations condentielles A6 - Disponibilité des informations A7 - Informations environnementales A8 - Productivité Threat Agents TA1 - Pirate neutre TA2 - Entités ennemies TA3 - Ancien employé TA4 - Script Kiddie TA5 - Hasard Scénarios d'attaque SA1 - Abus de la conance de l'utilisateur SA2 - Utilisation d'une faille du système ou d'une application SA3 - Utilisation du téléphone par une personne tierce SA4 - Saturation de l'équipement réseau SA5 - Ecoute du réseau SA6 - Réception répétée de messages SA7 - Panne matérielle Menaces Risque critique M1 - Accès en écriture aux données du téléphone M2 - Accès en lecture aux données du téléphone Risque haut M3 - Accès physique aux données du téléphone M4 - Obtention d'informations personnelles M5 - Capture d'identiants d'authentication forte M6 - Exécution de services payants Risque moyen M7 - Exécution d'une activité réseau malveillante M8 - Espionnage des communications M9 - Accès à diérents capteurs M10 - Surveillance de l'activité utilisateur Risque faible

6 TABLE DES MATIÈRES Carlo Criniti M11 - Désactivation/altération de l'appareil ou de ses fonctions M12 - Dysfonctionnement du téléphone Note M13 - Réception de messages non désirés Vulnérabilités Vulnérabilités génériques V1 - Manque de formation de l'utilisateur V2 - Marché d'applications non able V3 - Abus de permissions V4 - Téléphone non verrouillé V5 - Absence ou mauvais chirement des données V6 - Communications non chirées V7 - Vulnérabilité du système ou d'une application V8 - Absence de quota par application V9 - Informations des rapports d'erreurs V10 - Contrôle du téléphone par connexion USB V11 - Facteurs externes Vulnérabilités découvertes Vulnérabilités du système Vulnérabilités du navigateur Vulnérabilités de l'android Market Vulnérabilités d'applications tierces Contre-mesures Utilisateur CM1 - Formation de l'utilisateur Applications de sécurité CM2 - Antivirus CM3 - Pare-feu CM4 - Anti-spam CM5 - Navigateur sécurisé CM6 - Virtualisation Réseaux et données CM7 - Chirement des communications CM8 - Chirement des données CM9 - Pas de données locales Processus CM10 - Verrouillage automatique CM11 - Déverrouillage sécurisé CM12 - Authentication forte CM13 - Context-aware access control CM14 - Blocage des numéros surtaxés CM15 - Procédure de destruction CM16 - Administration à distance CM17 - Liste blanche d'applications CM18 - Certication d'applications CM19 - Revoir la conguration du téléphone (Hardening) CM20 - Contrôle d'intégrité Fonctionnement du système CM21 - Permissions plus nes CM22 - Authentication avant une action critique CM23 - Gestion des ressources Applications de sécurité Lookout Mobile Security DroidCrypt Google Apps Device Policy VMware MVP (Mobile Virtualization Platform)

7 TABLE DES MATIÈRES Carlo Criniti 14 Secure coding Principes de sécurité Liste blanche / liste noire Minimiser la surface d'attaque Sécurité par défaut Echec contrôlé Moins de privilèges possibles Défense en profondeur Valider les entrées Eviter la sécurité par l'obscurité Simplicité Correction complète Séparation des rôles Règles de programmation sécurisée Enregistrement des données sensibles Utilisation SSL (TLS) Mises à jour Développement Android sécurisé Inter-process communication (IPC) Composants exportés Injection SQL Fichiers en mémoire interne et préférences Fichiers en mémoire externe Information dans les logs Utilisation du navigateur Publication d'application Logiciels didactiques SMiShing Fonctionnement Remarques Accès Explorateur de permissions Fonctionnement Remarques Accès Explications techniques Spyware And More Fonctionnement Remarques Accès Explications techniques Dicultés de l'étude Etudes complémentaires Evolution temporelle d'android Modications constructeurs/opérateurs Elévation de privilèges Autres plateformes Développement de certaines contre-mesures Conclusion 70 A Présentation détaillée des menaces 71 A.1 M1 - Accès en écriture aux données du téléphone A.2 M2 - Accès en lecture aux données du téléphone A.3 M3 - Accès physique aux données du téléphone A.4 M4 - Obtention d'informations personnelles A.5 M5 - Capture d'identiants d'authentication forte A.6 M6 - Exécution de services payants

8 TABLE DES MATIÈRES Carlo Criniti A.7 M7 - Exécution d'une activité réseau malveillante A.8 M8 - Espionnage des communications A.9 M9 - Accès à diérents capteurs A.10 M10 - Surveillance de l'activité utilisateur A.11 M11 - Désactivation/altération de l'appareil ou de ses fonctions A.12 M12 - Dysfonctionnement du téléphone A.13 M13 - Réception de messages non désirés B Permission Explorer 84 B.1 Fonctionnement B.2 Séparation du code B.3 Base de données

9 TABLE DES FIGURES Carlo Criniti Table des gures 1 Croissance du pourcentage de téléphones mobiles intelligents en France Croissance par trimestre des logiciels malveillants sur les périphériques mobiles Description d'une menace Evolution des versions d'android Diérents types de permissions des applications Ecran de déverrouillage, mauvais schéma et schéma correct Permissions du navigateur Android (émulateur 2.2) Permissions à l'installation de Google Maps Permissions à l'installation de Barcode Scanner Lookout Mobile Security : Analyse complète et analyse à l'ajout d'un logiciel Lookout Mobile Security : Privacy Advisor Diérentes versions du logiciel Lookout Mobile Security Lookout Mobile Security sur l'android Market DroidCrypt sur l'android Market DroidCrypt : Menu et déchirement DroidCrypt : Fichiers en clair et chiers chirés Google Apps Device Policy : Administration Google Apps Device Policy sur l'android Market Microsoft Security Development Lifecycle Version HTC Hotspot WiFi : Conguration par défaut Tentative de SMiShing QRCode PoC SMiShing Permission Explorer : Vue par catégorie et détails d'une catégorie Permission Explorer : Vue par application et détails d'une application Permission Explorer : Vue par permission et détails d'une permission QRCode Permission Explorer SAM : Installation SAM : Connexion d'un nouveau client SAM : Messages publiques SAM : Messages privés Permission Explorer : Base de données

10 LISTE DES TABLEAUX Carlo Criniti Liste des tableaux 1 Calcul du risque d'une menace Menace M1 : Accès en écriture aux données du téléphone Menace M2 : Accès en lecture aux données du téléphone Menace M3 : Accès physique aux données du téléphone Menace M4 : Obtention d'informations personnelles Menace M5 : Capture d'identiants d'authentication forte Menace M6 : Exécution de services payants Menace M7 : Exécution d'une activité réseau malveillante Menace M8 : Espionnage des communications Menace M9 : Accès à diérents capteurs Menace M10 : Surveillance de l'activité utilisateur Menace M11 : Désactivation/altération de l'appareil ou de ses fonctions Menace M12 : Dysfonctionnement du téléphone Menace M13 : Réception de messages non désirés

11 1 INTRODUCTION Carlo Criniti 1 Introduction L'objectif de cette étude est de comprendre les risques encourus par une utilisation des smartphones (en particulier équipés du système Android) dans un cadre professionel. Le travail débute par une explication de la problématique de l'utilisation de ce type d'appareils. En eet, de nombreuses sources 2 annoncent que l'année 2011 sera marquée par des attaques ayant pour cible les appareils mobiles (en particulier Android et iphone), il est alors intéressant d'en comprendre les raisons. Les diérents mécanismes assurant une partie de la sécurité d'android sont ensuite présentés an de comprendre le fonctionnement de ce système et les bases sur lesquelles il repose. Une grande partie de ces mécanismes sont hérités du noyau Linux qui est à la base du système Android. Un threat model de l'utilisation d'android est ensuite développé. Celui-ci n'est pas lié à un cas d'utilisation particulier mais plutôt général au système Android. De ce fait, les assets et les threat agents sont généraux. Ce modèle sert de base et pourra être adapté à un cas particulier ou à une entreprise spécique. Il sut alors de contrôler les sources et assets des menaces (et éventuellement en ajouter certains) et repondérer la probabilité ainsi que la gravité des menaces. Il sera alors nécessaire de choisir une méthode de traitement pour chacun des risques. Les menaces sont suivies d'une liste de vulnérabilités divisée en deux parties. La première traite de vulnérabilités génériques, pas forcément liées au système Android mais à tous les smartphones. La seconde liste un certain nombre de vulnérabilités récemment découvertes dans le système Android. Ces menaces et vulnérabilités étant présentées, il est intéressant d'avoir une liste de contremesures expliquant comment s'en protéger. Il est possible de mettre en oeuvre certaines de ces contre-mesures grâce à des applications existantes (dont certaines sont présentées dans la section applications de sécurité) alors que d'autres nécessitent un développement ou une modication du système. Une liste de certains principes de secure coding est ensuite présentée. En eet, un système bien protégé mais contenant des applications mal développées et possédant un certain nombre de vulnérabilités n'ore aucune sécurité. Cette section se décompose également en deux parties, la première présentant des principes de sécurité pour du développement en général alors que la seconde est spécique au système Android. Ce travail se termine par une présentation de quelques logiciels didactiques servant à mettre en avant les éventuels problèmes auxquels il est nécessaire d'être attentif. 2. On peut notamment citer Cisco [2], McAfee [10] et Panda [16]. 7

12 2 CONTEXTE Carlo Criniti 2 Contexte Ces dernières années, le monde de l'informatique et des télécommunications a connu une évolution notable. Depuis l'arrivée de l'iphone d'apple, le marché des téléphones mobiles intelligents n'a cessé de croître et n'est désormais plus limité aux professionnels. En eet, un grand nombre de particuliers s'équipent aujourd'hui de ce type de téléphones ce qui en fait un marché très intéressant pour les pirates [10]. L'arrivée et le succès d'apple sur le marché de la téléphonie a intéressé d'autres sociétés telles que Google. Celle-ci a suivi en créant son système d'exploitation Android en partenariat 3 avec de nombreux fabricants et opérateurs. Android devenant de plus en plus connu, il a commencé à apparaitre sur d'autres types d'appareils que des téléphones. Les tablettes tactiles et les télévisions 4 sont des marchés ociellement supportés par Google, mais on peut également trouver le système dans des autoradios 5, des ordinateurs 6 ou des cadres photos numériques 7. Depuis le début de l'année 2011, il se vend plus de smartphones que d'ordinateurs 8 (xes ou mobiles). De plus, comme le montre la gure 9 1 en page 8, le pourcentage de téléphones mobiles intelligents par rapport aux téléphones mobiles classiques n'a cessé de croître pour atteindre environ 31% au premier trimestre 2011, en France. Le cabinet Parks Associates (spécialiste en études de marché) estime d'ailleurs que le nombre de smartphones passera de 500 millions en 2010 à 2 milliards en Le système Android, qui a pris la tête du marché des smartphones n avec environ 33% de parts de marché, semble le plus prometteur. Selon certains analystes 11, il atteindra 45% de parts de marché en Figure 1 Croissance du pourcentage de téléphones mobiles intelligents en France Par ailleurs, on cone de plus en plus de tâches aux téléphones mobiles. Alors qu'ils ne servaient qu'à téléphoner et envoyer des messages il y a quelques années, ils gèrent maintenant notre agenda, 3. Open Handset Alliance : 4. Il est intéressant de noter qu'en 1991, Mark Weiser prédisait ces formats pour les appareils informatiques du XXIème siècle, on y retrouve d'ailleurs, tant pour Google qu'apple, un produit dans chacune des trois catégories (Tabs : téléphones Android / iphone, Pads : tablettes Android / ipad, boards : télévisions, Google TV / Apple TV) Parrot Asteroid : 6. Toshiba AC100 : 7. Parrot Grande Specchio : 8. Selon l'idc : 9. Source (Mediametrie.fr) : Selon l'analyste Canalys : IDC : 8

13 2 CONTEXTE Carlo Criniti notre messagerie électronique, notre itinéraire, nos cartes de crédits, nos documents professionnels voire même notre santé 12. On peut nalement noter que les deux plus grands acteurs de ce marché ont une vision opposée du point de vue des sources de leurs produits, ce qui inuence leur sécurité 13. En eet, alors que Google publie une grande partie du code source d'android de façon publique et libre, Apple préfère conserver le secret sur son code. 12. Surveillance du corps avec un téléphone Android : Selon Kerckhos, la sécurité d'un système ne doit pas être basée sur le secret de sa source : 9

14 3 PROBLÉMATIQUE Carlo Criniti 3 Problématique Il est clair que les plus grandes motivations du piratage sont l'argent et les données, bien que les deux soient souvent liés. Concernant l'aspect nancier, les smartphones sont une cible intéressante. En plus des revenus connus du piratage informatique qui sont aussi applicables aux smartphones (envoi de spam, attaques ciblées, vente de virus, vol d'informations privées,...), on peut aussi eectuer des appels, envoyer des SMS surtaxés ou simplement générer du spam par SMS. Ces moyens demandent peu d'investissement et peuvent rapporter beaucoup. Les premières attaques de ces systèmes étaient des chevaux de Troie installables par les applications stores [17]. On peut maintenant constater que les pirates adaptent l'ensemble de leurs pratiques informatiques à l'environnement mobile 14 et recherchent activement des failles pour pénétrer dans ces systèmes sans action de l'utilisateur. McAfee prévoit notamment l'apparition de réseaux de robots ( botnets) basés sur des téléphones mobiles [10]. La deuxième motivation des pirates citée au début de cette section existe également avec les téléphones mobiles. En eet, un grand nombre d'informations condentielles (ou privées) sont stockées dans ces appareils sans que l'utilisateur n'ait conscience du nombre de menaces qui s'y rapportent. On peut aussi ajouter que les systèmes qui équipent les téléphones mobiles et les tablettes assurent une portabilité des applications (et donc des malwares) entre les plateformes, ce qui implique des risques encore plus importants et des cibles toujours plus nombreuses. On remarque donc que la motivation du piratage ne manque pas, et comme nous le montre la gure 2 réalisée par McAfee, le nombre de logiciels malveillants mobiles a connu une augmentation de 46% entre 2009 et 2010 [11]. Juniper Networks (société spécialisée en équipements de télécommunication) ont, quant à eux, estimé une croissance de 400% des nouveaux malwares Android entre juin 2010 et janvier 2011 [14]. Figure 2 Croissance par trimestre des logiciels malveillants sur les périphériques mobiles Avec le temps, les utilisateurs ont compris que les ordinateurs n'étaient pas sûrs et qu'il était nécessaire de les protéger (antivirus, pare-feu, comportement "prudent"). Ce n'est pas (encore) le cas avec les téléphones mobiles. Aux yeux d'une personne non sensibilisée, un téléphone ne peut pas recevoir de virus ou être piraté (51% des utilisateurs pensent que leur ordinateur peut être infecté par un malware contre 27% seulement dans le cas du smartphone 15 et seulement 15% des utilisateurs de smartphones utilisent un logiciel de protection [14]). Le téléphone est vu, à tort, comme un appareil dans lequel on peut avoir conance alors qu'il contient probablement plus d'informations sensibles qu'un ordinateur. Par exemple, la probabilité de se faire voler ou de perdre son téléphone mobile est bien plus importante 16 qu'avec son ordinateur et ils sont plus rarement protégés par un mot de passe. 14. It took computer viruses over twenty years to evolve, and mobile viruses have covered the same ground in a mere two years. Source : Source : En Angleterre, 2% des utilisateurs de téléphone mobiles ont déclaré avoir été victime d'un vol en [13] 10

15 3 PROBLÉMATIQUE Carlo Criniti De plus, avec l'arrivée des smartphones auprès du grand public, la frontière entre le téléphone privé et le téléphone professionnel tend à disparaître. Certaines sociétés autorisent leurs employés à utiliser leur téléphone privé comme téléphone professionnel et celui-ci aura peut-être des accès au réseau interne de l'entreprise ou enregistrera des données condentielles. Dans ces cas, il est nécessaire de se poser certaines questions concernant la sécurité de l'appareil. A contrario, avec un téléphone doté de fonctionnalités ludiques et l'accès à des marchés d'applications et de jeux, l'entreprise a-t-elle une garantie que l'utilisateur n'emploie pas son téléphone professionnel à des ns privées? Elle est probablement informée que l'utilisateur possède des documents condentiels sur son téléphone professionnel, mais est-elle avertie susamment rapidement si le téléphone est compromis ou perdu? A-t-elle des moyens pour limiter les conséquences d'un vol? Si le téléphone possède un accès VPN au réseau de l'entreprise, celui-ci pourrait être intégralement compromis par le simple vol du téléphone d'un employé. On peut aussi ajouter que le nombre de vecteurs d'attaque est bien plus important sur les téléphones mobiles que sur les ordinateurs. Une attaque peut, en eet, être faite via diérents moyens de connexion que ne possède pas forcément l'ordinateur (3G, WiFi, Bluetooth,...). Un problème existe également au niveau du développement. La concurrence et l'innovation imposent des cycles de développement plus courts aux programmeurs qui doivent terminer leur travail plus rapidement. Certains contrôles de sécurité se retrouvent certainement bâclés, volontairement ou non, pour que la société soit la première à sortir un produit ou une nouvelle fonctionnalité. Les problèmes seront (peut-être) corrigés plus tard. Partant de ces constats, on remarque qu'il y a un certain nombre de précautions à prendre lors de l'utilisation de ces appareils (surtout dans un cadre professionnel, mais aussi pour une utilisation privée) et qu'une étude des menaces (susceptibles d'évoluer avec le temps) est nécessaire. Les systèmes mobiles orent de grandes opportunités aux pirates compte tenu des faibles protections mises en place, de leur immaturité, ainsi que du manque de sensibilisation des utilisateurs. 11

16 4 APPROCHE DE L'ÉTUDE Carlo Criniti 4 Approche de l'étude Ce travail est essentiellement réalisé grâce à l'étude de diérentes analyses et rapports de sécurité. Il concerne un cadre d'utilisation professionnelle des smartphones Android, mais les entreprises (ou leurs employés) sont également susceptibles de subir les problèmes dus à l'usage privé du téléphone (disparition de la frontière entre le téléphone privé et professionnel citée à la section 3 en page 10). La première partie de ce travail, mécanismes de sécurité d'android, permet de comprendre quelques points forts du système. Les parties suivantes regroupent les diérents éléments du threat modeling : Assets Les assets représentent les diérents biens, physiques ou non, qui ont une certaine valeur pour la victime. Threat agents Les threat agents sont les diérentes sources qui peuvent être à l'orgine des menaces. Scénarios d'attaque Les scénarios (ou vecteurs) d'attaque présentent les diérentes méthodes permettant de mettre en oeuvre les menaces. Menaces Les menaces peuvent être décrites comme suit : Any circumstance or event with the potential to adversely aect a system through unauthorized access, destruction, disclosure, or modication of data, or denial of service [7]. La gure 3 établie par l'owasp 17 permet de décrire une menace partant du pirate ou des threat agents, passant par la vulnérabilité (security weakness) pour nir sur les assets. Cette gure illustre les diérents éléments de l'analyse eectuée. Figure 3 Description d'une menace Les menaces, classées par importance du risque, sont présentées par une brève description et un exemple. Une description plus complète avec les vulnérabilités et les contre-mesures liées est disponible à l'annexe A en page 71. On trouve ensuite une liste de vulnérabilités des systèmes mobiles. Elles peuvent être dénies comme suit : A aw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy [7]. Cette section est divisée en deux parties. Une première partie décrit des vulnérabilités générales et non spéciques à Android alors que l'autre présente celles qui ont été découvertes sur ce système. Etant connues, elles devraient en principe être corrigées dans les nouvelles versions. Elles permettent de mettre en oeuvre certaines des menaces présentées. Les menaces et vulnérabilités étant dénies, une liste de contre-mesures pour limiter ces risques est présentée. La diculté d'application de ces contre-mesures est variable. Cela peut être le simple fait de prévenir un utilisateur d'une action non recommandée au développement ou à la modication de logiciels du téléphone. Certaines applications permettant d'appliquer ces contre-mesures sont ensuite présentées. 17. Source : 12

17 4 APPROCHE DE L'ÉTUDE Carlo Criniti L'étude se termine par des principes de secure coding pour applications mobiles et Android ainsi qu'une présentation de quelques logiciels didactiques démontrant certains problèmes auxquels peuvent être soumis les utilisateurs de téléphones Android. Ces logiciels pourront sensibiliser tant l'utilisateur de base qui n'utilise son téléphone Android dans un cadre privé et ludique que l'utilisateur professionnel qui y enregistre ses rendez-vous et partenaires commerciaux. 13

18 5 LIMITES DE L'ÉTUDE Carlo Criniti 5 Limites de l'étude Cette étude est limitée aux téléphones mobiles de type smartphones équipés du système Google Android. Les autres systèmes d'exploitation ne sont pas étudiés dans ce travail. Le choix s'est porté sur Android au vu de ses parts de marchés, de plus en plus importantes, et non suite à des à prioris concernant sa sécurité comparée à d'autres systèmes. Le système Android connait une mise à jour majeure tous les 3 à 6 mois. Cette vitesse de mise à jour, bien qu'avantageuse dans certains cas, s'avère ennuyeuse pour le développement d'applications avec une compatibilité maximale ou une étude du système. Les dernières versions d'android ayant atteint une certaine maturité, l'arrivée de nouvelles versions s'est ralentie et s'approche plutôt des 6 mois. Ce document traite principalement de la version 2.2 (Froyo) d'android. Cette version est la plus fortement déployée au moment du travail comme le démontre la gure 4 provenant de la documentation d'android 18. Figure 4 Evolution des versions d'android Bien qu'android 2.3 (ou 2.3.x, Gingerbread) soit en cours de déploiement lors de l'étude, sa présence sur le marché reste relativement faible et un certain temps sera nécessaire pour que celui-ci atteigne la popularité de la version 2.2. La version 3 (Honeycomb) a également été publiée. Etant réservée aux tablettes tactiles, celle-ci ne sera pas traitée dans ce document. Bien qu'une grande partie du code source d'android soit disponible au public, aucune analyse de celui-ci ne sera réalisée. Cela se justie par le faible intérêt que représente un tel travail, accompli de façon bien plus élaborée et plus exhaustive par des organisations professionnelles. La disponibilité du code source d'android ainsi que les libertés accordées par Google pour sa modi- cation engendrent un grand nombre de versions modiées du système. La plupart des fabricants appliquent des modications au système avant d'équiper leurs appareils et on trouve également des versions modiées par des groupes de développeurs tels que Cyanogen 19. Ce travail se base sur une version "originale" du système Android que l'on retrouve par exemple sur les téléphones de la gamme Google Nexus. L'élévation de privilèges (root sur Android ou jailbreaking sur iphone OS) peut ajouter un certain nombre de problèmes de sécurité aux systèmes qui ne sont pas prévus pour cette utilisation. En eet, bien que ce procédé soit assez répandu 20, il permet de contourner certains principes de base de la sécurité de ces systèmes tels que le contrôle des signatures des applications et du code. L'étude ne traite pas des éventuels problèmes ajoutés aux diérents systèmes conséquents à cette élévation des privilèges. 18. Source : Cyanogen : Jay Freeman, créateur de Cydia (applications store alternatif pour iphone jailbreakés), estime à 10% le taux d'iphones ayant subit une élévation de privilèges. Source : 14

19 6 MÉCANISMES DE SÉCURITÉ D'ANDROID Carlo Criniti 6 Mécanismes de sécurité d'android Android implémente nativement quelques mécanismes qui orent un certain niveau de sécurité sans modications nécessaires. Ils sont dus à la construction du système Android. Celui-ci repose principalement sur le noyau Linux 21 (gestion du matériel, de la mémoire, des processus et du réseau). Le niveau suivant est composé des librairies natives d'andoid qui sont ensuite appelées par des interfaces natives Java. Le niveau suivant est caractérisé par la machine virtuelle Dalvik (exécutables.dex prévus pour être plus compacts et ecaces que les.class Java) et les core libraries (qui fournissent un sous-ensemble des paquetages Java 5 SE et certaines librairies spéciques à Android). Finalement, on retrouve les applications Android sous forme d'apk (conteneur équivalent au.jar de Java) contenant les ressources exécutables et non exécutables (images, Manifest,...). Les mécanismes de sécurité du système Android proviennent de cette construction du système. 6.1 Séparation des utilisateurs Chaque application Android (APK) qui est installée sur le système possède un identiant d'utilisateur unique. Cela permet le sandboxing de chaque application et l'empêchement de toute interaction (ou interférence) avec les autres 22. Ceci empêche à un jeu d'accéder à l'historique du navigateur par exemple. 6.2 Accès aux chiers L'accès aux chiers sur Android repose sur le noyau Linux et son système de chier EXT4 23, ce qui le rend dépendant des permissions Linux (chaque chier est caractérisé par l'identiant de l'utilisateur et du groupe qui l'a créé en plus de tuple Read-Write-eXecute). En tenant compte du point précédent spéciant que chaque application est assignée à un utilisateur unique, une application donnée ne peut accéder aux chiers spéciques d'une autre application (on ne tient pas compte ici des applications système ayant des droits particuliers). Grâce encore une fois à la base Linux, le matériel est également géré comme des chiers (pseudo-les). L'accès au matériel peut donc aussi être régulé grâce à ce système de permissions. A noter que le système de chiers de la carte SD étant FAT32, les chiers qu'elle contient ne sont pas soumis aux mêmes contrôles. Pour plus d'informations, voir la section en page Unité de gestion mémoire (MMU) Linux (et donc Android), comme la plupart des systèmes d'exploitation modernes, utilisent une unité de gestion d'accès mémoire permettant la séparation des processus dans des espaces mémoires diérents, ce qui empêche une application d'accéder à l'espace mémoire d'une autre application. 6.4 Langage typé Le développement d'applications Android est principalement réalisé en Java, langage fortement typé. Ceci nous permet de nous protéger automatiquement de certaines erreurs de programmation pouvant entraîner, entre autre, des buer overows et donc de l'exécution de code arbitraire. 21. En partant de ce constat, la société Coverty a estimé grâce à une analyse de code statique qu'android (Froyo sur HTC Droid Incredible) avait 50% de défauts en moins que prévu pour un logiciel de cette taille. Le code spécique à Android, quant à lui, contient deux fois plus de défauts que le code du noyau Linux. [3] 22. Si le développeur le souhaite, il peut contourner ce principe grâce à la propriété shareduserid : EXT4 est le système de chier des téléphones de type Google Nexus. En fonction du fabricant, ce type peut changer (par exemple, le Samsung Galaxy S est formaté en RFS, système de chier développé par le fabriquant lui-même). 15

20 6 MÉCANISMES DE SÉCURITÉ D'ANDROID Carlo Criniti 6.5 Permissions des applications Lors de leur installation, les applications doivent demander des permissions pour eectuer certaines actions considérées comme sensibles (utiliser le téléphone, le GPS, accéder à Internet,...). Les permissions nécessaires au fonctionnement de l'application doivent être inscrites dans le chier Manifest accompagnant celle-ci. Il y a quatre catégories de permissions Android : normal, dangerous, signature et signatureorsystem. Seuls les deux premiers types sont traités ici, et une dénition plus complète de chacun d'eux est disponible dans la documentation 24 Android. Les permissions de niveau normal sont automatiquement accordées à l'application sans nécessiter l'approbation de l'utilisateur (bien qu'il puisse quand même les consulter). Les permissions de type dangerous nécessitent par contre un accord de la part de l'utilisateur lors de l'installation de l'application. La gure 5 en page 16 présente les diérents types de permissions d'une application. Lors de l'achage classique, seules les permissions de type dangerous sont communiquées. Dans l'achage détaillé, les permissions dangerous sont présentées en orange, auxquelles se joignent les permissions de niveau normal. L'autorisation des permissions est demandée à l'utilisateur si l'application est installée depuis le téléphone. Dans le cas d'une installation depuis l'ordinateur en utilisant l'interface ADB, aucun écran de permission n'avertit l'utilisateur. De plus, dans le cas d'une installation depuis le site Internet 25 de l'android Market, une conrmation est requise sur le navigateur eectuant la demande d'installation mais pas sur le téléphone. Figure 5 Diérents types de permissions des applications Une fois le logiciel installé, ses permissions ne peuvent pas changer sans réinstallation ou mise à jour de celui-ci. Si, lors de la mise à jour, les permissions de l'application ont été modiées, l'utilisateur doit à nouveau donner son accord pour son installation (mise à jour automatique impossible). Le système de permissions permet de limiter l'impact des logiciels malveillants pour autant que celui-ci ne puisse pas être contourné et que l'utilisateur n'autorise pas d'applications douteuses. Android utilise les chiers Manifest pour savoir quelles permissions ont été accordées par l'utilisateur (permissions que l'utilisateur avait acceptées à l'installation du logiciel). Une application 24. Types de permissions Android : Android Web Market : 16