N° d’ordre : N° de série :
République Algérienne Démocratique et Populaire N° d’ordre : Ministère de l’Enseignement Superieur et de N° de série :
la Recherche Scientifique
UNIVERSITÉ ELchahid Hamma Lakhdar – El-Oued FACULTÉ DES SCIENCES ET DE TECHNOLOGIE
Mémoire de fin d’étude Présenté pour d’obtention du diplôme de MASTER ACADEMIQUE Domaine : Mathématique et Informatique Filière : Informatique Spécialité : Système Distribué et Intelligence Artificielle Présenté par Melle Yagoub ElKhansa
Melle Derouiche Karima Thème
Système de détection des malwares sous Android
Encadré par : Gherbi Kaddour
Devant le jury composé de: Mr. Khalaifa abdEnnaser MC (B) Univ. El Oued Président Mr. Othmani Samir MA (A) Univ. El Oued Examinateur Mr. Gherbi kaddour MA (A) Univ. El Oued Rapporteur
2014/2015
Remerciements
Je remercie tout d'abord notre Dieu qui nous a donné la force et la volonté pour élaborer ce travail. J’adresse nos vifs remerciements à notre encadreur Mr. Gherbi Kaddour , qui nous a aidés durant notre travail et par sa patience et ses précieux conseils dont Il nous a entourés. Sans son aide, notre travail n'aurait pas vu la lumière. Je remercie vivement les membres du jury qui m’ont fait l’honneur d’accepter de juger notre travail. Notre reconnaissance va aussi à tous ceux qui ont collaboré à notre formation en particulier les enseignants du département d'Informatique, de l’université d'El-Oued. Aussi à nos collègues de la promotion 2014-2015
Master Informatique, Je remercie également tous ceux qui ont participé de près ou de loin à élaborer ce travail.
Dédicaces
Je dédie ce travail ;
A ma très chère mère pour son amour inconditionnel et sa présence
À mes côtés dans les moments difficiles.
A la mémoire de mon très cher père symbole de courage, de tendresse et
que Dieu le
puissant l'accorde sa clémence et l'accueille en son vaste paradis.
A mes soeurs et frères pour leur encouragement.
A mes chers grands parents.
A mes grandes familles YAGOUB qui ont été toujours derrière moi.
A tous mes amies surtout : Karima.D et Siham.L
A tous mes collègues de la promotion 2014/2015.
A tous mes enseignants pour le savoir et les connaissances qu’ils m’ont
inculqué.
Je dédie ce modeste travail
Avec tout mon amour et tendresse.
ELKHANSA
Dédicaces
Je dédie ce travail ;
A ma très chère mère pour son amour inconditionnel et sa
présence
À mes côtés dans les moments difficiles.
A la mémoire de mon très cher père symbole de courage, de
tendresse et que Dieu le puissant l'accorde sa clémence et l'accueille en son vaste paradis.
A mes soeurs et frères pour leur encouragement.
A mes chers grands parents.
A mes grandes familles DEROUICHE qui ont été toujours
derrière moi.
A tous mes amies surtout : Khansa.Y et Siham.L
A tous mes collègues de la promotion 2014/2015.
A tous mes enseignants pour le savoir et les connaissances qu’ils
m’ont inculqué.
Je dédie ce modeste travailKARIMA
Avec tout mon amour et tendresse.
Résumé Android est devenu en quelques années le système d’exploitation le plus répandu sur les plateformes mobiles de type smartphones et tablettes. Parallèlement à sa large adoption, ce système est également devenu la cible de malware dont le nombre n’a cessé de croître, ce qui a stimulé les travaux de recherche liés à l’analyse et à la détection de malware Android. Les échantillons de malware Android étant principalement des versions infectées d’applications existantes. Nous proposons dans cette thèse une méthode de caractérisation et de détection de ces malware qui exploite ce mode d’infection et basée sur les techniques du machine learning. Mot clé : Android, Mobile Malware, analyse statique, machine learning,
ملخص
أصبح اندرو يد في غضون سنوات قليلة نظام التشغيل األكثر شيوعا على منصات مبايل والهواتف الذكية واألجهزة اللوحية. كما أصبح هذا النظام هدف البرمجيات الخبيثة التي انتشرت بنسبة هائلة في السنوات االخيرة األمر الذي حفز البحوث المتعلقة بتحليل وكشف البرمجيات الخبيثة لنظام االندرويد. عينات البرامج الخبيثة لالندرويد تكون اساسا من االصدارات المصابة للتطبيقات الموجودة.
نقترح في هذه األطروحة طريقة لتحليل والكشف عن البرمجيات الخبيثة تعتمد على اساليب التعلم اآللي.
الكلمات المفتاحية : اندرويد، البرمجيات الخبيثة للمحمول، التحليل الثابت، التعلم اآللي.
Abstract
Android has become in a few years the most common operating system on mobile platforms like smartphones and tablets. Alongside its broad adoption, this system also became the malware target whose number has grown steadily, which stimulated research related to the analysis and detection of Android malware. Android malware samples being mainly infected versions of existing applications. We propose in this thesis a method for characterizing and detecting these malware which operates the mode of infection and based on machine learning techniques.
Keywords: Android, Mobile Malware, static analysis, machine learning,
~ i ~
Glossaire
PDA : Personal Digital assistant , Patent Ductus Arteriosus
SDK: Software Development kit
UIDs: Unix-like operating systems
API : Application Programming Interface URL : Uniform Resource Locator
C&C: Command And Control.
IRC :Internet Relay Chat
RAT : Remote Administration Tool
BIOS : Basic Input output System
TDL-4 : The 'indestructible' botnet
MBR : Master Boot Record
CFG :Control Flow Graph en anglais
IDS : Système de Détection d’intrusions
ROC :Receiver Operating Characteristic
BPT): Bushy Park Time Tria
RTRL: Learning Rule
CPU: Central Processing Unit
LDR: Learning Decision Rules
SOFM :Self Organizing Map ou Self Organizing Feature Map
~ ii ~
Sommaire Résumé ...... i Glossaire ...... ii Sommaire ...... iii Listes des figures ...... vi Liste des tableaux ...... vii Introduction générale : ...... 1 Chapitre I ...... 3 Introduction : ...... 4 1. Système Android : ...... 4 1.1. Architecture du système Android : ...... 5 1.1.1. Noyau Android : ...... 5 1.1.2. Espace utilisateur : ...... 6 1.1.3. Communications entre processus : ...... 7 1.2. Applications Android : ...... 7 1.2.1. Architecture d’une application : les différents composants : ...... 7 1.2.2. Intents : communication entre composants : ...... 8 1.2.3. Intent-filter : ...... 9 1.2.4. Android Package : ...... 9 2. Sécurité de système Android : ...... 12 2.1. Mécanismes issus de Linux : ...... 12 2.1.1. Système multi-utilisateur et contrôle d’accès : ...... 12 2.1.2. Isolation des applications : ...... 12 2.1.3. Chiffrement de la partition de données : ...... 13 2.2. Mécanismes propres à Android : ...... 13 2.2.1. Permissions : ...... 13 2.2.2. Signature des applications : ...... 14 2.2.3. Analyse des applications : ...... 15 2.2.4. Protection de l’appareil et de ses données : ...... 15 2.2.5. Administration de l’appareil : ...... 15 3. Limite de mécanisme de sécurité : ...... 16 3.1. Abus de permission : ...... 16 3.2. Permissions : attaques par délégation et attaques par collusion ...... 16 3.3. Communication entre composants via les intents : ...... 16
~ iii ~
3.4. Failles logicielles : élévation de privilège :...... 18 4. Malware Android : ...... 18 4.1. Définitions : ...... 18 4.2. Actions effectuées par les malwares : ...... 18 4.3. Famille de malware : ...... 19 4.3.1. Backodoor : ...... 19 4.3.2. Ransomware : ...... 20 4.3.3. Voleur : ...... 20 4.3.4. Rootkit : ...... 21 5. Technique de détection des malwares : ...... 22 5.1. Analyse dynamique : ...... 22 5.1.1. Outils d’analyse dynamique : ...... 23 5.2. Analyse statique : ...... 23 5.2.1. Outils d’analyse statique : ...... 23 6. Les travaux existants : ...... 24 6.1. DREBIN : ...... 24 6.2. Kirin : ...... 25 6.3. Woodpecker: ...... 25 Conclusion : ...... 27 Chapitre II ...... 28 Introduction : ...... 29 1. Le cycle de vie d'une machine learning : ...... 29 1.1. Obtention des données et pré-processing: ...... 29 1.2. Réalisation du modèle : ...... 30 1.3. Phase d'apprentissage ...... 30 1.4. Phase de validation ...... 31 1.5. Performance du modèle : ...... 32 2. Types de modèle: ...... 32 2.1. Modèle supervisé: ...... 32 2.1.1. Neural network : ...... 32 2.1.2. Instance-Based Learning : ...... 33 2.1.3. k-nearest neighbor : ...... 33 2.1.4. Naive Bayes : ...... 33 2.1.5. Learning Décision Rules : ...... 34
~ iv ~
2.1.6. Learning Decision Trees : ...... 34 2.1.7. Quarter-sphere SVM : ...... 34 2.2. Modèle non supervisé: ...... 35 2.2.1. Single Linkage Clustering : ...... 35 2.2.2. Self organizing map ou self organizing Feature Maps (SOFM) : ...... 35 2.2.3. Gamma-algorithm : ...... 35 2.2.4. Machine à vecteur de support (SVM): ...... 35 Conclusion : ...... 39 Chapitre III ...... 40 Introduction : ...... 41 1. Notre Contributions : ...... 41 1.1. Sous-système De Téléchargement automatique des applications :...... 42 1.1.1. Applications normales : ...... 43 II.1.1 Applications malveillant : ...... 44 1.2. Sous-système De Service web Virus Total : ...... 45 2. Notre approche : ...... 46 2.1. Sous-système D’analyse d’applications Android : ...... 47 2.1.1. Extraction de métadonnées pour chaque application : ...... 47 2. Phase de Machine Learning: ...... 52 3.1. Algorithme de Machine Learning (svm) : ...... 52 3. Conclusion ...... 52 Chapitre VI ...... 53 Introduction : ...... 54 1. Implémentation : ...... 54 1.1. Environnement de travail : ...... 54 1.2. Androguard : ...... 54 2. Expérimentation: ...... 57 Conclusion : ...... 67 Conclusion générale ...... 68 Bibliographie ...... 69
~ v ~
Listes des figures Figure I.1 : le logo d'Android...... 4 Figure I.2 : Architecture de la plateforme Android...... 5 Figure I.3 : Partage d’une page web grâce à un intent implicite. Extrait du code du navigateur par défaut d’Android...... 8 Figure I.4 : Le format d’une application Android...... 9 Figure I.5 : Fichier AndroidManifest.xml d’Angry Birds Space...... 11 Figure I.6 : Fichier MANIFEST.MF de l’application HelloActivity...... 14 Figure I.7 : Fichier .SF de l’application HelloActivity...... 14 Figure II.1 : SVM binaire...... 37 Figure II.2 : L’hyperplan H optimal, vecteurs supports et marge maximale...... 38 Figure II.3 : à gauche cas linéairement séparable, à droite non linéairement séparable...... 38 Figure III.2 : L’architecture de notre Contributions...... 42 Figure III.3 : jeu de données...... 43 Figure III.4 : La distribution de normale apps...... 43 Figure III.5 : La distribution des applications...... 43 Figure III.6: La distribution des jeux...... 44 Figure III.7 : Top 20 Familles de malware Android...... 44 Figure III.8 : Sous-Système De Service web VirusTotal...... 45 Figure III.9 : Les 20 Premiers antivirus...... 45 Figure III.10: Les 20 Derniers antivirus ...... 46 Figure III.1: notre proposition...... 47 Figure III.11 : Extrait du code résultant de la décompilation de l’application JetBoy avec le décompilateur par défaut d’Androguard...... 48 Figure III.12: Les permissions d’androïde d’application opera_mini_65...... 49 Enfin, Le système génère un vecteur de caractéristiques similaires à la figure III.13...... 51 Figure III.14 : Une partie d’exemple de vecteur de caractéristique pour l'application facebook...... 51 Figure III.15 : Un hyperplan séparateur avec un maximum marge (SVM)...... 52 Figure III.19 : Taux de détection « Itération 01 »...... 58 Figure III.20 : Taux de détection « Itération 02 »...... 59 Figure III.21 : Taux de détection « Itération 03 »...... 60 Figure III.22 : Taux de détection « Itération 04 »...... 61 Figure III.23 : Taux de détection « Itération 05 »...... 62 Figure III.24 : Taux de détection « Itération 06 »...... 63 Figure III.25 : Taux de détection « Itération 07 »...... 64 Figure III.26 : Taux de détection « Itération 08 »...... 65 Figure III.27 : Taux de détection « Itération 09 »...... 66
~ vi ~
Liste des tableaux
Table I.1 : Types de permission Android...... 13 Table III.2 : Liste d’Antivirus scanners...... 57 Table III.3 : Résultat d'itération 01...... 58 Table III.4 : Résultat d'itération 02...... 59 Table III.5 : Résultat d'itération 03...... 60 Table III.6 : Résultat d'itération 04...... 61 Table III.7 : Résultat d'itération 05...... 62 Table III.8 : Résultat d'itération 06...... 63 Table III.9 : Résultat d'itération 07...... 64 Table III.10 : Résultat d'itération 08...... 65 Table III.11 : Résultat d'itération 09...... 66
~ vii ~
Introduction générale : Android est devenu en quelques années le système d’exploitation le plus utilisé et le plus répandu sur les smartphone et tablette. Les appareils tournant sous Android offrent différentes fonctionnalités allant du simple téléphone à celles des ordinateurs de bureau et assistants numériques personnels (pockets PC ou PDA). Les combinaisons de ces fonctionnalités font un point de concentration de divers données et services sensibles et en conséquence une cible de valeur pour les développeurs de malware.
Aujourd'hui, nous avons ainsi vu l’apparition d’un nombre important d’applications malveillantes qui cherchent à voler les données du téléphone, espionner l’utilisateur, etc. À la vue du nombre grandissant des malware Android, il devient nécessaire de développer des outils d’analyse de malware afin de comprendre leur fonctionnement et plus tard les détecter.
Les premiers travaux liés à la sécurité d’Android sont donc focalisés sur l’analyse des limites de la sécurité sous Android et sur une manière de les combler. Ce type d’approche a cependant une principale limitation qui est de ne détecter que ce que nous savons être dangereux. Il ne permet donc pas de détecter et d’apprendre de nouvelles attaques. Des autres travaux sont basés sur les flux d’information, il faut apprendre comment les attaques ont lieu en analysant directement les malware et utiliser la base de connaissance acquise durant l’apprentissage pour détecter les malware.
Contribution Selon les travaux de Zhou et al [18]. La méthode d’infection principale utilisée par les développeurs de malware est d’ajouter leur code malicieux à des applications existantes et proposer les versions infectées de ces applications en téléchargement sur les plateformes de téléchargement tel que Google Play.
Notre approche est classé parmi les deuxièmes travaux, elle effectue une large d'analyse statique, rassemblant le plus nombreux possible les fonctionnalités d'une application. Ces fonctionnalités sont intégrées dans un espace vectoriel conjointe, tels que les modèles typiques indicatifs des logiciels malveillants peuvent être automatiquement identifiés et utilisés pour expliquer les décisions selon notre méthode.
Organisation Le présent mémoire est organisé comme suit : Nous avons commencé par une introduction générale dans laquelle nous avons défini la problématique et notre contribution à la solution.
1
Le premier chapitre représente une introduction générale au contexte de ce travail et est divisé en deux parties. La première partie concerne le système Android : l’architecture du système, ses points communs et différences avec les systèmes Linux, la notion d’applications Android, l’analyse des limites du modèle de sécurité d’Android, les menaces que représentent les malware Android et les travaux essayant de combler ces limites.
Le deuxième chapitre décrit le Machine Learning. Nous expliquerons de façon détaillée le cycle de vie d'une implémentation de la machine Learning. Nous démarrons par l'obtention et nettoyage des données, puis la réalisation du modèle, la phase d'apprentissage, la phase de validation jusqu'à la phase d'exécution.
Le troisième chapitre présente la description de notre proposition.
Le quatrième chapitre présente l’implémentation de notre proposition et expérimentation.
La dernière partie de ce mémoire est constituée d'une conclusion générale et des perspectives pour continuer et améliorer ce travail.
2
Chapitre I L’état de l’art
Chapitre I Etat de l'art
Introduction : L’objectif de cette thèse est de développer une méthode afin de caractériser et détecter les malwares Android. La réalisation de cet objectif s’est faite en plusieurs étapes : La collection de jeu de données (applications androïde), L’étape d’analyse, L’extraction des caractéristiques, Méthode de détection des malwares. Dans ce premier chapitre, nous introduisons dans un premier temps le système Android : son architecture, la notion d’application Android et le modèle de sécurité d’Android. Ensuite, nous montrons les limites du mécanisme de sécurité Android ainsi qu’un aperçu des menaces que représentent les malware Android. Il est nécessaire d’analyser statiquement les échantillons des malware concernés. Nous présentons ainsi un ensemble d’outils d’analyse statique des applications Android. Enfin nous présentons les travaux existant dans le domaine d'analyse statique.
1. Système Android : Android est un système d'exploitation mobile pour smartphones, tablettes tactiles, PDA, smartwatches et terminaux mobiles. Android partage une base commune aux systèmes Linux qui est le noyau et, un ensemble de commandes et utilitaires nécessaires. Dans cette section, nous présentons dans un premier temps l’architecture du système Android, celle de ses applications et les mécanismes de sécurité fournis avec le système [29].
Figure I.1 : le logo d'Android.
4 Chapitre I Etat de l'art
1.1. Architecture du système Android : Le système Android est divisé en plusieurs couches comme illustré sur la figure I.2. La partie la plus basse représente le cœur du système, c’est-à-dire le noyau, et le reste l’espace utilisateur.
Figure I.2 : Architecture de la plateforme Android.
1.1.1. Noyau Android : Le noyau Android est une version modifiée du noyau Linux (Noyau utilisé par les distributions de type Linux telles que Debian et Ubuntu) et représente le cœur du système. Le noyau est le programme servant d’interface entre les différents composants du système (périphériques, processus, fichiers etc.). Parmi les modifications notables apportées dans le noyau Android, nous pouvons citer les mécanismes binder, ashmem, wakelock, low memory killer, logger, RAM console et Paranoid Networking. Binder : est un mécanisme de communication entre processus et d’appel de méthodes distantes. L’appel de méthodes distantes, appelé Remote Procedure Call en anglais, consiste à faire exécuter une méthode par une entité distante. Il est inspiré du projet OpenBinder [35]. Il est un élément essentiel du fonctionnement du système Android.
5 Chapitre I Etat de l'art
Ashmem : pour Anonymous Shared Memory est un mécanisme de partage de mémoire similaire à celui du noyau Linux shm. Il est utilisé pour partager les données entre applications Android. Wakelock : est un mécanisme servant à notifier le noyau de ne pas se mettre en veille. Contrairement aux systèmes Linux, le système Android essaie par défaut de se mettre en veille étant donné qu’il est destiné à tourner sur des appareils à ressources limitées. Lors d’exécution de code ne devant être interrompu, le wakelock est ainsi utilisé pour dire au système de rester éveillé. Low memory killer : est un mécanisme utilisé par le noyau pour libérer de la mémoire lorsqu’il ne reste plus assez de mémoire. Logger : est un mécanisme de journalisation qui écrit les évènements du système uniquement dans des zones allouées en mémoire. Contrairement aux systèmes Linux traditionnels, les évènements écrits dans le journal du système ne sont ainsi jamais écrits dans un fichier. RAM Console : est un mécanisme qui préserve en mémoire le contenu des évènements systèmes ajoutés par du code noyau (via la fonction printk) lors de la précédente
exécution du système. Son contenu est accessible via le fichier /proc/last_kmsg.
Paranoid Network : est un mécanisme contrôlant l’accès des applications au réseau. Sous Linux, toute application a le droit d’utiliser les sockets et accéder au réseau. Le socket est la structure de base liée aux opérations réseaux sous Linux. Sous Android, l’inverse est la règle car seule les applications avec une autorisation explicite sont autorisées à créer des sockets et communiquer sur le réseau [13].
1.1.2. Espace utilisateur : L’espace utilisateur sous Android peut être divisé en plusieurs parties comme illustré sur la figure I.2 La couche Applications : renferme les applications fournies par défaut sur le téléphone ainsi que celles qui seront installées plus tard par l’utilisateur. Il s’agit des applications avec lesquelles l’utilisateur pourra interagir en général (ex : application de messagerie et gestion des contacts). Les applications Android sont principalement écrites en Java. Android framework : est l’ensemble des services et ressources fournies par le système Android. Il s’agit principalement de services tournant dans quelques processus clés du système Android tels que system_server et mediaserver
6 Chapitre I Etat de l'art
Android runtime : est l’environnement d’exécution des applications Android. Il contient la bibliothèque Java utilisable par les applications ainsi qu’une machine virtuelle appelée Dalvik. Libraries : renferme les bibliothèques natives du système. Elles sont généralement utilisées par les applications natives du système. HAL ou Hardware Abstraction Layer : sert d’interface standard entre le système et les pilotes des périphériques présents sur l’appareil (ex : caméra, capteur etc [13].
1.1.3. Communications entre processus : Android est un environnement d’exécution où les applications sont poussées à collaborer pour fonctionner. Le but de cette collaboration est de limiter la duplication de code dans les applications et de proposer un ensemble assez grand de fonctionnalités aux différentes applications du système. Un exemple illustrant cette collaboration est l’application caméra. Pour utiliser la caméra d’un appareil, une application doit connaître son mode de fonctionnement exact sachant qu’une caméra peut être différente d’un modèle de téléphone à un autre. Pour faciliter la tâche au développeur de l’application, l’application caméra du téléphone propose une interface permettant aux autres applications de prendre des photos ou enregistrer des vidéos à leur place puis leur transmettre le résultat. Ce système de collaboration repose plusieurs fonctionnalités du système. Du point de vue des développeurs d’application, la collaboration repose sur l’usage des intents et des composants Content Provider pour échanger des messages et partager du contenu [13].
1.2. Applications Android :
1.2.1. Architecture d’une application : les différents composants : Une application Android est écrite en Java. Contrairement aux applications Java standard, une application Android peut posséder plusieurs points d’entrée. Plus précisément, une application Android peut avoir plusieurs composants et chacun d’eux peut-être un point d’entrée dans le programme. Il existe quatre types de composants : Activity, ContentProvider, Service et BroadcastReceiver. Activity : Un composant Activity est une interface utilisateur. Une application de messagerie électronique peut par exemple avoir trois composants. Activity : un pour naviguer entre les répertoires de la messagerie, le deuxième pour l’affiche d’un message et le dernier pour l’édition et l’envoi.
7 Chapitre I Etat de l'art
ContentProvider : Un ContentProvider est un composant servant au partage de données d’une application. Son rôle est de servir d’interface entre l’application souhaitant accéder aux données et les données. Service : Un service est un composant effectuant des tâches en arrière-plan. Il est utilisé pour effectuer de longues tâches internes à l’application ou à exécuter une tâche à la demande d’une application. BroadcastReceiver : Un BroadcastReceiver est un composant utilisé pour écouter les messages en large diffusion sur le système. Un exemple de ce type de message est la réception d’un nouveau SMS. Lorsqu’un nouveau SMS est reçu par le téléphone, le système envoie un message en broadcast pour notifier les différentes applications d’envoi et réception de SMS. Ce composant ne possède aucune interface graphique et n’est pas censé exécuter de longues tâches.
1.2.2. Intents : communication entre composants : Un intent est un message utilisé par les composants des applications pour communiquer entre eux. Plus précisément, il est utilisé pour exécuter que le destinataire exécute une requête à la demande de l’émetteur. Le composant émettant l’intent et celui la recevant ne font pas forcément partie de la même application. Un intent a deux usages principaux : lancer un composant Activity ou Service et diffuser un message dans le système aux composants Broadcast Receiver[22].
1 static final void sharePage(Context c, String title, String url, 2 Bitmap favicon, Bitmap screenshot) { 3 Intent send = new Intent (Intent.ACTION_SEND); 4 send.setType("text/plain"); 5 send.putExtra(Intent.EXTRA_TEXT, url); 6 send.putExtra(Intent.EXTRA_SUBJECT, title); 7 send.putExtra(Browser.EXTRA_SHARE_FAVICON, favicon); 8 send.putExtra(Browser.EXTRA_SHARE_SCREENSHOT, screenshot); 9 try { 10 c.startActivity(Intent.createChooser(send, c.getString( 11 R.string.choosertitle_sharevia))); 12 } catch (android.content.ActivityNotFoundException ex) { 13 // if no app handles it, do nothing 14 } 15 }
Figure I.3 : Partage d’une page web grâce à un intent implicite. Extrait du code du navigateur par défaut d’Android.
8 Chapitre I Etat de l'art
1.2.3. Intent-filter : Dans la section précédente, nous avons présenté les intents, un type de message utilisé par les composants d’une application pour communiquer avec d’autres composants. Lors de l’émission de l’intent, le système calcule à partir des attributs associés à l’intent le(s) destinataire(s) du message. Deux cas peuvent se présenter. Dans le premier cas, l’émetteur a défini explicitement le destinataire (explicit intent). Le message est donc transmis directement au destinataire choisi par l’émetteur. Dans le second cas, l’émetteur n’a pas défini de destinataire et il appartient au système de le définir (implicit intent). Lorsque ce cas se présente, le système définit la liste des destinataires possibles grâce à un filtre déclaré par chaque application appelée intent-ilter. Ce dernier définit pour chaque composant quels sont les intents que le composant souhaite recevoir et est déclaré dans le fichier AndroidManifest.xml qui accompagne chaque application Android. Dans la figure I.5 par exemple, l’application filtre les intents que deux de ses composants peuvent recevoir. Le premier composant, App, ne peut recevoir que les intents dont les attributs action et category ont respectivement comme valeur associée android.intent.action.MAIN et android.intent.category.LAUNCHER. Quant au deuxième composant, BillingReceiver, il ne peut recevoir que des intents auquel l’attribut action est associé à la valeur com.android.vending.billing.RESPONSE_CODE [23].
1.2.4. Android Package : Une application Android prend généralement la forme d’un fichier dont l’extension est. apk. Il s’agit cependant d’une simple archive ZIP. Cette archive contient différents éléments dont les plus importants, lors de la recherche de vulnérabilités [02], sont :
Figure I.4 : Le format d’une application Android.
9 Chapitre I Etat de l'art
AndroidManifest.xml : AndroidManifest.xml est un fichier xml contenant les informations liées à l’application qui sont nécessaires au système. Il est créé par le développeur de l’application. Parmi les informations qu’il contient, nous pouvons citer : le nom du package de l’application. le composant Activity à lancer au lancement de l’application. la liste des composants de l’application et les informations qui sont liés aux composants (ex : permission pour accéder à un composant Service sensible, les Intents attendus par les composants de l’application etc). les permissions demandées par l’application (ex : read_sms pour lire les SMS). les permissions déclarées par l’application. les bibliothèques utilisées par l’application. le niveau minimal du SDK Android pour que l’application puisse fonctionner.
Classes.dex : Le code de chaque classe d’une application Java standard est stocké dans des fichiers .class différents. Sous Android, ce n’est pas le cas. Tout est stocké dans un seul et unique fichier qui est classes.dex. De plus, si le code des applications Java est lui compilé en bytecode Java, celui des applications Android est lui compilé dans un autre format qui est le bytecode dalvik. C’est le contenu de ce fichier, ou plus précisément une version optimisée de celui-ci, qui sera interprété par la machine virtuelle Dalvik pour exécuter l’application. Autres : Un apk contient d’autres entrées telles que les répertoires META-INF, res, jni et lib. Le répertoire META-INF contient ainsi des fichiers liés au contrôle d’intégrité de l’application et à l’identification de son développeur. Le répertoire res contient les ressources utilisées par l’application telles que des images, sons, etc. Les répertoires jni et lib contiennent les bibliothèques utilisées par l’application.
1 10 Chapitre I Etat de l'art 11 />
Figure I.5 : Fichier AndroidManifest.xml d’Angry Birds Space.
11 Chapitre I Etat de l'art
2. Sécurité de système Android : Le noyau d’Android est un noyau Linux avec un ensemble de modifications et d’ajouts. Une partie des mécanismes de sécurité offerts par Android proviennent ainsi du système Linux auxquels s’ajoutent des mécanismes propres à Android. Ces mécanismes ont pour but de protéger les applications les unes des autres, les communications entre applications et les ressources sensibles disponibles dans le système.
2.1. Mécanismes issus de Linux : Le noyau d’Android est une version modifiée du noyau Linux. Il bénéficie ainsi des mécanismes offerts par les noyaux et systèmes Linux : système multi-utilisateur, contrôle d’accès (lecture, écriture et exécution) basé sur les utilisateurs et isolation par processus.
2.1.1. Système multi-utilisateur et contrôle d’accès : Android supporte l’existence de plusieurs utilisateurs dans le système et utilise le mécanisme de contrôle d’accès fourni par Linux. L’accès aux différentes ressources dans le système est ainsi défini par des droits d’accès en lecture, écriture et exécution. Ces accès sont définis pour trois entités : le propriétaire, le groupe propriétaire et les autres. Il existe un ensemble prédéfini d’utilisateurs par défaut sur les systèmes Android dont une partie est associée au fonctionnement interne du système. Parmi ces utilisateurs nous pouvons citer root qui est l’utilisateur avec les droits les plus élevés dans les systèmes de type Linux et Android et l’utilisateur system qui est associé aux différentes ressources nécessaires au fonctionnement du système tels que les bibliothèques natives partagées. Tout au long de l’exécution du système, la liste des utilisateurs peut ensuite évoluer. En effet, d’autres utilisateurs sont créés à chaque fois qu’une application est installée sur le système. Ces utilisateurs ont généralement des droits restreints à savoir qu’ils ont uniquement accès aux ressources appartenant à l’application à laquelle ils sont associés. Cette restriction évite ainsi que les données de fichier appartenant à une application ne soit lues ou modifiées par une autre application.
2.1.2. Isolation des applications : En plus d’associer des utilisateurs différents à chaque application, Android les cloisonne également en les exécutant dans des processus différents et en leur attribuant des répertoires différents dans lesquels les applications stockent les données qu’ils manipulent. Les processus associés à chaque application s’exécutent avec les droits de l’utilisateur associé à l’application et les répertoires appartiennent également à l’utilisateur auquel l’application est associée. Ce cloisonnement évite ainsi qu’une application interfère avec l’exécution d’une autre application ou qu’elle modifie les données d’une autre application.
12 Chapitre I Etat de l'art
Type Description Normal Valeur par défaut des permissions. Elle est automatiquement accordée à toute application la demandant. Dangerous Nécessite une validation de la part de l’utilisateur afin d’accorder la permission. Exemple : read_sms pour l’accès aux SMS. Signature Permission accordée uniquement si l’application la demandant est signée avec le certificat du développeur ayant déclarée la permission. signatureOrSystem Permission accordée uniquement aux applications system, plus précisément celles dans la partition system, ou à celles ayant été signées avec le même certificat que l’application ayant déclarée la permission.
Table I.1 : Types de permission Android.
2.1.3. Chiffrement de la partition de données : Depuis la version 3.0 d’Android, le système offre la possibilité de chiffrer la partition data. Cette partition contient l’ensemble des applications du téléphone, à l’exception des applications fournies par défaut que l’utilisateur ne peut désinstaller, ainsi que les données qu’elles manipulent. Le chiffrement est réalisé grâce au module dm-crypt [28] fourni par le noyau.
2.2. Mécanismes propres à Android :
2.2.1. Permissions : Android propose un ensemble de ressources sensibles aux applications installées sur le téléphone (réseau, caméra, système de géolocalisation, bluetooth, etc.). Pour les utiliser, une application devra déclarer les permissions correspondantes. Une application souhaitant lire les sms devra par exemple avoir la permission read_sms. À l’installation, l’utilisateur valide les permissions demandées par l’application. Pour que l’installation se fasse, il doit toutes les accepter. Une fois l’application installée, plus aucune validation n’est nécessaire de la part de l’utilisateur. La seule exception est l’envoi de messages à des numéros surtaxés où l’utilisateur doit valider (fonctionnalité disponible depuis Android 4.2) chaque envoi. Il existe quatre types de permission que nous résumons dans le tableau I. 1.
13 Chapitre I Etat de l'art
Name: AndroidManifest.xml SHA1-Digest: 9FiHXTmeVecbFb3enszaSlXIZp0= Name: res/layout/hello_activity.xml SHA1-Digest: BJz/aHbKT/Or0LwKJZ/jxN+WzmE= Name: resources.arsc SHA1-Digest: khWw+6lJ8dfajIaKkvbCuQ7YYzI= Name: classes.dex SHA1-Digest: +aR5lPSRcAvOrX+OhsxELXB1qGg=
Figure I.6 : Fichier MANIFEST.MF de l’application HelloActivity.
2.2.2. Signature des applications : Android requiert que chaque application soit signée afin d’être installée sur le téléphone. Les développeurs signent ainsi leur application avec un certificat dont la clé privée leur est propre. Les applications Android sont signées avec l’outil jarsigner. Il prend en entrée une archive jar ou zip et un certificat. Il donne en sortie l’archive à laquelle ont été ajoutés deux fichiers : un fichier avec l’extension .sf et un autre fichier avec l’extension .rsa ou .dsa selon les clés utilisées. L’entête du premier fichier correspond au hash du fichier MANIFEST.MF. Le reste de son contenu est similaire au fichier meta-inf/manifest.mf qui est présent dans chaque archive jar. MANIFEST.MF recense pour chaque fichier présent dans l’archive son nom, son hash et l’algorithme de hachage utilisé. La figure I.6 est le fichier manifest.mf de l’application HelloActivity fourni en exemple avec le kit de développement Android. Pour chaque fichier présent dans l’archive nous avons son nom, un algorithme de hachage et le hash du fichier. Le fichier .SF contient les mêmes types d’information que MANIFEST.MF. Pour chaque fichier présent dans l’archive nous avons une entrée constituée du nom du fichier, un algorithme de hachage et un hash.
Signature-Version: 1.0 Created-By: 1.0 (Android SignApk) SHA1-Digest-Manifest: Qenbz+ZjLsHBpHWbAHMYhLpfies= Name: AndroidManifest.xml SHA1-Digest: uziqi6KmjjgyRnooQ7j5ZHIKVTw= Name: res/layout/hello_activity.xml SHA1-Digest: who+PyjjYjRHN6maNog494Cr+CE= Name: resources.arsc SHA1-Digest: WlDZ0LWZ+zrAmxUTKZuz99hUoZo= Name: classes.dex SHA1-Digest: QjwcQAkf4iVckku4qf7kiLRSndo=
Figure I.7 : Fichier .SF de l’application HelloActivity.
14 Chapitre I Etat de l'art
2.2.3. Analyse des applications : Google analyse régulièrement les applications proposées en téléchargement sur Google Play ainsi que celles en instance d’être installées sur les téléphones des utilisateurs. Si aucune information sur la nature exacte des analyses n’est fournie par Google, nous savons qu’une analyse statique et dynamique des applications sont faites pour détecter des motifs synonymes de menace dans l’application ou des comportements malveillants.
2.2.4. Protection de l’appareil et de ses données : Android possède un ensemble d’outils destinés aux développeurs du système. Parmi ces outils nous pouvons citer adb et fastboot. La commande adb permet de communiquer avec un émulateur Android ou un téléphone. Parmi les fonctions proposées, il y a l’ouverture d’un shell distant sur le téléphone, l’installation ou la suppression d’application et le transfert de fichier. Pour protéger le téléphone de tout usage malveillant de ces outils, la communication est possible uniquement si le mode debug est activé. Une authentification par clé de l’ordinateur auprès du téléphone s’ajoute également à cela depuis la version 4.2 d’Android afin de filtrer les machines pouvant communiquer avec le téléphone via adb. La commande fastboot sert à effacer/remplacer le contenu des différentes partitions sur le téléphone. Afin de l’utiliser, l’utilisateur doit dans un premier temps débloquer cette fonctionnalité au démarrage et ce processus de déblocage implique la suppression du contenu de la partition data du téléphone. Cette partition contient les données de l’utilisateur ainsi que des différentes applications. L’action de remplacer le contenu d’une partition est souvent désigner par l’expression flasher une image, l’image étant le nouveau contenu de la partition. Un attaquant désirant ainsi remplacer une partie des composants logiciels du système via fastboot ne pourra ainsi accéder aux données de l’utilisateur.
2.2.5. Administration de l’appareil : Android propose depuis sa version 2.2 une API permettant de développer des applications afin d’administrer les téléphones [21]. L’API permet de renforcer la politique sur les mots de passe (ex : taille, expiration et nombre de tentatives), imposer le chiffrement des partitions, activer / désactiver la caméra (fonctionnalité disponible depuis Android 4.0), demander la création d’un nouveau mot de passe, verrouiller le téléphone et remettre le téléphone à la configuration d’usine.
15 Chapitre I Etat de l'art
3. Limite de mécanisme de sécurité :
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.
3.2. Permissions : attaques par délégation et attaques par collusion Une attaque par délégation [01] 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.
3.3. Communication entre composants via les intents : Les intents sont des messages échangés entre les composants des applications pour transmettre des requêtes. La possibilité d’envoyer des intents entre deux composants de deux applications différentes apporte une surface d’attaque supplémentaire. Dans [08], Chin et al. décrivent en se basant sur leur analyse du fonctionnement des întents des scénarios d’attaques qui pourraient 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. 3.3.1. 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 informations 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 message. 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
16 Chapitre I Etat de l'art
même intent-filter. Pour observer les messages reçus par le composant BillingReceiver déclaré dans le Figure I.5, une application malveillante n’a qu’à déclarer un composant du même type en précisant 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. 3.3.2. 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 implicite intent n’a donc qu’à déclarer un composant ayant un intent filter correspondant à l’intent qu’il souhaite détourner. 3.3.3. Vol/abus des permissions :
Nous avons écrit en section II.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. 3.3.4. 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 applications 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 malveillantes qui elle 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
17 Chapitre I Etat de l'art
exemple un composant Activity qui ouvre les URL à la demande d’autres applications. 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 navigateur afin que ce dernier ouvre une adresse web.
3.4. Failles logicielles : élévation de privilège : Comme tout programme, le système Android a également des failles logicielles. Exploiter certaines d’entre elles permet d’élever les privilèges d’une application 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 system sous 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.
4. Malware Android :
4.1. Définitions : Nous appelons malware un programme ou un code dont le but est de nuire à un système donné. Dans le reste du document nous ferons souvent usage des termes échantillon de malware et famille de malware. Un échantillon d’un malware est une application, comprendre ici application Android correspondant à un fichier apk, qui contient ce malware. Quant à une famille de malware, il s’agit de l’ensemble des échantillons d’un malware. Analyser un malware revient ainsi à analyser un ou plusieurs de ses échantillons afin d’extraire des informations liées au malware et détecter un malware revient à décider si une application donnée est un échantillon d’un malware. Les premiers travaux qui ont consisté à dresser un bilan des menaces que représentent les malwares Android sont les travaux d’Y. Zhou et X. Jiang dans [18]. Leurs travaux sont basés sur l’analyse de plus de 1200 échantillons de malware qu’ils ont collecté de 2010 à 2011.
4.2. Actions effectuées par les malwares : Les actions effectuées par les codes malveillants peuvent être réparties dans quatre groupes :
1. élévation de privilège
2. contrôle à distance
3. charge financière
4. Vol de données.
18 Chapitre I Etat de l'art
4.3. Famille de malware : Il existe des millions de malwares différents. Ces malwares ont des fonctionnalités différentes, ils peuvent être classés par familles. Il est important de pouvoir classer un malware en fonction de son impact et son but [12].
4.3.1. Backodoor : Les backdoors sont des malwares permettant à un attaquant de prendre la main sur le système infecté. Grâce à ce port ouvert, l'administrer à distance .cette technique. Impose une connexion à chaque machine afin de l'administration d'un parc de machine infectées est alors des plus laborieuses. On comprend que cette approche limite le nombre de machines humainement gérable par un seul attaquant. Pour pallier cette limitation, ces backdoors ont évolué en botent. Un botnet est un ensemble de machines infectées entre elles par un serveur central qui diffuse les ordres au travers du botnet. Ce serveur central est communément appelé C&C (Command and Control). Ces serveur peuvent être des serveurs IRC (Internet Relay Chat) ou encore des serveurs web. De cette manière, l'attaquant peut administrer des milliers de machines depuis un point central. Cette architecture client/ serveur est parfois édulcorée par un modèle pair à pair : quelques collecteurs obtiennent les ordres depuis le C&C, ensuite les ordres sont diffusés dans le voisinage du collecteur. De proche en proche les ordres sont ainsi diffusés dans tout le bonet. Waledac est un bon exemple d'une telle architecture.
Des frameworks ont été créés pour faciliter l'administration de ces machines infectées. Ces framworks, appelés RAT (Remote Administration Tool), permettent de prendre la main sur les machines infectées, mais également d'automatiser la capture d'écran, le transfert de fichiers entre l'attaquant et la machine infectée, de gérer la base de registre Windows. Les fonctionnalités de ces RAT sont seulement limitées par l'imagination des développeurs.
Pour saisir l'impact de ce type de malware, de nombreux exemples d'utilisation existent. Par exemple, lors des révolutions arabes de 2011, un RAT nommé DarkComet a été utilisé par les autorités syriennes pour contrôler les ordinateurs des opposants au régime.
Four ce type de malware, le premier travail de l'analyste de malware consiste à trouver le C&C afin de bloquer tout accès à ce serveur. Cette ce blocage ne nettoie pas les machines infectées par le malware mais l'attaquant sera neutralisé, en effet il ne pourra plus donner d'ordre au botnet. Cette approche permet de gagner du temps pour continuer les analyses. La seconde étape consiste alors comprendre comment éradiquer le malware, c'est-à-dire désinfecter la machine. Dans un troisième temps, on s'attachera à cerner les fonctionnalités du malware pour en cerner l'impact ainsi que son protocole de communication avec le C&C par
19 Chapitre I Etat de l'art
exemple pour définir une détection générique de son trafic réseau cette dernière détection générique peut alors permettre la détection de nouveaux C&C…
4.3.2. Ransomware : Les ransomwares sont des malwares créés pour que l’utilisateur infecté ne puisse plus utiliser son système d’information ou consulter ses documents sans payer une rançon à l’attaquant.
Dans le cas ou ce sont les données qui ne peuvent plus être consultées, le ransomware chiffre les fichiers et l’attaquant ne donnera la clé de déchiffrement qu’après avoir reçu la rançon.
Dans le cas où le système d’information est visée, la machine st limitée dans son utilisation. Par exemple, il est impossible de se connecter sur Internet. Dans ce cas, l’attaquant fournit un logiciel de déblocage après avoir reçu la rançon.
Pour ce type de malware, l’analyste devra comprendre l’algorithme de chiffrement ou les mécanismes de blocage de la machine mis en place par l’attaquant. En effet, des erreurs d’implémentation ou des algorithmes faibles permettent souvent de restaurer les fichiers de la victime sans payer aucune rançon.
Il existe de nombreux ransomwares, parmi ceux-ci Matsnu (ou Rannoh) est particulièrement intéressent. Une des caractéristiques de ce malware est sa grande vitesse de propagation ainsi que le nombre important de machines bloquées. Ce ransomware était interfacé avec plusieurs serveurs d’administration. De plus, pour rendre l’analyse encore plus complexe, le malware générait des clés chiffrement uniques pour chaque fichier chiffré. Le chiffrement utilisé était le RC4 qui est considéré comme un algorithme de chiffrement fort.
4.3.3. Voleur : Les voleurs (ou stealer) sont des malwares crées dans le but de voler des informations ou des données sur la machine infectée. Comme dans le cas des backdoors, ces malwares se connectent à des serveurs centraux pour envoyer les données volées. Ces données peuvent être de tout type : des e-mails, des plans, des numéros de carte de crédit, des bitcoins (monnaie virtuelle)…
Tout comme pour les backdoors, le but de l’analyste de malware est de trouver le C&C afin de bloquer toutes les communications avec celui-ci. La seconde étape est d’analyser quels types de données ont été exfiltrées par ce malwares afin d’évaluer l’impact.
Il existe de nombreuses manières pour faire sortir les données d’un système : l’attaquant peut utiliser de nombreux canaux de communication tels que l’envoi d’e-mails, les salons
20 Chapitre I Etat de l'art
IRC, ou encore le web en envoyant par exemple les informations sur PasteBin, un outil permettant de copier un texte pour le rendre disponible aux autres internautes.
Ce type de malware peut être illustré par le cas de Duqu, découvert en 2011 dans le laboratoire de cryptophragie et de sécurité système de l’université polytechnique et économique de Budapest. Ce malware a été conçu pour capturer les frappes du clavier de la machine infectée et également pour récupérer des informations sur le système infecté. Les cibles de ce malware étaient peu nombreuses et concernaient essentiellement des systèmes de contrôle industriel.
4.3.4. Rootkit : Les rootkits sont des malwares servant à dissimuler l’activité de l’attaquant sur la machine infectée. Les premiers rootkits sont nés en 1994 sur Linux, en 1998 sous Windows et en 2004 sous Mac OS X.
Les premier but d’un rootkit est de se dissimuler, pour cela le rootkit va supprimer sa trace dans les journaux système. Il va également cacher son existence au niveau de la base de registre, mais aussi au niveau du système de fichiers via des mécanismes de hook.
Un hook consiste à remplacer un appel système du système d’exploitation par un autre appel. Dans notre cas, le malware peut par exemple remplacer l’appel système permettant d’afficher les fichiers présents dans un répertoire par un appel modifié listant seulement les fichiers non liés au rootkit. Ainsi les fichiers nécessaires au fonctionnement du malware restent cachés.
Un rootkit cachera par exemple son activité de processus ou son activité réseau. De cette manière, l’utilisateur de la machine infectée sera incapable de voir qu’un logiciel non voulu est on cours de fonctionnement sur sa machine. De plus, les rootkits peuvent également stopper les antivirus ou firewalls pour ne pas être interrompus pendant que l’attaquant se connecte à la machine infectés. A la manière d’une backdoor, les rootkits laissent généralement une porte dérobée pour permettre à l’attaquant d’utiliser la machine infectée.
Les rootkits ont besoin de privilèges élevés pour pouvoir fonctionner. Il est donc fréquent que ces rootkits soient des drivers du noyau chargés automatiquement au démarrage de la machine. Ces dernières années, de nouveau du types de rootkits apparaissent agissant au niveau du BIOS de la machine. Ces rootkits sont très compliqués à identifier, car le système d'exploitation n'est pas capable de les analyser. En 2010, un chercheur a publié une méthode
21 Chapitre I Etat de l'art
permettant de remplacer le firmware d'une carte réseaux. Ce nouveau firmware permettait une prise de main à distance de la machine infectée sans rien modifier au système d'exploitation
Ce type de malware est le plus compliqué à analyser. Les fonctionnalités son multiples, la taille de ce type de malware est généralement grande et leur dissimulation rend l’analyse encore plus ardue.
TDL-4 est un malware ayant utilisé un rootkit. Ce rootkit s’installait sur le MBR (Master Boot Record) du disque dur.
Le MBR est le secteur de boot d’un disque dur, il permet au système d’exploitation de démarrer. Le fait de se trouver sur cette section de disque rend la détection par l’antivirus beaucoup plus difficile. Il y aurait en juin 2011 plus de 4 millions de machines infectées par ce rootkit.
5. Technique de détection des malwares : La détection de malware se fait généralement en utilisant des signatures ou des profils comportementaux. La signature d’un malware est un ensemble de propriétés communes aux fichiers des échantillons du malware. Dans le cas des applications Android, ces fichiers sont les apks. Le profil comportemental d’un malware est un ensemble de propriétés communes à l’exécution des échantillons du malware. Ces signatures et profils sont construits à partir des informations obtenues en analysant, statiquement ou dynamiquement, les échantillons de malware. La tendance actuelle consiste à utiliser des méthodes d’apprentissage afin de classifier et détecter des malwares [13]. Analyser une application a pour but d’extraire des informations liées à l’application telles que son comportement, les ressources qu’elle utilise et les évènements attendus pour exécuter une partie de son code.
5.1. Analyse dynamique : L’analyse dynamique consiste à exécuter et à monitorer (surveiller) les actions exécutées par une application. Au contraire de l'analyse statique et de l'étude du code-source de l'application, l'analyse dynamique consiste à étudier le comportement de l'application : appel de fonctions, chaines stockées en mémoire, trafic généré, etc. On utilise l'analyse dynamique pour l'étude de malwares (dans ce cas-là, le recours à un environnement sécurisé de type sandbox19 permet de contrôler les actions réalisées), et quand il n'est pas possible d'accéder au code-source de l'application (légalité du reverse engineering) [05].
22 Chapitre I Etat de l'art
5.1.1. Outils d’analyse dynamique : Il y a un certain nombre d’outils permettant de réaliser une analyse dynamique (monitoring des actions réalisées) d’une application Android. On utilise ceux-ci pour en général tester des applications malveillantes dans un environnement protégé.
Droidbox [20]: Outil de type Sandbox pour les applications Android. Permet l’analyse dynamique (monitoring d’API, détection des fuites de données, analyse préliminaire statique, etc.) Mobile Sandbox [34]: Sandbox pour applications mobile disponible en ligne. AndroidAuditTools [24]: Outils pour analyse dynamique d’applications Android.
5.2. Analyse statique : L’analyse statique consiste à décompiler l’application afin d’en étudier le code. Cette méthode appelée reverse-engineering, a pour défaut que le temps passé à analyser le code peut être considéré comme du temps en moins pour tester la sécurité de l’application. Normalement toutes les vulnérabilités du côté client peuvent être détectées sans avoir à lancer le code, mais dans la pratique, cela se révèle plus compliqué. L’objectif de l’analyse de code sera donc plutôt de détecter des problèmes de sécurité plus ou moins évidents et de se faire une idée sur la sécurité globale de l’application. Pour ce type d’analyse, Il est recommandé d’utiliser le Framework Androguard qui permet de faciliter le travail d’analyse (permissions, instructions dangereuses, similarité entre 2 applications, etc.). Il existe aussi ARE [30], une machine virtuelle contenant une ancienne version d’Androguard [04].
5.2.1. Outils d’analyse statique : Parmi les outils permettant l’analyse statique d’applications sous Android, nous pouvons citer :
IDA pro version 6.1 [31]: Désassembleur. APKInspector [25]: Outil en interface graphique permettant d’analyser une application Android. Dex2jar [27]: Outil permettant de convertir une application android au format dex en fichier de class Java. Jd-gui [33]: Application graphique permettant de lire les codes-sources des fichiers .class (java) Androguard [19] : Androguard est un outil d'analyse statique populaire pour les applications Android. Il peut démonter et décompiler Dalvik bytecode. Il peut aussi
23 Chapitre I Etat de l'art
calculer une mesure de similarité pour détecter les applications reconditionnés ou logiciels malveillants connus. Il a également des modules qui peuvent analyser et récupérer des informations à partir de l’AndroidManifest.xml. Grâce à sa flexibilité, il est utilisé par certains autres cadres d'analyse qui doivent effectuer une analyse statique. Framework d’analyse d’applications Android. Androguard est principalement un outil écrit en python de jouer avec: Dex/Odex (Dalvik virtual machine) (.dex) (disassemble, decompilation), APK (Android application) (.apk), Android's binary xml (.xml), Android Resources (.arsc). Androguard est disponible pour Linux / OSX / Windows (python alimenté). JAD [32]: Décompilateur Java Dexdump [26]: Permet de décompiler les fichiers JAVA au format DEX Smali [36]: Assembleur / Désassembleur pour le format dex utilisé par dalvik.
6. Les travaux existants :
Il existe différents travaux sur l’analyse statique d’application afin de détecter des instances de malware. Les signatures sont des propriétés liées au malware telles que des chaines de caractères, des ressources dans l’application, des appels à des fonctions spécifiques, ou simplement l’empreinte d’un fichier.
6.1. DREBIN : Sous Android, Arp et al. ont proposé DREBIN [06] pour détecter les échantillons de malware Android sur les téléphones. Les propriétés prises en compte lors de l’analyse d’une application sont les permissions demandées, les composants matériels requis, ses composants, les filtres d’intent pour activer les composants, les appels aux fonctions sensibles, les permissions utilisées, les appels de fonction suspects et les adresses de serveur présents dans le code de l’application. Pour classifier les applications, ils utilisent une machine à vecteurs de support qui est une méthode d’apprentissage supervisée. Un apprentissage supervisé consiste à calculer à partir d’ensembles distincts un modèle permettant de définir l’appartenance d’un élément à un de ces ensembles. À partir de deux ensembles distincts d’applications, l’une contenant des applications malveillantes et l’autre contenant des applications bénignes, ils calculent ainsi un modèle de détection qui différencie les applications malveillantes des applications bénignes. Ce modèle est ensuite utilisé sur le téléphone afin de détecter les
24 Chapitre I Etat de l'art
applications malveillantes. L’évaluation effectuée par les auteurs de DREBIN sur la capacité de détection montre que leur outil atteint un taux de détection de 93.90% sur un ensemble de 1834 échantillons de malware. Le taux de détection définir pourcentage d’échantillons détectés sur tout le jeu de données. Le résultat est proche des meilleurs résultats obtenus par les produits anti-virus qu’ils ont testé sur le même jeu de données. Les meilleurs taux de détection sont de 96.41% et de 93.71% tandis que le pire est de 3.99%. La détection par analyse statique montre cependant ses limites lorsque les développeurs de malware utilisent des techniques d’obfuscation afin de cacher la véritable nature de leurs application ou des techniques de polymorphisme et de métamorphisme afin de changer l’aspect du code des différentes instances d’un malware. Les développeurs du malware Obad.a utilisent par exemple des chaines aléatoires pour les noms de variables, méthode et classes. Ils utilisent également des fonctions de chiffrement afin de masquer les chaines de caractères utilisées dans le malware et ces fonctions changent d’un échantillon à l’autre.
6.2. Kirin : L’approche basique utilisée par les applications malveillantes sous Android est de demander toutes les permissions qui leur sont nécessaires pour effectuer leur tâche malveillante. Par exemple, les applications espionnes dont le but est de tracer l’utilisateur du téléphone demande l’accès aux données de géolocalisation et l’accès à internet. Afin de bloquer ce type d’attaque, Enck et al. proposent un système nommé Kirin dans [17]. Le but de Kirin est de vérifier qu’une application n’a pas un ensemble de permissions jugé dangereux. Par exemple, l’accès aux données de géolocalisation et à internet permet de faire fuir les déplacements de l’utilisateur de téléphone. Ainsi, Kirin vérifie à l’installation les permissions demandées par une application. Si elle contient un ensemble dangereux, l’installation est bloquée. Il appartient à l’utilisateur ou à l’administrateur de l’appareil de définir les ensembles de permission dangereux.
6.3. Woodpecker: Les permissions filtrent l’accès aux ressources sensibles sous Android. Une application sans la permission READ_SMS ne peut par exemple lire la base de données des SMS. Dans [07], Grace et al. Ont analysé les applications livrées avec téléphones Android et montré que certaines exposaient sans aucune restriction les ressources sensibles. Les auteurs ont identifié deux méthodes. La première méthode, qu’ils disent explicite, consiste à exposer les méthodes pour accéder aux ressources sensibles via des interfaces publiques dont l’accès est plus laxiste que celui de la méthode protégée. Ils considèrent comment interface les composants exposés publiquement
25 Chapitre I Etat de l'art
à d’autres applications. La deuxième méthode, cette fois-ci implicite, consiste à partager le même identifiant d’utilisateur entre deux applications. Cela est possible en associant la même valeur à l’attribut sharedUserId dans le fichier AndroidManifest.xml des deux applications. Les deux applications tournant avec le même identifiant utilisateur, elles se retrouvent ainsi à l’exécution avec l’union des permissions que les deux applications possèdent. Grace et al. ont ainsi développé Woodpecker un outil pour analyser les applications et trouver d’éventuelles expositions de ressources sensibles. Woodpecker définit les points d’entrée de l’application à partir de son fichier Android Manifest.xml, construit son graphe de flux de contrôle (Control Flow Graph en anglais) et à partir du CFG calcule tous les chemins d’exécution possibles. L’outil considère qu’une ressource sensible est exposée explicitement si un chemin d’exécution partant d’une interface non protégée contient un appel à une fonction sensible et qu’aucun contrôle n’est fait avant l’appel. Pour le deuxième cas, une alerte est levée si une application indique partager son identifiant utilisateur et s’il existe un appel à une fonction sensible dans le code de l’application telle que la partie contenant cette fonction puisse être atteinte.
26 Chapitre I Etat de l'art
Conclusion : Nous avons présenté dans ce chapitre le système Android et introduit la base de connaissance nécessaire pour comprendre notre approche. Nous avons présenté dans Premier section le système Android : le noyau, l’espace utilisateur en insistant sur les applications et la manière dont ils coopèrent. Dans la section qui suit, Nous avons présenté les différents mécanismes de sécurité protégeant ce système. Ces mécanismes ont pour but de protéger les applications, les ressources qu’elles utilisent et les communications entre ces processus. Ces mécanismes ne sont cependant pas parfaits et nous montrons dans la section qui suit leurs limites ainsi qu’un aperçu des menaces que représentent les malware 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 avons présenté les malware Android et les Technique de détection des malwares. Enfin, Nous avons présenté les travaux existant.
27
Chapitre II Machine Learning
Chapitre II Machine Learning
Introduction : Le domaine de la machine learning inclut la construction d'un modèle à partir de données grâce à l'utilisation d'un algorithme. Ce modèle va au mieux généraliser, en représentant ou en approximant les données. Il permet, selon les données qu'on lui donne en input, de prédire celles inconnues ainsi que de mieux comprendre celles existantes. Le domaine d'application du machine Learning est très varié : la prédiction de valeurs financières,, la détection d'intrusion dans le domaine de la sécurité informatique, le moteur de recherche influençable par le profil de l'utilisateur, la détection de vols de machine, l'implémentation d'un anti-virus et la cryptanalyse.
1. Le cycle de vie d'une machine learning : Le cycle de vie d'une implémentation de la machine learning est la suivante [09] : 1. Obtention et nettoyage des données
2. Réalisation du modèle
3. Phase d'apprentissage
4. Phase de validation
5. Phase d'exécution
1.1. Obtention des données et pré-processing: La première étape à réaliser est donc l'obtention de données en suffisance, représentatives du problème à résoudre. Ceci n'est pas toujours aisé. Certaines informations sont plus coûteuses à obtenir que d'autres. Par exemple, un header d'un paquet réseau est plus simple à obtenir qu'une information dans la partie data quand celle-ci est chiffrée. La deuxième étape est le nettoyage, appelé aussi" pré-processing ", de la donnée récoltée, c'est-à-dire une réduction de ce qui est strictement intéressant, ainsi que leur traduction. Le but de cette étape est une meilleure précision du modèle, une optimisation de son temps d'exécution et de son apprentissage ainsi que de sa taille. Voici quelques exemples de nettoyage : 1. Transposer un ensemble de nombres vers un range [0,1]. 2. Transposer un ensemble de réels vers un ensemble de naturels. 3. Ajouter des valeurs qui ont été calculées à partir des données récoltées. 4. Sélectionner un résumé des informations. 5. Enlever les informations inutiles représentant du bruit
29 Chapitre II Machine Learning
Ce nettoyage est souvent très compliqué à mettre en œuvre et demande une bonne connaissance des données à traiter. C'est pourquoi des techniques automatiques ont fait l'objet de recherches : ce sont les techniques de " feature sélection ". L'article [14] donne un exemple d'une méthode pour choisir les bonnes informations à présenter à un IDS. 1.1.1. La sélection des caractéristiques : Il existe essentiellement 3 types de méthodes de " Feature sélection ". On retrouve d'abord les " Filtre méthodes ", qui ne se basent que sur l'utilité d'une variable sans tenir compte de son impact dans le modèle. Ensuite on a les "Wrapper méthode " qui tiennent compte de l'algorithme d'apprentissage pour déduire l'apport des variables. Enfin, on distingue aussi les "Embedded méthode " qui sont spécifiques à un modèle et sont exécutées lors de la procédure d'apprentissage. Ces méthodes peuvent être combinées pour obtenir de meilleurs résultats. Il est conseillé de ne pas utiliser les mêmes données pour les phases de Feature sélection et d'évaluation, pour éviter un biais au niveau des performances estimées du système. Après avoir obtenu les données nettes du problème, la prochaine étape est la réalisation du modèle.
1.2. Réalisation du modèle : Elle consiste en une recherche de la meilleure structure ainsi que l'ensemble des paramètres à initialiser dedans. La complexité, et plus précisément la qualité, du modèle aura une influence directe sur la précision de la généralisation des données. Plusieurs types de modèles vont être présentés dans la suite. Après avoir construit le modèle, il est nécessaire de le configurer selon le problème à traiter grâce à la phase d'apprentissage.
1.3. Phase d'apprentissage Un sous-ensemble de l'ensemble des informations nettoyées forme les données d'entrainement, permettant d'exécuter la phase d'apprentissage du modèle. Ceci permet d'ajuster les paramètres du modèle. Il existe plusieurs sortes d'algorithmes d'apprentissage. Certains de ces algorithmes sont supervisés et d'autres non supervisés. Un algorithme supervisé est un algorithme à qui on présente l'entrée et la sortie (ou la cible) désirée en supposant qu'il y a une relation inconnue mais réelle entre les deux. Il devra minimiser l'erreur entre la sortie désirée et celle qu'il produit. Ils sont souvent utilisés pour des problèmes de reconnaissance. Un algorithme non supervisé est un algorithme à qui on présente l'entrée mais dont la sortie est inconnue. Ce type d'algorithmes est souvent utilisé pour des problèmes de partitionnement où le nombre et la nature des partitions ne sont pas
30 Chapitre II Machine Learning
connus a priori. Néanmoins, ce dernier ne donne aucun résultat si les données ne contiennent pas de partitions. Après avoir entraîné le modèle, il est important de le valider pour éviter le sur-apprentissage. 1.3.1. Sur-Apprentissage Le sur-apprentissage a lieu quand le modèle prédit correctement les données présentées lors de la phase d'apprentissage mais a des mauvais résultats lors de la phase d'exécution. Pour éviter le sur-apprentissage, on peut utiliser l'une des méthodes suivantes : 1. On regarde empiriquement le nombre de périodes de la phase d'apprentissage pour qu'il n'y ait pas de sur-apprentissage. 2. Le "early stopping " est une technique où on divise les informations en deux parties. La première partie permet d'entraîner le modèle, la deuxième permet de le tester. On procède ainsi en le réalisant plusieurs fois et on regarde les erreurs. Au début, les fautes vont diminuer mais, petit à petit, les erreurs sur la partie test vont commencer à augmenter lorsqu'il y aura un sur-apprentissage. Et c'est à ce moment qu'il faut arrêter l'apprentissage. Ainsi, on gagne aussi sur le temps nécessaire pour l'apprentissage. D'autres méthodes existent et sont présentées dans la section de validation.
1.4. Phase de validation Durant cette phase, on va tester et valider le modèle et ses paramètres selon des critères se basant sur ses résultats. Il permet d'obtenir le meilleur modèle généralisant les données obtenues lors de la phase d'apprentissage. Pour cela, on a un ensemble d'exemples pour l'apprentissage et un autre pour les tests. Voici quelques méthodes pour les tests : 1. Hold-out : On coupe aléatoirement l'ensemble des informations en deux groupes : groupe d'apprentissage et groupe de tests. 2. Leave-one-out : Cette méthode sort de l'ensemble des informations une donnée en particulier et la laisse de côté, puis construit le modèle avec celles restantes et enfin évalue la structure avec l'exemple laissé de côté. On répète le processus pour chacune des données de l'ensemble de données. Ainsi, on peut avoir une moyenne globale de la précision du modèle. 3. Cross-validation : Cette méthode réalise un partitionnement des données de manière aléatoire en n groupes. On utilise une partition comme un ensemble de test et le reste pour former celui d'entraînement. Comme précédemment, on applique un algorithme à l'ensemble d'entraînement et on évalue le modèle résultant sur celui de tests. On répète ce processus pour chaque partition et on regarde l'erreur moyenne. D'autres méthodes
31 Chapitre II Machine Learning
existent telles que le bootstrap. Enfin, après avoir validé le modèle, il reste à quantifier ses performances en pratique.
1.5. Performance du modèle : Apres avoir choisi et évalué notre modèle, il est intéressant de pouvoir quantifier ses performances. Pour cela, on compare plusieurs modèles sur un même jeu de données. En effet, certains sont plus adaptés pour certains problèmes. Lors de cette phase, il est primordial de ne pas enlever de données pour ne pas biaiser l'évaluation. Pour cette phase, on s'intéresse au pourcentage de vrais positifs, de vrais négatifs, de faux négatifs et enfin de faux positifs. Néanmoins, ça n'inclut pas la taille du modèle ni son temps d'apprentissage ou son temps d'exécution. La technique " receiver operating characteristic (ROC) " est largement utilisée et permet de tester une structure. Concrètement, un ROC est une courbe d'un modèle représentant ses vrais positifs par rapport à ses faux positif. L'aire sous cette courbe représente la performance du modèle.
2. Types de modèle: Il existe plusieurs types de modèles. Outre le fait qu'ils sont différenciables par leur côté supervisé ou non supervisé, ils le sont aussi par leur côté " classification " ou "régression " Le premier classifie les données et le deuxième prédit des valeurs pour chaque donnée. Puisque le problème de l'IDS semble être un problème de classification, ce qui suit est une liste non exhaustive de modèles de classification qui pourraient être envisagées pour la mise en place d'un IDS.
2.1. Modèle supervisé:
2.1.1. Neural network : Les réseaux neuronaux permettent d'approximer toutes les fonctions. Ils sont largement utilisés grâce à leur capacité de traiter de grandes quantités d'informations et à leur stabilité face au bruit. Les réseaux neuronaux sont un ensemble de petit processeurs, appelés neurones, travaillant en pseudo-parallèle. Ces neurones reçoivent des données et les renvoient, après une transformation appelée fonction d'activation, à d'autres neurones ou à une source externe. Les canaux de communication entre eux contiennent chacune une certaine valeur représentant la capacité de transfert d'information. Ces valeurs sont modifiées lors de la phase d'apprentissage. L'ensemble de neurones est partitionné par couche : une d'entrée, des cachées et enfin une de sortie. Il existe plusieurs manières de différencier les réseaux neuronaux. Ils peuvent l'être par leur côté feed-forward ou feed-
32 Chapitre II Machine Learning
back, le deuxième permettant de réaliser comportement plus dynamique et complexe que le premier en prenant en compte l'écoulement du temps et en permettant d'avoir des boucles dans le réseau. Le réseau feed-forward semble être plus efficace pour des problèmes de classification et de reconnaissance de forme. L'algorithme d'apprentissage permet aussi de différencier les réseaux neuronaux. Il y a l'apprentissage par descente du gradient et par l'algorithme de Widrow-Hoff pour les réseaux feed-forward. Pour les réseaux feed-back, il y a la rétropropagation récurrente, la rétropropagation dans le temps (BPTT) et l'apprentissage temporel récurrent en temps réel (RTRL). Il existe d'autres types d'apprentissage selon que le réseau est supervisé ou non supervisé. Pour le cas non supervisé, on peut utiliser le Hebbian Learning Rule ou le Competitive Learning Rule. Le Hebbian Learning Rule augmente les valeurs des connexions entre deux neurones qui s'activent simultanément et les diminue dans le cas inverse. Le Competitive Learning Rule définit des neurones spécialisés pour certains cas d'input. Pour le cas supervisé, on peut utiliser des algorithmes tels que la rétropropagation ou le Boltzman learning rule. Le choix du nombre de neurones ainsi que du nombre de couches est empirique et est dépendant de plusieurs facteurs tels que le volume de données à traîter, la puissance du CPU, la précision voulue, le temps d'apprentissage maximum,. . .
2.1.2. Instance-Based Learning : L'apprentissage consiste seulement à stocker les informations dans un ensemble. Ce genre de méthodes s'appelle également lazy learning. La classification d'une nouvelle observation se fait en regardant la distance entre les informations et l'observation. Le résultat est la classe la plus proche de l'observation. Pour un grand nombre d'exemples, la performance d'exécution peut être prohibitive mais l'indexation est rapide.
2.1.3. k-nearest neighbor : Ce modèle appartient à la famille du _ Instance-Based Learning. Les k plus proches voisins de l'exemple à prédire sont cherchés. La classe majoritaire de ces voisins est retournée comme réponse pour cet exemple. La distance peut être calculée grâce à une distance Euclidienne ou autre. L'apprentissage est simple puisqu'il faut uniquement mémoriser les exemples. Mais la prédiction peut être très lente puisqu'il faut chercher les k plus proches voisins, dans un espace à dimension potentiellement très élevée.
2.1.4. Naive Bayes : Cette méthode utilise les règles de Bayes. Une hypothèse est que chaque classe d'exemples est indépendante. La phase d'apprentissage calcule chacune de leur probabilité et celle de chaque attribut la connaissant. Ceci se fait en regardant dans les exemples d'entraînement
33 Chapitre II Machine Learning
la fréquence d'apparition de la classe et de la valeur de l'attribut pour chaque classe. La phase d'exécution regarde la plus grande probabilité conditionnelle pour déterminer que telle instance inconnue appartient à telle classe connue. Un des points fort est le besoin d'une faible quantité d'informations pour la phase d'apprentissage.
2.1.5. Learning Décision Rules : Une règle de décision se compose d'un antécédent et d'une conséquence. Le premier est simplement une conjonction des attributs des exemples. Le second se compose d'un nom de label de classe. La méthode d'apprentissage choisit un exemple d'une classe et le généralise autant que possible sans avoir une intersection avec des exemples venant d'autres classes. Par la suite, l'algorithme enlève chaque exemple de la même classe qui satisfait la règle. Ceci est itéré jusqu'il n'y ait plus d'exemples. AQ19 [10] est une implémentation du spécifique-au-général. CN2 [10] en est une du général-au-spécifique. RIPPER [10] construit des règles en agrandissant les conditions de chacune d'entres elles. La phase d'exécution compare les valeurs des attributs de l'observation et des conditions de chaque règle. Si elle satisfait toutes les conditions d'une règle, le résultat est le label de la classe se trouvant dans le conséquent. Si elle ne satisfait aucune des règles, on prend la règle où les conditions sont les plus respectées.
2.1.6. Learning Decision Trees : Cette méthode est équivalente au" Learning Decision Rules ". L'arbre acyclique contient des nœuds étiquetés par des attributs. Chaque arrête est étiquetée par un prédicat qui s'applique aux nœuds parent. Chaque feuille est étiquetée par une classe qui est l'attribut cible. L'apprentissage construit un arbre récursivement en choisissant l'attribut qui coupe au mieux les exemples dans leurs propres classes, créant des nœuds enfants pour chaque valeur de l'attribut choisi. Itérativement, l'algorithme enlève ceux choisis en créant des nœuds enfants. Les algorithmes pour créer un arbre de décision sont : ID3, C4.5, CART. Pour classifier un exemple, il faut partir de la racine de l'arbre et descendre jusqu'à une feuille en respectant les prédicats.
2.1.7. Quarter-sphere SVM : Cette méthode englobe tous les exemples d'une classe dans une sphère alors que ceux qui se retrouvent en dehors de la sphère sont étiquetés comme appartenant à une autre classe. Le paramètre du modèle est son rayon.
34 Chapitre II Machine Learning
2.2. Modèle non supervisé: K-means Cette méthode réalise un partitionnement des informations en k classes. Pour cela, Il faut choisir k centroïdes aléatoirement, qui sont des représentants des k partitions. Chaque exemple est associé au centroïde le plus proche. Après ça, un nouveau centroïde est formé en calculant la moyenne des exemples d'une même partition. Et ainsi de suite jusqu'à se qu'il y ait une stabilisation. Le point fort de cette méthode est la rapidité de convergence vers une stabilisation quand elle est possible. Néanmoins, la valeur k est difficile à déterminer ainsi que l'emplacement initial des centroïdes.
2.2.1. Single Linkage Clustering : Ceci est une variante de K-means. Elle véri_e qu'un exemple n'excède pas une certaine distance W de toute classe. Dans le cas contraire, elle lui en assigne une nouvelle.
2.2.2. Self organizing map ou self organizing Feature Maps (SOFM) : Ce modèle est un réseau de neurones feedforward à une couche non supervisé, permettant de mieux visualiser les informations données en entrée. On obtient une vue respectant la distance entre les informations initiales. C'est-à-dire qu'un ensemble d'informations différentes sera visiblement séparé sur la carte alors que des données semblables seront visiblement proches. Ce modèle est souvent utilisé pour cartographier des données de grandes dimensions en 1D, en 2D ou en 3D. L'apprentissage est de type compétitif, ce qui signifie que les neurones sont en compétition pour représenter les données. Ainsi, ils se spécialisent pour certains types de données. L'augmentation du nombre de neurones améliore la précision du réseau mais accroît aussi drastiquement le temps d'exécution. De plus, un de ses points faibles est son temps d'exécution pour des données de grande dimension puisque la distance entre tous les neurones doit être calculée pour chaque input. Par ailleurs, lors de l'apprentissage, les connexions du neurone gagnant et des neurones avoisinants doivent être modifiées.
2.2.3. Gamma-algorithm : Ce modèle assigne une valeur à chaque exemple. Cette valeur est sa distance moyenne par rapport à ses k plus proches voisins.
2.2.4. Machine à vecteur de support (SVM): Cette technique initiée par Vapnik [03] tente de séparer linéairement les exemples positifs des exemples négatifs dans l'ensemble des exemples. Chaque exemple doit être représenté par un vecteur de dimension n. La méthode cherche alors l'hyperplan qui sépare les exemples positifs des exemples négatifs, en garantissant que la marge entre le plus proche des positifs et des négatifs soit maximale. Intuitivement, cela garantit un bon niveau de
35 Chapitre II Machine Learning
généralisation car de nouveaux exemples pourront ne pas être trop similaires à ceux utilisés pour trouver l'hyperplan mais être tout de même situés franchement d'un côté ou l'autre de la frontière. L'intérêt des SVM est la sélection de Vecteurs Supports qui représentent les vecteurs discriminant grâce auxquels est déterminé l'hyperplan. Les exemples utilisés lors de la recherche de l'hyperplan ne sont alors plus utiles et seuls ces vecteurs supports sont utilisés pour classer un nouveau cas. Cela en fait une méthode très rapide [11]. 2.2.4.1. Apprentissage statistique : La théorie d’apprentissage statistique étudie les propriétés mathématiques des machines d’apprentissage [16]. Ces propriétés représentent les propriétés de la classe de fonctions ou modèles que peut implémenter la machine. L’apprentissage statistique utilise un nombre limité d’entrées (appelées exemples) d’un système avec les valeurs de leurs sorties pour apprendre une fonction qui décrit la relation fonctionnelle existante, mais non connue, entre les entrées et les sorties du système. On suppose premièrement que les exemples d’apprentissage, appelés aussi exemples d’entrainement, sont générés selon une certaine probabilité inconnue (mais fixe) c’est-à- dire indépendants et identiquement distribués (iid). C’est une supposition standard dans la théorie d’apprentissage. Les exemples sont de dimension m (Є Rm) et dans le cas d’apprentissage supervisé, accompagnés d’étiquettes caractérisant leurs types ou classes d’appartenance. Si ces étiquettes sont dénombrables, on parle de classification sinon on parle de régression. Dans le cas d’une classification binaire cette étiquette est soit +1 ou -1. L’ensemble des exemples et leurs étiquettes correspondantes est appelés ensemble d’apprentissage. Une machine efficace d’apprentissage est une machine qui apprend de l’ensemble d’entrainement une fonction qui minimise les erreurs de classification sur l’ensemble lui-même. Soit D = {(x1; y1);…; (xn; yn)} l’ensemble des exemples d’entrainement, avec xi ЄRm et yi = ±1, et soit (x) la fonction apprise par la machine d’apprentissage. On appelle le risque empirique Remp [ ] le taux d’erreurs effectuées par la fonction sur l’ensemble d’entrainement D.
avec,
Puisque l’ensemble D ne représente qu’une simple partie de tout l’espace d’exemples, la fonction apprise f, qui minimise le risque empirique, peut se comporter mal avec les nouveaux exemples non vus à l’entrainement. C’est un phénomène très connu en
36 Chapitre II Machine Learning
apprentissage automatique appelé le sur-apprentissage ou apprentissage par cœur. Pour garantir que f, prenne en charge même les exemples non jamais vus, il faut contrôler sa capacité de généralisation mesurée souvent sur un autre ensemble d’exemples appelé ensemble de test réservé uniquement pour tester la machine apprise. La fonction f recherchée doit donc minimiser les erreurs de classification sur les deux ensembles : d’entrainement et de test. Trouver la fonction optimale f revient toujours à un problème d’optimisation, ce qui explique la forte relation entre l’apprentissage et l’optimisation. Avant de rechercher la fonction f, il faut définir son type puis rechercher ses paramètres. Dans le cas des machines à vecteur support, la fonction recherchée est de forme linéaire. Les SVMs sont, donc, des systèmes d’apprentissage qui utilisent un espace d’hypothèses de fonctions linéaires dans un espace de caractéristique à haute dimension. Cette stratégie d’apprentissage introduite par Vapnik et ses co-auteurs est une méthode très puissante. Elle a pu, en quelques années depuis sa proposition, conquérir la plupart des autres systèmes d’apprentissage dans une grande variété de domaines d’application. 2.2.4.2. SVMs binaires : Le cas le plus simple est celui où les données d’entrainement viennent uniquement de deux classes différentes (+1 ou -1), on parle alors de classification binaire. L’idée des SVMs est de rechercher un hyperplan (droite dans le cas de deux dimensions) qui sépare le mieux ces deux classes (figure 2.1).
Figure II.1 : SVM binaire.
Si un tel hyperplan existe, c’est-à-dire si les données sont linéairement séparables, on parle d’une machine à vecteur support à marge dure (Hard margin).
37 Chapitre II Machine Learning
Figure II.2 : L’hyperplan H optimal, vecteurs supports et marge maximale.
2.2.4.3. Linéarité et non-linéarité : Parmi les modèles des SVM, on constate les cas linéairement séparables. les cas non linéairement séparables. Les premiers sont les plus simples des SVM car ils permettent de trouver facilement le classificateur linéaire. Dans la plupart des problèmes réels il n’y a pas de séparation linéaire possible entre les données, le classificateur de marge maximale ne peut pas être utilisé car il fonctionne seulement si les classes de données d’apprentissage sont linéairement séparables [32].
Figure II.3 : à gauche cas linéairement séparable, à droite non linéairement séparable.
38 Chapitre II Machine Learning
Conclusion : Dans le présent chapitre, nous avons présenté les machines learning, Le cycle de vie d'une implémentation de la machine learning, type de modèle de la machine learning (supervisé et non supervisé) et on détaillé une technique de classification automatique supervisée : machine à vecteurs supports (ou séparateurs à vaste marge) qui est une étape importante dans notre approche.
39
Chapitre III Notre Approche
Chapitre III Notre approche
Introduction : Pour détecter les logiciels malveillants sur un Smartphone, nous proposons une méthode de détection de logiciels malveillants Android. Le travail est discuté en détail dans ce chapitre. Ce chapitre contient le plan de travail global de notre méthode. Figure 3.1 illustre la structure de flux de travail d'expérimentation il est composé de quatre phases. La première étape est la phase de collection de données, qui recueille des applications normales et malveillantes. La deuxième phase, qui est la sélection et l'extraction des caractéristiques, les objets sélectionnés sont extraits, étiquetés et stocké pour utiliser dans la phase suivante. La classification des enchantions se fait en utilisant la machine Learning cette classification représente la troisième phase. La dernière phase est la phase d’expérimentation et le choix d'un classificateur sur des données empiriques obtenues, afin de construire notre cadre.
1. Notre Contributions : Notre contribution s’est faite en 03 étapes :
A. Téléchargement automatique des applications : 5 0000 Apps 5 500 Malwares B. Le service web virustotal Scan : Uploade toutes les apps au service virustotal 56 antivirus scan pour chaque application Récupérer les résultats de scan Normalisation du résultat obtenu C. Analyse des applications : Extraction de métadonnées pour chaque application.
41 Chapitre III Notre approche
Figure III.1 : L’architecture de notre Contributions.
1.1. Sous-système De Téléchargement automatique des applications : Afin d’évaluer notre future proposition nous avons créé un système de téléchargement automatique des applications android à partir 4 site web:
1. m.163.com.
2. aptoide.com.
3. slideme.org.
4. appchina.com.
Les résultats obtenus sont représenté comme suit:
5500,0 11%
Malwares apps Normale apps 46500,0 89%
42 Chapitre III Notre approche
Figure III.2 : jeu de données.
1.1.1. Applications normales : Après le filtrage de (46 500 applications normale), on a éliminé toutes les applications redondantes et aussi toutes les applications détecté par au moins d’un antivirus. Après la phase de filtrage on a obtenu 26 000 applications prêtes pour la phase d’analyse. Ces 26 000 applications sont distribuées comme suite:
6768,0 26%
jeux 19312,0 74% Applications
Figure III.3 : La distribution de normale apps.
Les 19312 applications sont distribuées comme suite:
Tools 665,0 524,0 503,0 684,0 Entertainment 709,0 Personalization 3650,0 Productivity 726,0 Music & Audio 824,0 Communication 1706,0 Education Lifestyle 1574,0 Social 1015,0 1321,0 907,0 Media & Video Books & Reference 948,0 Photography Travel & Local Applications & News & Magazines
Figure III.4 : La distribution des applications.
43 Chapitre III Notre approche
Les 6768 jeux sont distribués comme suite:
Casual 665,0 1213,0 Arcade & 678,0 Action
Puzzle 891,0 829,0 Arcade
Brain & Puzzle
Figure III.5: La distribution des jeux.
II.1.1 Applications malveillant : Pour les 5 500 malware constituer notre jeu de données malware, on a plus de 150 familles de malwares. Ces familles de malwares sont distribuées comme suite:
FakeInstaller DroidKungFu 92,091,0 Plankton 132,0 925,0 Opfake 147,0 GinMaster 152,0 BaseBridge 330,0 667,0 Iconosys Kmin 339,0 FakeDoc 625,0 Geinimi 613,0 Adrd DroidDream ExploitLinuxLotoor MobileTx Glodream FakeRun SendPay
Figure III.6 : Top 20 Familles de malware Android.
44 Chapitre III Notre approche
1.2. Sous-système De Service web Virus Total : Il existe plusieurs scanners de virus sous Android dont certains sont disponibles directement sur Google Play. Il existe cependant pour les analystes des services permettant d’analyser les applications Android pour détecter les échantillons de malware sans avoir à les analyser avec une application dans un téléphone. VirusTotal est un service web en ligne qui analyse les fichiers suspects et facilite la détection rapide des malware Pour effectuer une analyse, le Sous-Système soumet le Sha256 de fichier à analyser via Api de VirusTotal. Les utilisateurs soumettent le fichier à analyser via une page de soumission. Chaque fichier soumis est ensuite analysé par différents produits anti-virus afin de détecter si oui ou non il est malveillant. VirusTotal utilise à ce jour 49 produits anti-virus. Le résultat des analyses de chaque anti-virus est ensuite retourné à l’utilisateur. Zhou et al. ont par exemple utilisé VirusTotal afin de classifier les échantillons de malware qu’ils ont analysé dans [36].
Normalisation Calcule le Uploade le Sha256 de des résultats Sha256 pour obtenu chaque App chaque app au Virustotal
• calculate_sha256.py • scan_files.py • CsvFile.py
Figure III.7 : Sous-Système De Service web VirusTotal.
Taux de Détection 101 100 99 98 97 96 95 94 Taux de Détection
93
V3
-
Prot
AVG
-
Avira
Cyren
VIPRE
eScan
F
GData
Aware
-
Secure
DrWeb
-
NOD32
Sophos
-
McAfee
AVware
-
Comodo
Emsisoft
F
AegisLab
Antivirus
-
Ad
Kaspersky
AhnLab
BitDefender
ESET
NANO MicroWorld
Figure III.8 : Les 20 Premiers antivirus.
45 Chapitre III Notre approche
Taux de Détection 80 70 60 50 40 30 20
10 Taux de Détection
0
…
…
-
AVL
GW
-
CMC
Bkav
Zillya
-
Rising ALYac
Panda
VBA32
ClamAV
ViRobot
Norman
Agnitum
nProtect
Microsoft
Symantec
Antiy
TheHacker
K7AntiVirus
TrendMicro
McAfee
TotalDefense SUPERAntiSpywa
Figure III.9: Les 20 Derniers antivirus
2. Notre approche : L’objectif de cette thèse est de développer une méthode afin de caractériser et détecter les malwares Android. La réalisation de cet objectif s’est faite en plusieurs étapes :
1. La collection de jeu de données (applications android)
2. L’étape d’analyse
3. L’extraction des caractéristiques
4. Méthode de détection des malwares
46 Chapitre III Notre approche
Figure III.10: notre proposition.
2.1. Sous-système D’analyse d’applications Android : L’analyse peut également avoir pour but d’extraire des métadonnées liées à l’application. Dans le cas d’applications Android, ces données sont généralement le contenu du fichier AndroidManifest.xml. Ce fichier contient différentes informations : permissions utilisées par l’application, son numéro de version, la liste de ses composants, etc. L’accès à son contenu ne nécessite pas forcément un outil particulier car il s’agit d’un fichier XML. Androguard propose cependant d’extraire automatiquement ces données.
2.1.1. Extraction de métadonnées pour chaque application : Dans la phase d'extraction de métadonnées, le système examine statiquement les échantillons de logiciels malveillants apk et bénignes et recueillies afin de déterminer et d'extraire les caractéristiques nécessaires. En outre, il analyse le code source décompilé d'une application, en identifiant les autorisations (used permissions) utilisées requises par l'application, les appels d'API (API calls), ainsi que d'autres caractéristiques pour la détection des malwares. Le système utilise les informations extraites à l'aide d’Androguard pour construire les catégories de fonctionnalités suivantes:
47 Chapitre III Notre approche
1 public void onClick(android.view.View p6) 2 { 3 if(this.mJetBoyThread.getGameState() != 15) { 4 ... 5 } else { 6 this.mButton.setText("PLAY!"); 7 this.mTextView.setVisibility(0); 8 this.mTextView.setText(1.76787404569e+38); 9 this.mJetBoyThread.setGameState(0); 10 } 11 return; 12 }
Figure III.11 : Extrait du code résultant de la décompilation de l’application JetBoy avec le décompilateur par défaut d’Androguard.
2.1.1.1. Hardware components: Cette caractéristique contient les composants matériels demandés. Si une application demande l'accès à la caméra (android.hardware.camera), touchscreen ou le module de GPS (android.hardware.location.gps) de smartphone, ces caractéristiques doivent être déclarées dans le fichier manifeste. Le système sélectionne un nombre total de (22) used
feature utilisées.
2.1.1.2. Requested Permissions : Un des mécanismes de sécurité les plus importantes dans Android est le système d'autorisation (Permissions). Chaque application Android doit inclure, dans le fichier manifeste, une liste de demander des autorisations pour accéder à certains éléments restreints, tels que périphériques (appareil photo, GPS, système de fichiers, ...), les données sensibles du système (contacts, favoris, ...), et l'accès à certaines parties d'autres applications. Les logiciels malveillants tend à demander certaines autorisations la plus souvent inoffensive application. Par exemple, INTERNET demande le droit d'accéder à la Internet, READ_CONTACTS
demande le droit d'accéder à la liste des utilisateurs de contact, et un grand pourcentage de malwares actuelle envoie des messages SMS premium et demande les permissions SEND SMS, READ_SMS, RECEIVE_SMS, WRITE_SMS ainsi. Le système rassemble (85) Permissions à la fois dangereuses et inoffensives.
48 Chapitre III Notre approche
Figure III.12: Les permissions d’androïde d’application opera_mini_65.
2.1.1.3. Used Permissions : Cet ensemble de caractéristiques est une liste de toutes les autorisations dangereuses utilisées. Il n'y a pas un fichier qui décrit les autorisations effectivement utilisées par une application. Par conséquent, notre système doit analyser le fichier dex pour identifier les autorisations qui sont effectivement utilisés par l'application. Par exemple: WRITE_EXTERNAL_STORAGE, INTERNET, ACCESS_NETWORK_STATE, CHANGE_WIFI_MULTICAST_STATE
2.1.1.4. API Calls : Contrairement aux travaux précédents, nous ne suivons pas une approche heuristique pour identifier des APIs dangereuses pour le fonctionnement des logiciels malveillants. Au lieu de cela, nous cherchons à identifier de manière fiable les principales APIs qui invoquent par les malwares en analysant statiquement nos échantillons. Effectivement, nous avons analysé statiquement une large gamme d'applications de logiciels malveillants et bénignes et nous avons généré une liste des appels d'API distinctes au sein de chaque gamme. Des APIs distinctes se réfèrent à une combinaison distincte de Nom de classe, Nom de méthode, et de descripteur. Nous effectuons ensuite une analyse fréquente pour sélectionner ces API qui sont plus utilisés dans le malware que dans la gamme bénigne. En outre, nous avons défini la liste des API pour inclure seulement ceux qui ont un usage différent, supérieur ou égal à un certain seuil. Certains appels d'API permettent d'accéder à des données sensibles ou des ressources, et sont fréquemment trouvées dans les échantillons de logiciels malveillants. Notre sysstèm recueille les types d’API calls suivante:
49 Chapitre III Notre approche
API Calls pour accéder aux données sensibles, telles que getSubscriberId(), getDeviceId(), getLine1Number(), getSimSerialNumber(), getNetworkOperator(), and getCellLocation(). API Calls pour envoyer et recevoir des messages SMS / appels téléphoniques, comme : sendTextMessage(). API Calls pour l'exécution de commandes externes, telles que ClassLoader.loadClass() and System.loadLibrary(). API Calls pour la communication en réseau, comme : HttpURLConnection() and Socket(). API Calls utilisées pour le chiffrement, comme : Cipher.getInstance(). Le système regroupe 1472 appels API potentiellement dangereuses.
2.1.1.5. Intents : La communication inter-processus sur Android est effectuée principalement par les intentions. Notre système collecte un ensemble d'intentions suspectes comme un autre ensemble de fonctionnalités. Un exemple typique d'un message intention impliqué dans malware est BOOT COMPLETED, qui est utilisé pour déclencher une activité malveillante directement après le démarrage de l'appareil. Notre système sélectionne 55 intentions suspectes. Par exmple : Intent.setPackage, ACTION_PACKAGE_REMOVED, ACTION_CALL, ACTION_PACKAGE_CHANGED, ACTION_PACKAGE_ADDED, ACTION_SEND.
2.1.1.6. Risks : Androrisk est un autre utilitaire d’Androguard, qui identifie «drapeaux rouges» en fonction des autorisations, les bibliothèques partagées, et d'autres facteurs de risque. Le système contrôle les facteurs de risque suivants:
Code dynamique: DexClassLoader est un chargeur de classe qui charge les classes à partir de fichiers .jar et .apk. Cela peut être utilisé pour exécuter du code pas installé comme une partie d'une application. Code natif: les applications Android peuvent charger le code écrit en C / C ++ en utilisant le kit de développement natif (NDK). Code natif peut être utilisé pour améliorer les performances de l'application pour les applications gourmandes en ressources. Néanmoins, l'utilisation de code natif augmente le risque de l'application. Réflexion Java: Java Réflexion est utilisé pour examiner ou modifier le comportement d'exécution. Grâce à cette caractéristique, les applications Android peuvent charger les classes Java lors de l'exécution, qui peut être utilisé pour contourner les restrictions de l'API.
50 Chapitre III Notre approche
Crypto: Androrisk recherches pour l'utilisation de bibliothèques de chiffrement qui peut obscure partie du code qui évite une analyse statique
2.1.1.7. Content Access: Les fournisseurs de contenu parviennent à accéder aux référentiels centraux de données dans le système Android. Une forme particulière de l'URI, qui commence avec le contenu: //, est attribué à chaque fournisseur de contenu. Toute application peut interroger la boîte de réception de l'appareil en utilisant son contenu URI: // sms / boîte de réception, bien que la permission de SMS_READ doit être nécessaire pour l'accès. Le système localise accès via URI de (42) fournisseurs de contenu. android.content.BroadcastReceiver
android.content.BroadcastReceiver. Context: startService() , openFileOuput() , getFilesDir() , getApplicationInfo(), Après l’extraction des touts les caractéristiques nous allons créer le vecteur pour la phase d’apprentissage selon la fonction Fi, défini comme suite: Fi = 1; si elle est découverte par Le système,
Fi = 0; autrement.
Chaque application est affectée un vecteur défini par f = (f1, f2,…., fn), où fi est le résultat de l'ième Fi variables.
Enfin, Le système génère un vecteur de caractéristiques similaires à la figure III.13.
[1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Figure III.14 : Une partie d’exemple de vecteur de caractéristique pour l'application facebook.
51 Chapitre III Notre approche
2. Phase de Machine Learning: Dans la troisième étape, nous appliquons des techniques de machine d'apprentissage pour apprendre automatiquement une séparation entre les applications malveillantes et bénignes. L'application de machine d'apprentissage nous épargne de construire manuellement des règles de détection pour les caractéristiques extraites.
3.1. Algorithme de Machine Learning (svm) : Bien que plusieurs méthodes d'apprentissage puissent être appliquées à apprendre une séparation entre deux classes, seules quelques méthodes sont capables de produire une détection efficace et explicable. Nous choisissons le SVM Machines à support de Vecteur pour notre approche.
Figure III.15 : Un hyperplan séparateur avec un maximum marge (SVM).
3. Conclusion Dans ce chapitre, nous avons présenté la description de notre proposition de développer une méthode afin de caractériser et détecter les malwares Android. De plus, nous avons détaillé l’architecture de notre proposition.
52
Chapitre VI Implémentation et Expérimentation
Chapitre VI Implémentation
Introduction : Dans ce chapitre, on va détailler la réalisation et l'implémentation de notre contribution, on va voir également l’environnement de travail utilisé pour développer ce projet, puis nous présenterons le déroulement de principales tâches de notre logiciel.
1. Implémentation :
1.1. Environnement de travail : Pour réaliser notre proposition, nous avons utilisé l’environnement python (pycharm) dans le système d’exploitation Windows 7 et Linux.
Figure VI.1 : L’interface de l’environnement pycharm. 1.2. Androguard : Pour analyser les échantillons des applications android, nous utilisons principalement les outils Androguard et apktool. Nous servons principalement d’Androguard afin de décompiler à la volée le code des applications Android et d’apktool pour extraire le contenu des fichiers apk, décoder en clair le contenu des fichiers AndroidManifest.xml ainsi que pour désassembler en smali le code des applications.
54 Chapitre VI Implémentation
Dans ce qui suit on va voir en détail, les codes sources de l’application, et les résultats.
Figure VI.2 : Fonction d’extraction des caractéristiques.
55 Chapitre VI Implémentation
Figure VI.3 : Fonction de vecteur.
Figure VI.4 : Fonction de SVM.
56 Chapitre VI Implémentation
2. Expérimentation: Après La phase de détection et l’obtention les résultats nous la avons comparé avec les résultats de scan de 56 anti virus, Nous comparons notre proposition également contre 56 scanners anti-virus sur notre jeu de données. La performance de détection de chaque scanner est extraite du Service VirusTotal. Le résultat de comparaison se fait en 9 Itérations comme suite :
Chaque itération, notre système prend aléatoirement 1500 apps mal et 1500 apps normal pour la phase d’apprentissage et 1000 apps mal pour la phase de détection.
AV1 AVG AV21 AhnLab-V3 AV41 Bkav AV2 McAfee AV22 DrWeb AV42 Norman AV3 Avware AV23 Tencent AV43 Zillya AV4 Avira AV24 Fortinet AV44 Agnitum AV5 VIPRE AV25 K7GW AV45 McAfee-GW-Edition AV6 Cyren AV26 Ikarus AV46 Panda AV7 ESET-NOD32 AV27 Kingsoft AV47 ALYac AV8 Sophos AV28 Jiangmin AV48 ViRobot AV9 F-Secure AV29 Avast AV49 K7AntiVirus AV10 GData AV30 Baidu-International AV50 Antiy-AVL AV11 Kaspersky AV31 Zoner AV51 nProtect AV12 Comodo AV32 CAT-QuickHeal AV52 ByteHero AV13 Ad-Aware AV33 TrendMicro-HouseCall AV53 CMC AV14 BitDefender AV34 TrendMicro AV54 Malwarebytes AV15 F-Pr+ot AV35 Symantec AV55 SUPERAntiSpyware AV16 MicroWorld-eScan AV36 VBA32 AV56 TheHacker AV17 Emsisoft AV37 Microsoft AV18 NANO-Antivirus AV38 ClamAV AV19 AegisLab AV39 Rising AV20 Qihoo-360 AV40 TotalDefense
Table III.1 : Liste d’Antivirus scanners.
57 Chapitre VI Implémentation
Itération 01 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV21 96 AV40 40,64 AV2 99,6 AV22 95,6 AV41 24,2 AV3 99,4 AV23 95,4 AV42 20,6 AV4 99,4 Notre proposition 94,5 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.2 : Résultat d'itération 01.
Figure III.16 : Taux de détection « Itération 01 ».
58 Chapitre VI Implémentation
Itération 02 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV21 96 AV40 40,64 AV2 99,6 AV22 95,6 AV41 24,2 AV3 99,4 AV23 95,4 AV42 20,6 AV4 99,4 Notre proposition 94,6 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.3 : Résultat d'itération 02.
Figure III.17 : Taux de détection « Itération 02 ».
59 Chapitre VI Implémentation
Itération 03 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV21 96 AV40 40,64 AV2 99,6 Notre proposition 95,8 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.4 : Résultat d'itération 03.+
Figure III.18 : Taux de détection « Itération 03 ».
60 Chapitre VI Implémentation
Itération 04 :
AV Résultat AV Résultat AV Résultat AV1 99,4 Notre proposition 96 AV40 40,64 AV2 99,6 AV21 96 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.5 : Résultat d'itération 04.
Figure III.19 : Taux de détection « Itération 04 ».
61 Chapitre VI Implémentation
Itération 05 :
AV Résultat AV Résultat AV Résultat AV1 99,4 Notre proposition 96,1 AV40 40,64 AV2 99,6 AV21 96 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.6 : Résultat d'itération 05.
Figure III.20 : Taux de détection « Itération 05 ».
62 Chapitre VI Implémentation
Itération 06 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV21 96 AV40 40,64 AV2 99,6 Notre proposition 95,9 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6 Table III.7 : Résultat d'itération 06.
Figure III.21 : Taux de détection « Itération 06 ».
63 Chapitre VI Implémentation
Itération 07 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV21 96 AV40 40,64 AV2 99,6 AV22 95,6 AV41 24,2 AV3 99,4 AV23 95,4 AV42 20,6 AV4 99,4 Notre proposition 94,3 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.8 : Résultat d'itération 07.
Figure III.22 : Taux de détection « Itération 07 ».
64 Chapitre VI Implémentation
Itération 08 :
AV Résultat AV Résultat AV Résultat AV1 99,4 AV20 96,4 AV40 40,64 AV2 99,6 AV21 96 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 Notre proposition 97 AV38 45,2 AV19 96,4 AV39 44,6
Table III.9 : Résultat d'itération 08.
Figure III.23 : Taux de détection « Itération 08 ».
65 Chapitre VI Implémentation
Itération 09 :
AV Résultat AV Résultat AV Résultat AV1 99,4 Notre proposition 96,1 AV40 40,64 AV2 99,6 AV21 96 AV41 24,2 AV3 99,4 AV22 95,6 AV42 20,6 AV4 99,4 AV23 95,4 AV43 12 AV5 99,4 AV24 93,4 AV44 10 AV6 99,2 AV25 93 AV45 7,6 AV7 99,19 AV26 92,6 AV46 5,01 AV8 98,79 AV27 91,6 AV47 3,5 AV9 98,4 AV28 88,6 AV48 3,41 AV10 98,2 AV29 87,4 AV49 2,8 AV11 98,2 AV30 85,8 AV50 2,48 AV12 98 AV31 82,8 AV51 1,4 AV13 97,8 AV32 82,6 AV52 0 AV14 97,8 AV33 81,53 AV53 0 AV15 97,8 AV34 71,54 AV54 0 AV16 97,78 AV35 67,8 AV55 0 AV17 97,77 AV36 50,6 AV56 0 AV18 97,4 AV37 49 AV19 96,4 AV38 45,2 AV20 96,4 AV39 44,6
Table III.10 : Résultat d'itération 09.
Figure III.24 : Taux de détection « Itération 09 ».
66 Chapitre VI Implémentation
Conclusion : Au long de ce chapitre, nous avons vu les outils nécessaires pour la réalisation de notre application. Nous avons cité l’environnement de développement Et finalement la phase d’expérimentation, nous comparons notre proposition également contre 56 scanners anti- virus.
67 Conclusion générale
Conclusion générale
Aujourd'hui, nous avons ainsi vu l’apparition d’un nombre important d’applications malveillantes qui cherchent à espionner les Smartphones. La méthode d’infection principale utilisée par les développeurs de malware est d’ajouter leur code malicieux à des applications existantes puis les proposer sur internet. Dans cette thèse nous avons proposé et évalué une nouvelle méthode afin de caractériser, classifier et détecter les malwares Android. Notre approche est classée parmi les techniques d'analyse statique, tel que en rassemblant le plus nombreux possible les caractéristiques d'une application dans un espace vectoriel. Les malveillants peuvent être donc identifier automatiquement en utilisant une Machine Learning. Cette cadre d'étude a été nommé détecteur basé sur l'apprentissage. Les principales contributions et conclusions de ce travail sont les suivants: Dans cette étude, nous avons utilisé des échantillons de 50500 récente d'applications malveillantes extraites de monde réel. Les algorithmes d'apprentissage de Machine Learning les plus connus sont utilisés et étudiés. Ces algorithme sont le Support Vector Machine (SVM). Le produit final résultant de cette étude est un cadre pour la détection d'application malveillants d'Android qui consiste par : D'une procédure d'extraction de caractéristiques à partir d'applications basées sur l'analyse statique de manifeste d'Android et le code source. Un algorithme d'apprentissage automatique, Support Vector Machine (SVM), qui était configuré et adapté pour être applicable. Ce cadre conduit à 97% de précision, ce qui signifie qu'il est capable de discriminer presque tous les cas de malwares existant dans l'ensemble de données considéré.
68
Bibliographie
Bibliographie
[1]- Adrienne Porter Felt, Helen J.Wang, Alexander Moshchuk, Steven Hanna, and Erika Chin. Permission re-delegation: Attacks and defenses. In Proceedings of the 20th USENIX Conference on Security, SEC’11. USENIX Association, 2011. [2]-André Moulu, Sécurité des applications Android constructeurs et construction de backdoors ciblées, 2013. [3]- B.E. Boser, I.M. Guyon, and V.N. Vapnik. A training algorithm for optimal margin classifiers. In Proceedings of the fifth annual workshop on Computational learning theory, ACM, 1992. [4]-Cédric BERTRAND, Pentest d’une application Android, Novembre 2012 [5]- Cédric BERTRAND. Les malwares sous android, Panorama des malwares sous Android, Analyser une application Android, juin 2012. [6]-Daniel Arp, Michael Spreitzenbarth, Malte Hübner, Hugo Gascon, Konrad Rieck, and CERT Siemens. Drebin : Effective and explainable detection of android malware in your pocket. In NDSS 2014, 2014. [7]- Debin Gao, Michael K. Reiter, and Dawn Song. Gray-box extraction of execution graphs for anomaly detection. In Proceedings of the 11th ACM conference on Computer and communications security, pages 318– 329, 2004. [8]- Erika Chin, Adrienne Porter Fell, Kate Greenwood, and David Wagner. Analyzing inter-application communication in android. In MobiSys’11, 2011. [9]- Liran LERMAN, Les systèmes de détection d'intrusion basés sur du machine learning, [10]- Marcus A. Maloof (2005), _Machine Learning and Data Mining for Computer Security_ , Springer London Ltd, ISBN-10 184628029X ; ISBN-13 978-1846280290. [11]- Marref Nadia, Apprentissage Incrémental & Machines à Vecteurs Supports, Mémoire du diplôme de Magister, 18 /12 /2013. [12]- Paul RASCAGNERES. Malwares Identification, analyse et éradication, avril 2013. [13]- Radoniaina ANDRIATSIMANDEFITRA RATSISAHANANA Caractérisation et détection de malware Android basées sur les flux d'information, 2014. [14]- R-I. Chang & W-D. Su & J-C. Wang & J-S. Kouh (2007), _Intrusion Detection by Backpropagation Neural Networks with Sample-Query and Attribute-Query_, vol. 3, No. 1, pp. 6-10, National Taiwan University, Taiwan.
Bibliographie
[15]- S.Khellat Kihel, « Les séparateurs à vaste marge Bi- classe », Université des sciences et de technologie d‟Oran, exposé de Master2, 2012. [16]- V.N. Vapnik. Statistical Learning Theory. Edition Wiley, 1998. [17]- William Enck, Machigar Ongtang, and Patrick Mcdaniel. Mitigating android software misuse before it happens. Technical report, The Pennsylvania State University, 2008. [18]- Yajin Zhou and Xuxian Jiang. Dissecting android malware: Characterization and evolution. In Proceedings of the 2012 IEEE Symposium on Security and Privacy, SP ’12, pages 95–109, Washington, DC, USA, 2012. IEEE Computer Society. Web graphie
[19]- Androguard, https://code.google.com/p/androguard/, 15/04/2015. [20]- Android Application Sandbox , droidbox, http://code.google.com/p/droidbox/, 28/03/2015. [21]- Android Open Source Project. Device administration. https://developer. android.com /guide/topics/admin/device-admin.html, 15/04/2015. [22]- Android Open Source Project. Intent. http://developer.android.com/reference/ android/content/Intent.html#setFlags%28in t%29, 15/04/2015. [23]- Android Open Source Project. Intent-Filter. http://developer.android.com/reference /android/content/IntentFilter.html, 15/04/2015. [24]- AndroidAuditTools, https://github.com/wuntee/androidAuditTools, 15/04/2015. [25]- APKInspector, https://code.google.com/p/apkinspector/, 28/03/2015. [26]- Dex decompiler, https://code.google.com/p/dex-decomplier/, 15/04/2015. [27]- Dex2jar, https://github.com/pxb1988/dex2jar, 15/04/2015. [28]- dm-crypt.http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree /Documentation/device-mapper/dm-crypt.txt , 28/03/2015. [29]- http://fr.wikipedia.org/wiki/Android, 20/03/2015. [30]- https://redmine.honeynet.org/projects/are, 28/03/2015. [31]- IDA pro version 6.1, https://www.hex-rays.com/products/ida/6.1/index.shtml, 15/04/2015. [32]- JAD, http://varaneckas.com/jad/, 15/04/2015. [33]- Jd-gui, http://java.decompiler.free.fr/?q=jdgui, 15/04/2015. [34]- Mobile Sandbox, http://mobilesandbox.org/, 15/04/2015. [35]- PalmSource.Openbinder.http://www.angryredplanet.com/~hackbod/openbinder/docs/ html/index.htm, 20/03/2015.
Bibliographie
[36]- Smali, An assembler/disassembler for Android's dex format https://code.google.com /p/smali/, 15/04/2015.