Sécurité du système android

Le marché des Smartphones et tablettes s’étend de plus en plus chaque jour. L’évolution de ces appareils et l’augmentation de la demande des utilisateurs, poussent les développeurs à migrer de plus en plus vers le développement relié à ces plateformes. Cette migration inonde le marché d’un nombre incalculable d’applications mobiles, qui apportent de nombreux avantages aux utilisateurs, mais qui peuvent représenter des risques importants.

Nous introduisons dans ce chapitre la plateforme Android, où nous nous intéressons aux bases de ce système, ainsi qu’à ces composants. Nous présentons par la suite le modèle de sécurité déployé par Android, et un aperçu de ses mécanismes de sécurité. Nous nous intéressons ensuite aux vulnérabilités affectant le système Android, et aux façons dont elles sont employées. Et nous terminons par la présentation d’un certain nombre de contre-mesures déployées afin de limiter les attaques.

Android est un système d’exploitation Open source pour terminaux mobiles, il a été conçu et développé par la start-up Android, et racheté par la suite par la société Google qui l’a annoncé officiellement le 15 novembre 2007 (Gannes, 2007). Android est fondé sur un noyau modifié du système d’exploitation Linux, il supporte diverses plateformes embarquées telles que ARM, x86, MIPS, etc. Son architecture est conçue d’une manière permettant l’intégration des applications Google comme Gmail, Google agenda, YouTube ou encore Google maps, et a été proposé à tous les constructeurs des téléphones mobiles, tout en autorisant les modifications par ces fabricants (Cooper, Shahriar et Haddad, 2014).

Puisque Android est basée sur le système d’exploitation Linux, le noyau de ce dernier représente le niveau le plus bas de Android. Cette couche assure la liaison entre le matériel et le logiciel, et elle fournit aussi les services les plus fondamentaux tels que la sécurité, la gestion des processus, la gestion de la mémoire, les fonctionnalités des communications réseau, etc. Android ne s’occupe donc pas de l’interaction avec le matériel, c’est la raison qui fait que Android soit compatible avec la plupart des périphériques mobiles, puisque c’est la tâche du constructeur de spécifier ses composants matériels dans le noyau (BOUGARMOUD, 2013).

Un moteur d’exécution est un programme qui assure le fonctionnement d’autres programmes, ce mécanisme est intégré dans l’architecture d’Android plus précisément la couche au-dessus du noyau Linux. Cette couche contient des bibliothèques natives écrites en C/C++, des bibliothèques Java, ainsi que des bibliothèques spécifiques à Android et la machine Virtuelle Dalvik. Ces bibliothèques servent essentiellement à fournir des fonctionnalités aux couches applicatives d’Android (Shabtai, 2009).

La couche Framework offre aux développeurs des services de haut niveau, qui sont appelés à partir des applications sous format java. Cette couche offre donc un ensemble d’API (Application Programming Interface) qui permet la création des applications riches et innovantes. Les développeurs peuvent donc à travers ces API, exécuter des services d’arrièreplan, ajouter des notifications, accéder aux services de localisation, etc.

La couche la plus haute de l’architecture Android, est la couche applications. C’est la seule couche visible par l’utilisateur du périphérique. Elle se concrétise dans un ensemble d’applications installées sur le périphérique, qui sont développées à l’aide du langage Java, et compilées en des fichiers APK (Crussell, Gibler et Chen, 2012) .

La machine virtuelle Dalvik 

Dalvik est une machine virtuelle incorporée dans le système d’exploitation Android. Elle permet l’exécution de plusieurs applications sur un appareil de faible capacité en mémoire, et en puissance de calcul. Contrairement à la machine virtuelle classique de la technologie java, qui est basée sur la pile, la machine Dalvik est une machine à registres qui nécessite moins d’instructions pour effectuer les mêmes opérations qu’une machine à pile. En raison de cette différence, les fichiers de byte code Java ne peuvent pas être exécutés tels qu’il sont par Dalvik, ils seront tout d’abord transformés et consolidés dans un fichier .dex (Chien-Wei et al., 2010).

Les fichiers APK 

Un fichier APK est un format de fichier utilisé pour distribuer et installer des applications, au sein du système d’exploitation Android. Autrement dit un APK est l’équivalent d’un fichier JAR conçu spécialement afin de tourner sous Android.

Le fichier APK contient donc : 1) un fichier .DEX qui est le byte code Dalvik de l’application; 2) un fichier resources.arsc qui contient les ressources compilées (layouts ,xml etc.); 3) un fichier de ressources non compilées (les images, les strings, etc.); et 4) un fichier AndroidManifest.xml qui contient pour sa part le nom de package, la version actuelle de l’application, ainsi que diverses autres informations, qui sont nécessaires à l’exécution de l’application sous Android (permissions, activités, intents etc.) (Garin, 2009).

Communication inter applications (Intents)

