Présenté pour d’obtention du diplôme de MASTER ACADEMIQUE · 2015. 6. 10. · A tous mes amies surtout : Karima.D et Siham.L A tous mes collègues de la promotion 2014/2015

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Superieur et de

la Recherche Scientifique

2014/2015

N° d’ordre :

N° de série :

N° d’ordre :

N° de série :

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

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

Système de détection des

malwares sous Android

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 travail

Avec tout mon amour et tendresse.

KARIMA

~ i ~

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,

~ ii ~

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

http://en.wikipedia.org/wiki/Unix-likehttp://en.wikipedia.org/wiki/Operating_system

~ iii ~

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

~ iv ~

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

~ v ~

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

~ vi ~

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.23 : Taux de détection « Itération 05 ». .................................................................. 62





file:///C:/Users/AISSAOUI.Computer/Desktop/Détection%20des%20malwares%20sous%20andoid.docx%23_Toc421634569

~ vii ~

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.10 : Résultat d'itération 08. ........................................................................................ 65

Table III.11 : Résultat d'itération 09. ........................................................................................ 66

1

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.

2

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.

Chapitre I L’état de l’art

Chapitre I Etat de l'art

4

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.

http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation_mobilehttp://fr.wikipedia.org/wiki/Smartphonehttp://fr.wikipedia.org/wiki/Smartwatch


5

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.


6

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


7

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.


8

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.


9

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.


10

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 5 9


11

11 /> 21 22 27 32 33 36 37 40 42 43 44

Figure I.5 : Fichier AndroidManifest.xml d’Angry Birds Space.


12

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.


13

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.


14

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.


15

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.


16

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


17

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


18

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.


19

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


20

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


21

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


22

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].


23

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


24

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

https://sites.google.com/site/io/dalvik-vm-internalshttps://play.google.com/


25

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


26

à 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.


27

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è

Documents

Présenté pour d’obtention du diplôme de MASTER ACADEMIQUE · 2015. 6. 10. · A tous mes amies surtout : Karima.D et Siham.L A tous mes collègues de la promotion 2014/2015