La communication entre applications au sein du système est une notion importante, elle permet le partage des données entre les applications, l’envoi des messages entre applications, etc. Le système d’exploitation Android offre un moyen de communication puissant entre applications. Cette communication est assurée grâce au mécanisme des Intents (Guignard, 2010).

Les Intents sont basés sur le principe des Sandboxing, qui consiste à séparer presque totalement les applications entre elles. En d’autres termes, les Intents sont un ensemble de données qui peuvent être passées à un autre composant applicatif, faisant partie de la même application ou non (Guignard, 2010).

Les Intents peuvent être envoyés de deux principales façons, une première qui est explicite, et qui permet le lancement d’une classe précise. Et une deuxième dite implicite, qui permet le lancement d’une requête pour une action, sans la nécessité de préciser la classe qui s’occupe du traitement.

Table des matières

INTRODUCTION
CHAPITRE 1 SÉCURITÉ DU SYSTÈME ANDROID
1.1 Introduction
1.2 Le système d’exploitation Android
1.3 La machine virtuelle Dalvik
1.4 Les fichiers APK
1.5 Communication inter applications (Intents)
1.6 Modifications des APK (reverse engineering)
1.7 Le langage Smali
1.8 Modèle de sécurité d’Android
1.8.1 Sécurité au niveau noyau Linux
1.8.2 Sécurité au niveau applicatif
1.9 Les vulnérabilités du système Android
1.9.1 Vulnérabilités dues au système de permissions
1.9.2 Vulnérabilités dues aux fabricants de matériels
1.9.3 Vulnérabilités dues aux développeurs d’applications
1.9.4 Vulnérabilités deux au code source
1.9.5 Vulnérabilités dues au manque d’expérience des utilisateurs
1.9.6 Vulnérabilités dues au manque de fiabilité du store
1.10 Les attaques conte le système Android
1.10.1 Attaques par abus de permissions
1.10.2 Attaques exploitant les vulnérabilités du noyau Linux
1.10.3 Attaques exploitant les vulnérabilités du Framework Android
1.10.4 Attaques exploitant les vulnérabilités des applications
1.10.5 Attaques par collaborations ente applications
1.10.6 Attaques par espionnage des Intents
1.10.7 Attaques par botnets
1.10.8 Attaques par injection de code
1.10.9 Attaques par transformation de l’APK
1.11 Contre-mesures
1.11.1 Sensibilisation des utilisateurs
1.11.2 Antivirus
1.11.3 Pare-feu
1.11.4 Anti-spam
1.11.5 Virtualisation
1.12 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Le repackaging des applications
2.3 Modification de la plateforme Android
2.3.1 Comparaison
2.3.2 Limitations
2.4 La réécriture des applications Android
2.4.1 Réécriture des méthodes JAVA
2.4.2 Injection d’un code de contrôle dans les APK
2.4.3 Contrôle de divulgation de données privées dans l’application
2.4.4 Purification des APK
2.4.5 Comparaison
2.4.6 Limitations
2.5 Conclusion
CHAPITRE 3 ARCHITECTURE ET IMPLÉMENTATION
3.1 Introduction
3.2 Solution proposée
3.3 Choix de conception
3.4 Architecture globale de la solution proposée
3.5 Principe de réécriture des applications Android
3.6 Framework de réécriture des applications
3.6.1 La nature du Framework de réécriture d’applications
3.6.2 Modification du code des applications
3.6.3 Décompilation des applications
3.6.4 Détection des points d’injections
3.6.5 Invocation des méthodes dans le langage Smali
3.6.6 Pistage des méthodes API
3.6.7 Ajout de ressources nécessaires à l’application
3.6.8 La nature des ressources à rajouter
3.6.9 Mécanisme de communication
3.6.10 Injection des ressources dans l’application
3.6.11 Modification des chemins
3.6.12 Adaptation des registres
3.6.13 Modification du fichier AndoidManifest.xml
3.6.14 Compilation de l’application
3.6.15 Signature de l’application
3.7 Le contrôleur des applications
3.7.1 L’authentification des applications
3.7.2 Contrôle d’exécution des applications
3.7.3 Les règles de sécurité
3.7.4 Fonctionnement du contrôleur d’applications
3.7.5 Rafraîchissement des tableaux de références
3.7.6 Le contrôle des conditions
3.7.7 Communication de la réponse
3.7.8 L’ajout des méthodes API
3.8 Conclusion
CHAPITRE 4 TEST ET EXPÉRIMENTATIONS
4.1 Introduction
4.2 Framework de réécriture d’applications
4.2.1 Réécriture des applications
4.2.2 Temps de réécriture d’applications
4.2.3 Taille des applications
4.2.4 Insertion des appels de contrôles
4.3 Contrôleur d’applications
4.3.1 Tests de fonctionnement
4.3.2 Politiques de sécurité
4.3.3 Temps d’exécution
4.4 Discussion
CONCLUSION

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *