Nicolas KISS Analyse de malware Android - Kharon project

Transcription

Nicolas KISS
Master 2 Informatique
Spécialité : Sécurité des Systèmes d’Information
Année universitaire : 2014 / 2015
CentraleSupélec, Campus de Rennes
Avenue de la Boulaie
CS 47601
F-35576 Cesson-Sévigné CEDEX
Rapport de stage
Analyse de malware Android
Stage effectué du 1er Avril 2015 au 30 Septembre 2015
Sous la responsabilité de :
Valérie VIET TRIEM TONG, [email protected] , CentraleSupélec, Rennes
Jean-Francois LALANDE, [email protected] , INSA Centre Val de Loire, Bourges
Sous le suivi de :
Sandrine BLAZY, [email protected] , Université de Rennes 1, Rennes
Résumé
Les malware Android ne cessent de se multiplier et sont de plus en plus nombreux que ce soit sur
les marchés alternatifs ou sur le Google Play et il est assez difficile de détecter les nouveaux malware
automatiquement. Un projet financé par le LabEx CominLabs a été débuté en janvier 2015 dans le but
de détecter les malware Android en ciblant et exécutant le code suspect des applications. Le but de mon
stage a été d'analyser différents malware Android. L'objectif était de rentrer dans le code d'applications
infectées afin de caractériser un ensemble de malware, comprendre comment ils fonctionnent,
comment ils se déclenchent et comment ils se cachent afin d'apporter des informations pour aider au
ciblage automatique de code malveillant. Parallèlement à ça, j'ai contribué à la rédaction d'un papier
pour un workshop international sur l'élaboration et l'analyse de datasets pour la sécurité. La dernière
partie du stage a été d'alimenter et d'améliorer un site web qui sert de base de connaissances sur
l'étude et le fonctionnement de malware Android.
Mots-clefs : Android, Malware, Java, Bytecode, Décompilation, Flux d'information
Abstract
Android malware are constantly multiplying and are more and more numerous whether on
alternative markets or on the Google Play and it is quite difficult to automatically detect new malware. A
project funded by the LabEx CominLabs was started in January 2015 in order to detect Android malware
by targeting and running suspicious code of applications. The purpose of my internship was to analyze
various Android malware. The objective was to enter into the code of infected applications in order to
characterize a set of malware, to understand how they work, how they are triggered and how they hide
in order to provide information to help for automatic targeting of malicious code. In parallel with that, I
contributed to the writing of a paper for an international workshop about building and analyzing
datasets for security. The last part of the internship was to improve and to add data to a website which
is used as a knowledge base about studies and functioning of Android malware.
Keywords : Android, Malware, Java, Bytecode, Decompilation, Information flow
Nicolas KISS - Rapport de stage M2 SSI
1
Remerciements
Je tiens tout d’abord à remercier mes encadrants de stage Valérie Viet Triem Tong, enseignantchercheur à CentraleSupélec, et Jean-Francois Lalande, enseignant-chercheur à l’INSA Centre Val de
Loire, pour m’avoir fait confiance et m’avoir donné l’opportunité de réaliser ce stage. Merci de m’avoir
consacré du temps, de m’avoir appris de nouvelles choses et d’avoir pris le temps de relire ce rapport.
J’adresse également mes remerciements à Radoniaina Andriatsimandefitra Ratsisahanana,
ingénieur dans l’équipe CIDRE, pour m’avoir aidé lorsque j’ai eu des problèmes techniques, pour m’avoir
donné des informations utiles et pour m’avoir conseillé sur la rédaction de ce rapport.
Je remercie aussi Adrien Abraham, stagiaire dans l’équipe CIDRE, pour avoir partagé ses
connaissances avec moi et avoir été mon collègue de bureau durant ces quelques mois.
Enfin je tiens à remercier toute l’équipe CIDRE pour m’avoir accueilli parmi eux et m’avoir
présenté leurs travaux durant les différents séminaires auxquels j’ai pu assister.
2
Sommaire
1
Introduction ..................................................................................................................................................... 4
2
Organisme d’accueil....................................................................................................................................... 5
3
2.1
CentraleSupélec ........................................................................................................................................ 5
2.2
Équipe CIDRE ............................................................................................................................................ 5
Contexte .......................................................................................................................................................... 6
3.1
3.1.1
Machine virtuelle Dalvik ................................................................................................................... 6
3.1.2
Applications Android ........................................................................................................................ 6
3.1.3
Sécurité Android ............................................................................................................................... 8
3.2
4
5
6
7
Android ...................................................................................................................................................... 6
Malware Android ....................................................................................................................................... 8
3.2.1
Réflexion ............................................................................................................................................ 9
3.2.2
Code natif .......................................................................................................................................... 9
3.2.3
Renommage ...................................................................................................................................... 9
3.2.4
Cryptographie ................................................................................................................................. 10
3.2.5
Vulnérabilités .................................................................................................................................. 10
3.3
Projet Kharon .......................................................................................................................................... 10
3.4
Sujet de stage .......................................................................................................................................... 11
Environnement de travail ........................................................................................................................... 12
4.1
Blare ......................................................................................................................................................... 12
4.2
BytecodeViewer ...................................................................................................................................... 12
4.3
ApkTool.................................................................................................................................................... 13
4.4
Droidbox .................................................................................................................................................. 13
4.5
Androguard ............................................................................................................................................. 13
4.6
Android Debug Bridge ............................................................................................................................ 13
Travail effectué ............................................................................................................................................. 14
5.1
Analyse statique ...................................................................................................................................... 14
5.2
Analyse dynamique................................................................................................................................. 21
Résultats ........................................................................................................................................................ 25
6.1
Article....................................................................................................................................................... 25
6.2
Site web ................................................................................................................................................... 26
Conclusion ..................................................................................................................................................... 28
Annexe 1 ................................................................................................................................................................. 29
Annexe 2 ................................................................................................................................................................. 30
3
1
Introduction
Étudiant en Master 2 Sécurité des Systèmes d'Information à l'ISTIC, j'ai effectué mon stage de fin
d'études au sein de CentraleSupélec (campus de Rennes), dans l'équipe de recherche CIDRE. Le stage
s'est déroulé du 1er avril au 30 septembre 2015.
Le sujet de mon stage portait sur l'analyse de malware Android. J'ai été encadré durant toute la durée
par Valérie Viet Triem Tong et Jean-François Lalande. Dans le but d'expliquer au mieux le travail réalisé,
le rapport est structuré comme ceci.
Premièrement, je vais commencer par présenter dans la section 2 l'école CentraleSupélec ainsi que
l'équipe CIDRE. J’exposerais en particulier les thématiques de recherche de l'équipe afin de mettre en
évidence les raisons qui m'ont poussé à les rejoindre pour travailler avec eux.
Dans la section 3, je présenterais le contexte du stage et je décrirais en détails le sujet. Pour commencer
je ferais une présentation du système Android et des différents types de malware existants, puis
j'expliquerais plus précisément dans quel projet se situe mon travail, pourquoi a-t-on besoin de moi,
quelles sont les difficultés et quels sont les objectifs du travail demandé.
La section 4 présentera les différents outils et logiciels que j'ai utilisé lors du stage. Cela permettra
d'introduire l'environnement technologique dans lequel j'ai évolué et d'aider à mieux comprendre le
déroulement des analyses décrites dans la section suivante.
Je décrirai ensuite dans la section 5 les analyses faites sur chaque malware. Le but est de décrire pas à
pas la méthodologie générale employée et de transposer cela sur un exemple concret de malware que
j'ai pu analyser.
La section 6 présentera les résultats obtenus et les contributions apportées par mon travail. Cette partie
se focalisera principalement sur la rédaction d’un papier qui sera soumis au mois de septembre pour le
workshop BADGERS 2015 et sur l'amélioration d’un site web présentant des malware Android.
Pour finir ce rapport, la dernière section sera consacrée à la conclusion dans laquelle je ferais un bilan
humain et technique de ce que j'ai vécu et appris durant ce stage. Enfin j’exposerais les poursuites
possibles de mon travail.
4
2
Organisme d’accueil
2.1 CentraleSupélec
CentraleSupélec est une école d’ingénieurs
publique, créée en 2015. Elle est née de la fusion entre
l'école Centrale Paris et Supélec dans le but de devenir
l’une des institutions de référence à l’échelle mondiale1.
L’école est composée de quatre campus : ChâtenayMalabry, Gif-sur-Yvette, Metz, Rennes.
Elle est l'une des 210 écoles d'ingénieurs françaises habilitées à délivrer un diplôme d'ingénieur. En plus
des diplômes d’ingénieur, CentraleSupélec délivre des diplômes de Master, des diplômes de docteur et
des Mastères Spécialisés 2. L’école est très impliquée dans le domaine de la recherche, son centre de
recherche est composé de 15 laboratoires répartis sur ses quatre campus. Les domaines d'activités des
laboratoires sont nombreux : informatique, physique, télécommunications, énergie, électronique…
CentraleSupélec va devenir l’institution qui va le plus publier dans le domaine des sciences de
l’ingénieur en France, avec plus de 500 publications par an 1.
2.2 Équipe CIDRE
L’équipe CIDRE (Confidentialité, Intégrité, Disponibilité, REpartition) est une équipe de recherche
membre de l’UMR IRISA, elle est commune entre Inria, CentraleSupélec, l’université de Rennes 1 et le
CNRS. L’équipe travaille dans le domaine la sécurité des systèmes d’information, plus précisément elle
focalise ses recherches sur 3 axes principaux.
 Gestion automatique de la confiance
Proposer des mécanismes qui permettent à des machines d’évaluer la confiance qu’elles peuvent
mettre dans les entités avec lesquelles elles sont emmenées à interagir.
 Détection d’intrusions / Supervision de la sécurité
Proposer des nouvelles méthodes qui permettent d’identifier des comportements suspects ou des
attaques sur un système d’information, produire des alertes et corréler les alertes.
 Protection de la vie privée
Proposer des mécanismes qui permettent d’assurer la protection de la vie privée des utilisateurs.
Par ailleurs, plusieurs membres de l’équipe ont donné des cours et encadré des TP à l’ISTIC lors de notre
formation.
Page web de CIDRE : http://www.rennes.supelec.fr/ren/rd/cidre/
1
2
http://www.lesechos.fr/05/09/2013/lesechos.fr/0202988177257_fusion-centrale-supelec----nous-allons-rivaliser-avec...
http://www.cge.asso.fr/nos-labels/ms
5
3
Contexte
3.1 Android
Android est un système d'exploitation mobile open source, utilisant un noyau Linux modifié. Le
système a été racheté par Google en 2005. Il est utilisé principalement par des smartphones et
tablettes, mais est aussi utilisé par des smartwatches, PDA et même des téléviseurs. En 2015, Android
représenterait 78% du marché des smartphones3.
3.1.1 Machine virtuelle Dalvik
Android possède une machine virtuelle nommée Dalvik. Cette machine Dalvik permet d'exécuter
du code Java tout comme le ferait la traditionnelle Java Virtual Machine (JVM). La différence avec la JVM
est que la machine Dalvik est conçue spécialement pour les terminaux mobiles, c'est à dire des
terminaux avec des ressources limitées, possédant moins de puissance de calcul, moins de mémoire et
dont la consommation électrique doit être réduite au maximum. La machine Dalvik fonctionne avec un
système de registres alors que la JVM fonctionne avec une pile. Par conséquent, les instructions Dalvik
sont différentes et le bytecode Dalvik est donc différent du bytecode Java classique.
Figure 1 : Processus de compilation d’une application Android (http://www.cse.psu.edu/~duo114/research.html)
3.1.2 Applications Android
Les applications Android sont donc écrites en Java et sont empaquetées dans des fichiers Android
Package (APK). Ces paquets contiennent entre autre une description de l'application, les ressources et
tout le code exécutable contenu dans un seul et unique fichier au format Dalvik Executable (DEX).
3
http://www.zdnet.fr/actualites/chiffres-cles-les-os-pour-smartphones-39790245.htm
6
3
Contexte
Afin de mieux comprendre comment les applications Android fonctionnement, et donc les malware, cidessous une description des éléments importants à connaître d'une application Android.
 Manifest : Fichier XML servant de description de l'application. On y déclare entre autres les
permissions et les différents composants comme les activités, les services, les
BroadcastReceivers.
 Permissions : Ce sont les permissions utilisées par l'application. Cela permet de définir ce que
l'application a le droit de faire ou non, par exemple lire les SMS, utiliser internet, etc.
 Activités : Une activité (ou Activity en anglais) est une interface utilisateur, typiquement une
fenêtre comportant des boutons ou des champs. Une application a en général plusieurs activités.
 Services : Un service est un composant effectuant des tâches en arrière-plan, invisible à
l'utilisateur et ne bloquant pas l'application.
 BroadcastReceivers : Un BroadcastReceiver est un composant dont le but est de réagir à la
réception d'intents diffusés dans le système.
 Intents : Un intent est un message servant à faire communiquer activités, services et même
applications entre elles. Le but d'un intent est en général de déléguer une action à un autre
composant. Un intent peut être à destination spécifique d'une activité ou d'un service, mais peut
aussi être broadcasté dans le système et être récupéré par des BroadcastReceivers.
Il est important de noter que contrairement à un programme Java classique, une application Android
n'a pas de Main et possède plusieurs points d'entrée (Activités, Services, BroadcastReceivers). De plus,
une application Android à un cycle de vie bien particulier comme le montre l'image ci-dessous.
Figure 2 : Cycle de vie d’une activité Android
(https://mobiledevnews.wordpress.com/2014/11/05/android-managing-the-activity-lifecycle/)
7
3
Contexte
3.1.3 Sécurité Android
Android est basé sur un noyau Linux et de ce fait, il hérite de mécanismes de sécurité provenant
de Linux. Premièrement Android supporte la présence de plusieurs utilisateurs, en effet chaque
application est considérée comme un utilisateur différent (par défaut). De plus les applications sont
cloisonnées entre elles, c'est à dire que chaque application tourne dans un processus différent, que
chaque application à son propre répertoire (dans /data/data/) avec ses ressources et ses données. Le
contrôle d'accès est comme sur Linux, à savoir qu'il y a des droits d'accès en lecture, écriture et
exécution pour 3 entités : le propriétaire, le groupe, et les autres.
Les permissions que l'on a évoquées dans la partie précédente sont aussi un mécanisme de
sécurité qui lui est propre à Android. Comme expliqué précédemment, si une application doit par
exemple lire les SMS, elle doit avoir la permission android.permission.READ_SMS. Au moment de
l'installation d'une nouvelle application, l'ensemble des permissions nécessaires est montré à
l'utilisateur et il doit les valider avant installation. En pratique ce système n'est pas parfait, beaucoup
d'applications demandent plus de permissions que nécessaire et une bonne partie des utilisateurs
acceptent les permissions sans les comprendre ou même les lire.
3.2 Malware Android
Malware est le terme anglais pour désigner tout type de logiciel malveillant. En 2014, environ
9 % des applications Android seraient ou contiendraient des malware4. Selon l'éditeur d'antivirus
Dr.Web, depuis 2010 le nombre de signatures de malware Android a été multiplié par 189 et Android
serait l'OS le plus ciblé après Windows5.
Les malware Android peuvent avoir différents objectifs et n'ont pas tous la même finalité. Ci-dessous
une liste d'actions malveillantes que peuvent faire ces malware.
- Vols d'informations confidentielles et/ou bancaires
- Souscription à des services payants
- Demande de rançon
- Blocage du téléphone
- Publicités intempestives
- Installation d'applications indésirables
- Minage de monnaies virtuelles6
- Infection d'un PC Windows7
- Prise de contrôle et exécution de commandes à distance
4
https://www.cmcm.com/blog/2014-07-18/186.html
http://antifraud.drweb.fr/android_theft
6
https://www.lookout.com/resources/top-threats/coinkrypt
7
https://blog.gdatasoftware.com/blog/article/android-malware-infects-windows-pcs-with-spy-bot.html
5
8
3
Contexte
Évidemment les malware peuvent effectuer plusieurs de ces actions malveillantes à la fois, ils ne sont
pas limités à un seul type. Ils deviennent aussi de plus en plus sophistiqués avec le temps, et il est
possible qu'ils utilisent différentes techniques d'obfuscation pour échapper aux analyses statiques
automatiques et rendre difficile les analyses manuelles faites par décompilation. Voici une brève
présentation de ces techniques.
3.2.1 Réflexion
Java fournit dans son API la possibilité de faire ce que l'on appelle de la réflexion. Le but de la
réflexion est de charger dynamiquement une classe et d'utiliser ses méthodes ou modifier ses attributs,
sans connaître à l'avance la classe et ses méthodes. La figure ci-dessous illustre un exemple très simple
d’utilisation de réflexion.
Figure 3 : Exemple de réflexion en Java
Bien évidemment, les chaînes utilisées sont statiques pour la compréhension de l'exemple. Mais il est
très facile d'imaginer que ces chaînes peuvent être des variables dont le contenu est changé
dynamiquement par le malware.
3.2.2 Code natif
Android fournit une collection d'outils appelée Native Development Kit (NDK). Le NDK permet de
coder une ou plusieurs parties d'une application en code natif avec typiquement C/C++. Le code sera
compilé et ensuite exporté dans une librairie externe (fichier .so). Le code de la librairie pourra être
utilisé dans l'application Android en utilisant la Java Native Interface (JNI). Certains malware utilisent du
code natif dans le but de cacher le code malveillant. En effet le code des fichiers .so n'est pas décompilé
par les outils de décompilation de bytecode.
3.2.3 Renommage
Il existe des outils gratuits comme ProGuard8 ou RetroGuard9 qui permettent (entre autre) de
faire du renommage. Le renommage consiste à changer le nom des packages, classes, méthodes et
variables par des chaînes de caractères, le plus souvent incompréhensibles. De cette façon le bytecode
décompilé sera très difficile à comprendre même si la sémantique du code est identique à l'original.
8
9
http://proguard.sourceforge.net/
http://www.retrologic.com/retroguard-faq.html
9
3
Contexte
3.2.4 Cryptographie
Il n'est pas rare que des malware aient recours à la cryptographie pour se dissimuler. Le
chiffrement peut se faire sur plusieurs éléments, par exemple sur des chaînes de caractères sensibles
(adresse de serveur distant, nom de classe ou méthode pour la réflexion). Il est aussi possible
d'effectuer le chiffrement d'un fichier exécutable contenant un exploit pour ne pas qu'il soit reconnu par
son empreinte, ou encore de chiffrer toutes les communications entre le smartphone et un serveur
distant.
3.2.5 Vulnérabilités
Certains malware exploitent des vulnérabilités du système Android pour obtenir un accès root.
Cela sert par exemple à perdurer dans le téléphone, même après désinstallation de l'application
infectée en installant des packages dans la partition system. Nous pouvons par exemple citer les
exploits Exploid 10 et Rage Against The Cage 11 qui sont utilisés par un malware que j'ai analysé :
DroidKungFu1.
3.3 Projet Kharon
Kharon est un projet qui a débuté en janvier 2015, il est financé par le Laboratoire d'Excellence
(LabEx) CominLabs. Le but final de ce projet est de proposer une plate-forme en ligne où les utilisateurs
pourront déposer des applications Android et savoir de façon totalement automatisé si l'application est
malveillante. La méthode ici n'est pas de comparer l'empreinte du fichier avec une base de signatures
mais d'observer le comportement dynamique de l'application et d'en déduire automatiquement si elle
est dangereuse. Le processus de détection se fait en 2 parties.
La première partie consiste à faire une analyse statique de l'application et à repérer les zones de code
potentiellement malveillantes. L'objectif est de forcer l'exécution du code suspect en instrumentant le
code.
La deuxième partie consiste à comparer le résultat de l'exécution forcée avec le comportement d'autres
malware. Pour cela, on utilise une structure de données nommée System Flow Graph (SFG) qui contient
tous les flux d’information au niveau système qui ont eu lieu pendant l’exécution, comme par exemple
les flux entre processus et fichiers ou encore sockets. Le SFG d'un malware est utilisé comme signature
comportementale. On peut ensuite observer si la signature comportementale d'un malware est
présente dans le SFG d'une application et donc être capable de dire si l'application est malveillante.
Le projet regroupe des membres de l'équipe CIDRE et de l'équipe Celtique 12 de l'IRISA.
Lien : http://www.kharon.cominlabs.ueb.eu/fr
10
https://thesnkchrmr.wordpress.com/2011/03/27/udev-exploit-exploid/
http://www.quora.com/What-are-the-exact-mechanisms-flaws-exploited-by-the-rage-against-the-cage...
12
https://www.irisa.fr/celtique/
11
10
3
Contexte
3.4 Sujet de stage
Il est important de préciser que la plupart des malware ne se déclenchent pas automatiquement
après installation de l'application. Le code malveillant ne se déclenche que sous certaines conditions.
Par exemple l'attente d'une période de temps, l'attente d'un message d'un serveur distant, l'attente
d'un Intent particulier, l'attente du redémarrage du téléphone, etc. C'est une des difficultés du
processus de détection du projet Kharon, à savoir cibler le code malveillant et trouver sous quelles
conditions il se déclenche.
Le but du stage était de prendre un ensemble de malware, et pour chacun d'eux, analyser le code,
localiser le code malveillant, comprendre ce qu'il fait, comprendre comment il se déclenche et identifier
les techniques d'obfuscation utilisées pour se cacher.
L'objectif était double. Premièrement mon travail allait aider au ciblage automatique de code
malveillant du projet Kharon en apportant des informations techniques et précises sur des malware
dont on connaîtra le comportement exact. Le deuxième objectif était de participer à l'élaboration d'un
dataset présentant des analyses détaillées et précises de plusieurs malware afin que n'importe qui
intéressé par le sujet (chercheur, étudiant, ingénieur) puisse trouver sur un site web des informations
utiles et pertinentes sur le fonctionnement des malware Android.
C'est un travail qui demande du temps. Il n'est pas toujours facile d'arriver dans le code d'une
application dont on ne connaît rien et dont le code n'est pas commenté. Il faut comprendre
l'architecture de l'application, repérer tous les points d'entrée possibles, couvrir tous les branchements
possibles. Beaucoup de malware sont repackagés dans des vraies applications, il faut alors faire
attention à ne pas confondre le code bénin et le code malveillant. En plus de ça, il faut aussi parfois faire
face à de l'obfuscation, ce qui complique encore plus la tâche.
11
4
Environnement de travail
4.1 Blare
Blare est un système de détection d'intrusions créé et développé par l'équipe CIDRE. Sa
particularité est qu'il utilise une politique de flux d'information, cette politique décrit les flux
d'information autorisés dans le système. Pour expliquer le fonctionnement simplement, il faut faire la
distinction entre un contenu (l'information) et un conteneur d'information. Blare utilise un système de
marquage afin de définir quel contenu a le droit de se retrouver dans quel conteneur, et quel conteneur
a le droit de contenir tel contenu.
Blare est un moniteur de flux d'information, il suit les flux d’information au niveau du système
d’exploitation et lève une alerte lorsque la politique n'est pas respectée. L'ensemble des flux observés
peut être visualisé sous la forme d'un graphe qu'on appelle System Flow Graph (SFG). Le SFG d'une
application décrit le comportement de l'application d'un point de vue système, c'est à dire qu'on peut
voir les fichiers utilisés, les sockets utilisés, les processus créés, etc. C'est très utile pour caractériser une
application et obtenir une signature comportementale.
Il y a actuellement 3 implémentations de Blare.
- KBlare pour Linux
- JBlare pour les programmes Java
- AndroBlare pour Android
C'est bien sûr AndroBlare que j'ai utilisé durant mon stage.
Lien : https://www.blare-ids.org/
4.2 BytecodeViewer
BytecodeViewer est un outil qui permet de décompiler des programmes Java. Il embarque 5
décompilateurs Java différents : Procyon, FernFlower, CFR, Krakatau et le décompilateur JD-GUI. Il
fonctionne aussi bien avec des programmes Java classique qu'avec des applications Android.
Grâce à son interface graphique, il offre une navigation facile dans le code source. Il permet pour une
même application d'afficher en même temps le bytecode, le code Java (en 5 versions) et le code Smali
(du code DEX désassemblé).
Il permet de modifier le code Java et de le sauvegarder dans un nouveau fichier Jar ou DEX, mais c'est
une chose à éviter, car le code Java généré par les décompilateurs n'est presque jamais recompilable ou
exécutable.
Lien : http://bytecodeviewer.com/
12
4
Environnement de travail
4.3 ApkTool
ApkTool est un outil qui permet de décompiler et recompiler des fichiers APK. C'est outil est
intéressant car il permet de récupérer le fichier Manifest.xml dans un format lisible, ce qui n'est pas le
cas avec BytecodeViewer. Il permet aussi d'obtenir les fichiers ressources (images, xml, etc) et la totalité
du code de l'application dans des fichiers Smali, ce qui permet d'ajouter des modifications au code
facilement, puis de reconstruire un nouveau fichier APK à partir du code Smali modifié.
Lien : http://ibotpeaches.github.io/Apktool/
4.4 Droidbox
DroidBox est un outil permettant l’analyse dynamique d’applications Android dans un émulateur.
Durant l’exécution de l’application, l’outil enregistre les communications réseaux effectuées par
l’application, les accès aux fichiers, les services lancés, les classes chargées, les opérations
cryptographiques via l’API Android, les SMS et les appels émis. On peut donc observer le contenu des
requêtes envoyées aux serveurs, le nom des fichiers accédés, le contenu des SMS envoyés, etc.
Mais l'outil est assez limité, il se contente de lancer l’application en exécutant son activité principal
(celle associée au launcher), ne cherchant aucun autre point d'entrée. C'est ensuite à l'utilisateur
d'utiliser l'application dans l'émulateur, ce qui n'est pas toujours pratique.
Lien : https://code.google.com/p/droidbox/
4.5 Androguard
Androguard est une collection d'outils en Python dédiée à l'analyse des applications Android. Il
permet de décompiler les applications et de décoder le manifest binaire mais ne s'arrête pas là.
Androguard peut par exemple faire une analyse statique des applications, le résultat va afficher les
permissions dangereuses, les endroits dans le code où sont utilisées les permissions, si l'application
utilise de la cryptographie, du code natif, de la réflexion, etc. Un des outils permet de calculer la
similarité entre 2 applications, ce qui est utile pour repérer si un malware a été repackagé dans une
application. Un autre outil va lui générer le graphe de flot de contrôle pour chaque méthode de
l'application. C'est une collection assez riche et il serait trop long de décrire tout ce qui est faisable.
Lien : https://code.google.com/p/androguard/
4.6 Android Debug Bridge
Android Debug Bridge (ADB) est un outil en ligne de commandes fournit dans le SDK Android. Il
permet d'ouvrir un shell pour communiquer avec le smartphone depuis l'ordinateur. Les commandes
permettent entre autre d'installer des APK, de copier des fichiers du PC au smartphone (push), du
smartphone au PC (pull), de créer/supprimer des dossiers, etc. Il est notamment indispensable pour
utiliser Androblare et marquer les applications à surveiller.
13
5
Travail effectué
Cette partie va présenter la majorité du travail que j'ai effectué durant mon stage, c'est à dire
analyser des malware Android. Il faut savoir qu'à mon arrivé, je n'avais jamais fait de développement
Android. J'ai donc passé le début du stage à apprendre Android et à lire un rapport d’anciens étudiants
qui ont analysé eux aussi des malware Android.
J'ai analysé plusieurs malware dont je parlerais plus en détails dans la partie concernant les résultats.
Dans cette partie je vais présenter la méthodologie employée sur un malware que je trouve plutôt
intéressant datant de 2014 nommé Simplocker (ou SimpleLocker) qui est un ransomware, c'est à dire
qu'il bloque l’accès aux fichiers du téléphone et demande une rançon à la victime.
La méthodologie va être séparée en deux, je vais d'abord présenter l'analyse statique qui ne demande
pas d’exécution et qui est la plus grosse partie du travail que j'ai fait, puis l'analyse dynamique qui elle se
base sur plusieurs exécutions du malware et qui apporte des détails supplémentaires sur le
comportement du malware.
5.1 Analyse statique
La première chose à faire est de déposer l'échantillon (ou sample) sur la plate-forme en ligne
VirusTotal13. Le but principal de VirusTotal est d'indiquer si un fichier ou une URL est malveillante en
utilisant la base virale de plusieurs antivirus (55 actuellement). En soumettant le sample de Simplocker
sur la plate-forme, on obtient le résultat suivant.
Figure 4 : Résultat de VirusTotal sur l’échantillon de Simplocker
On a donc confirmation que ce fichier APK contient un malware. Toutefois, si jamais VirusTotal donne un
taux de détection faible, ou même de 0 sur 55, cela ne veut pas forcément dire que l'application n'est
pas malveillante, cela veut juste dire qu'elle n'est pas (encore) connue des antivirus.
13
https://www.virustotal.com/
14
5
Travail effectué
J'utilise ensuite ApkTool pour extraire le manifest et l'étudier. Il suffit de taper la commande :
apktool d <malware-sample>.apk
On obtient alors un dossier contenant : les librairies (fichiers .so), le code Smali de l’application, le
manifest et toutes les ressources (fichiers .xml, .png, .mp3). Le manifest complet est disponible en
annexe 1.
En observant le manifest, on obtient les informations suivantes :

Le package principal de l'application est org.simplelocker

L'activité lancée par le launcher est Main. C'est d'ailleurs la seule activité de l'application.

L'application possède 2 services.

Le premier service s'appelle MainService.

Le deuxième service s'appelle TorService et se trouve dans un package Java14 différent
org.torproject.android.service. Ce service peut être démarré par l'intent
org.torproject.android.service.ItorService et l'intent
org.torproject.android.service.TOR_SERVICE.

L'application possède 2 BroadcastReceiver.

Le premier receiver s'appelle ServiceStarter et est déclenché par l'intent BOOT_COMPLETED.

Le deuxième receiver s'appelle SDCardServiceStarter et est déclenché par l'intent
ACTION_EXTERNAL_APPLICATIONS_AVAILABLE
Pour résumé, nous avons obtenu 3 informations importantes :
 L'application ne possède qu'une seule et unique activité, ce qui est peu commun.
 L'application effectue quelque chose à chaque redémarrage du téléphone ( BOOT_COMPLETED).
 L'application utilise un package Java externe org.torproject 15, qui est en réalité un package
fournit dans Orbot, la version Android de Tor 16.
Pour information, Tor est un réseau informatique décentralisé dont le
but premier est de préserver l'anonymat des utilisateurs. Pour faire
simple, chaque connexion utilise un circuit composé de plusieurs
nœuds (dans des pays différents), et les données sont chiffrées
asymétriquement avec la clé publique de chaque nœud du circuit, ce
qui implique plusieurs couches de chiffrement. Chaque nœud déchiffre
ensuite sa couche de chiffrement avec sa clé privée, et relaie le paquet
au nœud suivant jusqu’à arriver au nœud final.
Plus d'informations : http://open-freax.fr/reseau-tor-principe-fonctionnement/
14
Un package Java est un « dossier » regroupant plusieurs classes Java
https://gitweb.torproject.org/orbot.git/tree/src/org/torproject
16
https://www.torproject.org/docs/android.html.en
15
15
5
Travail effectué
Maintenant que nous avons ces informations, retournons sur VirusTotal. Il y a une partie « File
detail » dans laquelle se trouvent les résultats d'une analyse statique de l'application. Il faut savoir que
VirusTotal utilise Androguard, et que les informations que l'on va voir dans cette partie peuvent tout
aussi bien être récupérés avec l'un des outils d'Androguard en tapant la commande
python androguard/androapkinfo.py -i <malware-sample>.apk
Je vais utiliser VirusTotal car l'interface est plus claire et « user-friendly » qu'avec Androguard. La
première chose que l'on peut voir sur la page « File detail » est le résumé de l'analyse statique. Voici ce
qui est affiché.
Figure 5 : Section « Risk Summary » de VirusTotal
J'ai encadré en rouge les éléments intéressants.
- « The studied DEX file makes use of API reflection »
→ Le code contient de la réflexion.
- « The studied DEX file makes use of cryptographic functions »
→ Le code fait appel à des fonctions cryptographiques.
- « The APK package studied contains ELF executable files »
→ L'application contient des librairies externes.
Il est important de préciser que l'analyse est faite sur la totalité du code de l'application. Il faut donc
prendre ces informations avec précaution car il n'est pas rare que l'utilisation de réflexion ou de code
natif fasse partie de code bénin provenant d'une application ou d'un package inoffensif.
La deuxième section qui est affichée concerne les permissions utilisées par l'application.
Figure 6 : Section « Required permissions » de VirusTotal
16
5
Travail effectué
VirusTotal affiche en rouge les permissions dangereuses. On voit que l'application possède les
permissions pour avoir accès librement à Internet, avoir accès la carte SD (lecture et écriture), démarrer
automatiquement à chaque redémarrage du téléphone.
La section suivante nommée « Permission-related API calls » nous montre à quels endroits du code sont
utilisées les permissions. Le code n'est pas affiché directement, il est simplement indiqué que telle
fonction de telle classe fait appel à telle permission. Je ne vais pas montrer de screenshot car cette
section est assez longue, mais il faut savoir que ça peut aider à donner une piste pour trouver le (ou les)
package(s) suspect(s). Dans notre cas, cette partie n'apporte pas grand-chose car nous avons déjà une
bonne idée du package dans lequel regarder, à savoir org.simplelocker.
Une autre section affiche tous les fichiers contenus dans l'archive (le fichier APK). Cette section
n'apporte pas beaucoup d'informations intéressantes car on obtient la même chose avec ApkTool, mais
on peut par exemple observer les différentes librairies embarquées dans l'application.
Figure 7 : Libraries embarquées dans l’application
On peut repérer les mots « tor », « proxy » et « privoxy ». Il est donc fort possible que ces librairies aient
quelque-chose à voir avec Orbot que nous avons vu précédemment.
Enfin la dernière section qui donne des informations utiles nous montre les chaînes de caractères
intéressantes dans le code.
Figure 8 : Section « Interesting strings » de VirusTotal
On peut voir une URL en .onion, qui est le type d'URL utilisé dans le réseau Tor.
En résumé de cette partie, nous savons que l'application peut avoir accès librement à Internet, qu'elle
utilise sûrement le réseau Tor, qu'elle peut modifier le contenu de la carte SD du téléphone, qu'elle
utilise des fonctions cryptographiques et qu'elle est capable d'exécuter quelque-chose à chaque
redémarrage du téléphone.
Maintenant que nous avons toutes ces informations, nous allons passer à l'inspection du code
afin de comprendre précisément ce que l'application fait et comment. Pour cela on va utiliser
BytecodeViewer et ouvrir l'échantillon avec.
17
5
Travail effectué
Commençons par regarder l’activité qui est démarrée lorsqu'on lance l'application. Pour rappel, il s'agit
de org.simplelocker.Main.
Figure 9 : Extrait de code de l’activité org.simplocker.Main
On voit que la fonction onCreate() lance une procédure startService() qui démarre le service
org.simplelocker.MainService. Regardons donc de plus près ce service.
Figure 10 : Extrait de code du service org.simplelocker.MainService
On observe premièrement que le service acquiert un « WakeLock », ça sert à ce que l'application tourne
toujours, même si l'écran du téléphone est éteint 17. Ensuite, on voit que le service ordonnance 2 tâches
répétitives à intervalle fixe. La première est l'exécution de org.simplelocker.MainService$3 toutes
les 3 minutes, la deuxième est l'exécution de org.simplelocker.MainService$4 toutes les secondes.
Enfin pour finir, le service démarre un thread org.simplelocker.MainService$5.
Je ne vais pas montrer le code de MainService$3 car il fait presque une vingtaine de lignes, mais son
rôle est de lancer (ou relancer dans certains cas) le service TOR_SERVICE du package
org.torproject.android.service. Si le service est déjà lancé, la tâche fait appel à la fonction
org.simplelocker.TorSender.sendCheck(). Voici à quoi ressemble cette fonction.
Figure 11 : Extrait de code de la fonction org.simplocker.TorSender.sendCheck( )
On peut voir que l'application envoie l'IMEI du téléphone. Pour information, l'IMEI (International Mobile
Equipment Identity) est un numéro qui permet d'identifier de façon unique n'importe quel terminal
mobile. Quant à la classe HttpSender, c'est une classe qui s'occupe d'envoyer des requêtes sur le port
9050 en utilisant un proxy SOCKS, c'est donc pour envoyer des messages sur le réseau Tor 18.
17
18
https://developer.android.com/training/scheduling/wakelock.html#cpu
https://wiki.archlinux.org/index.php/Tor#Configure_Tor
18
5
Travail effectué
Figure 12 : Extrait de code de la classe HttpSender
Le rôle de MainService$4 est de lancer l'activité Main si la variable DISABLE_LOCKER est à false et que
l'activité Main n'est plus en cours d'exécution. On peut donc en déduire que c'est la variable
DISABLE_LOCKER qui indique au malware si il doit afficher à l'écran de façon continu (toutes les
secondes) l'activité Main.
Figure 13 : Extrait de code de MainService$4
Le thread MainService$5 a lui seulement pour but de lancer l'exécution de la fonction
org.simplelocker.FilesEncryptor.encrypt( ). En regardant de plus près cette fonction, on voit
qu'elle applique une fonction AesCrypt.encrypt( ) sur un ensemble de chaînes de caractères
désignant des fichiers. On peut remarquer que le malware fait un File.delete( ) sur chacun des
fichiers après le chiffrement.
Figure 14 : Extrait de code de MainService$5
Si on regarde le code de la classe org.simplelocker.AesCrypt, on voit que la méthode de chiffrement
utilisé est AES en mode CBC19 avec un padding PKCS#7.
Figure 15 : Extrait de code de la classe org.simplelocker.AesCrypt
19
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29
19
5
Travail effectué
L'ensemble contenant la liste des fichiers à chiffrer est construit en scannant la totalité de
Environment.getExternalStorageDirectory( ) qui est en fait le chemin de la racine de la carte SD.
On observe que le malware recherche des fichiers d'extensions précises contenus dans
Constants.EXTENSIONS_TO_ENCRYPT . En regardant la classe org.simplelocker.Constants, on peut
trouver plusieurs informations intéressantes.
Figure 16 : Extrait de code de la classe org.simplelocker.Constants
On voit que le malware ne cherche qu'à chiffrer que les fichiers multimédia. On retrouve aussi l'url en
.onion qui se nomme ADMIN_URL, on devine que c'est l'adresse du serveur maître qui est contacté pour
savoir si la victime a payé la rançon. On peut remarquer que le mot de passe de chiffrement est
constant, ce qui implique qu'il est très facile de déchiffrer les données. Enfin on voit des chaînes de
caractères concernant différents services de paiement, MoneyPack, PaySafeCard, Ukash.
Pour terminer, nous avions parlé lors de l'étude du manifest d'un BroadcastReceiver nommé
ServiceStarter et déclenché par l'intent BOOT_COMPLETED. Son seul but est de lancer le service
org.simplocker.MainService à chaque redémarrage de l'appareil.
Figure 17 : Extrait de code du BroadcastReceiver org.simplelocker.ServiceStarter
En résumé de cette analyse, nous avons pu comprendre plus précisément ce que fait le malware. Il est
déclenché automatiquement au lancement de l’application ou à chaque redémarrage du téléphone.
Quand le malware est déclenché, il bloque l’écran du téléphone en affichant une activité en continue et
il se connecte au réseau Tor pour contacter son serveur maitre. La première fois que le malware se
déclenche, il chiffre tous les fichiers multimédia de la carte SD, des nouveaux fichiers d’extension .enc
sont créés et les fichiers originaux sont effacés. Le mot de passe de chiffrement est constant.
Remarques :
Le malware est capable de chiffrer les données de la carte SD simplement car l'application possède les
permissions READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE. Le malware peut se connecter à
Tor quand il veut car l'application possède la permission INTERNET. Il arrive à être actif sans interruption
grâce à l’acquisition d'un WakeLock (permission WAKE_LOCK) et de son démarrage à chaque reboot du
téléphone (permission RECEIVER_BOOT_COMPLETED).
On peut donc voir que les permissions accordées (et acceptées par l'utilisateur) y sont pour beaucoup
dans ce que malware a le droit de faire. De plus, le malware est capable de bloquer l'écran du téléphone
de façon tout à fait légale dans le système simplement grâce au lancement d'une activité toutes les
secondes.
20
5
Travail effectué
La connexion au réseau Tor est un « bonus » qui permet de préserver l'anonymat du demandeur de
rançon. Le malware aurait sûrement fonctionné (pendant un certain temps) avec un serveur accessible
sur le web classique.
Nous n'avons pas croisé de réflexion dans le vrai code malveillant. La réflexion ici est utilisée dans des packages
qui
sont
bénins
en
théorie.
Comme
par
exemple
org.spongycastle20
ou
21
info.guardianproject.onionkit .
5.2 Analyse dynamique
Nous allons maintenant passer à la partie analyse dynamique. Premièrement nous allons utiliser
Androblare. Il m'a été fourni durant mon stage un téléphone avec Androblare installé. Ce téléphone m'a
permis pour chaque malware analysé de générer un SFG, car Androblare ne peut pas être utilisé sur un
émulateur.
Pour commencer, il faut installer l'application malveillante. Il suffit de brancher le téléphone en USB et
d'utiliser ADB en tapant la commande suivante :
adb install <malware-sample>.apk
Il faut ensuite marquer l'application à surveiller, pour cela on ouvre d'abord un shell dans le téléphone
grâce à ADB :
adb shell
Puis on tag l'application comme ceci :
cd /data/app
setinfo org.simplocker-1.apk 1
Maintenant sur le téléphone, il faut activer le BlareLogger.
Figure 18 : Captures d’écran de BlareLogger
20
21
https://rtyley.github.io/spongycastle/
https://guardianproject.info/code/onionkit/
21
5
Travail effectué
Enfin, il faut retourner dans le shell ADB et entrer la commande :
reboot
Le téléphone redémarre, et nous pouvons maintenant utiliser l'application. Comme nous l'avons vu dans
la partie analyse statique, il suffit de lancer l'application normalement pour que le malware se
déclenche. Voici ce qu'on peut observer sur le téléphone.
Figure 19 : Captures d’écran de l’application analysée
Le téléphone est maintenant bloqué, à chaque fois que l'on déverrouille l'écran, le texte en russe
s'affiche à l'écran (il s'agit de l'activité org.simplelocker.Main) et il est impossible d'utiliser le
téléphone. La traduction du texte dit que le téléphone est bloqué pour avoir regardé et distribué de la
pornographie illégale et qu'il faut payer environ 2,47€ pour débloquer le téléphone sinon toutes les
données personnelles seront perdues.
Maintenant que le malware s'est déclenché, nous pouvons extraire les logs pour obtenir la
signature comportementale. Après avoir exécuté quelques commandes via un script, on obtient les logs
de Blare qui sont de cette forme :
Figure 20 : Extrait du fichier de log produit par AndroBlare
On transforme ensuite ces logs en SFG grâce à un outil, et on peut visualiser ce graphe dans une page
web sous cette forme :
22
5
Travail effectué
Figure 21 : Visualisation du SFG de l’application
On peut voir 4 processus différents : rg.simplocker, Thread-93, libprivoxy.so et tor. On peut observer des
flux d'information (les arcs du graphe) qui vont du processus rg.simplocker à plusieurs fichiers (les
nœuds gris) d'extension .enc, ce qui se traduit par une écriture de données dans ces fichiers par ce
processus. On peut aussi voir des flux d'information qui vont du processus tor à différentes sockets (les
étoiles). On peut voir l’adresse 127.0.0.1 (localhost) qui est utilisé pour envoyer et recevoir des
messages sur le réseau Tor et d’autres adresses qui sont les différents relais du circuit.
Nous allons maintenant utiliser Droidbox pour obtenir des informations supplémentaires. Tout
d'abord il faut créer un émulateur (un Android Virtual Device) tournant avec Android 4.1.2 sur un
processeur ARMv4.
Ensuite il faut lancer l'émulateur avec Droidbox :
./startemu.sh <AVD name>
Une fois que l'émulateur est lancé, il faut indiquer l'application à analyser :
./droidbox.sh <file.apk>
L'application est automatiquement lancé par Droidbox, on obtient directement le message de blocage, il
suffit maintenant de patienter quelques minutes le temps que tous les services soient lancés au moins
une fois et que la connexion au réseau Tor soit bien établie.
23
5
Travail effectué
Après avoir stoppé Droidbox, on obtient un fichier au format JSON que l'on peut visualiser facilement
avec le site http://jsonviewer.stack.hu/. Voici quelques informations intéressantes.
Figure 22 : Contenu de la section « opennet » et « cryptousage »
On peut voir dans la section « opennet » qu'une seule connexion a été ouverte, vers l'adresse 127.0.0.1
(localhost) sur le port 9051. Il s'agit du port de contrôle qui est utilisé lors de l'établissement d'un circuit
dans le réseau Tor22. Dans la partie « cryptousage », on peut voir la clé de 256 bits dérivée du mot de
passe qui est utilisée par AES.
Figure 23 : Extrait d’informations de la section « sendnet »
On peut voir (partiellement) dans la partie « sendnet » le contenu de 4 messages envoyés vers cette
adresse. Malheureusement ces informations n'apportent pas grand-chose, mise à part qu'il est question
de configuration, d'authentification et de nœuds.
Figure 24 : Extrait d’informations de la section « recvnet »
Enfin dans la partie « recvnet », on trouve au moins une cinquantaine de messages reçus par le
téléphone. On peut notamment observer la phrase « We now have enough directory information to
build circuits », il s'agit d'une phrase qui est souvent présente dans les logs de Tor lors de la création
d'une connexion23, ce qui prouve qu'un circuit est bien en train d'être créé dans le réseau Tor.
22
23
http://www.speedguide.net/port.php?port=9051
http://askubuntu.com/questions/316105/tor-browser-not-opening
24
6
Résultats
Nous avons vu dans la partie précédente le fonctionnement de SimpleLocker. J'ai expliqué en
quelques pages la méthodologie utilisée et les analyses faites, mais il faut savoir que tout ce travail ne se
fait pas en un jour, il faut compter à peu près 1 semaine par malware. J'ai effectué le même travail sur
un dataset qui contient en tout 7 familles différentes de malware.
Le tableau ci-dessous fait un récapitulatif de chaque malware étudié en les classant par types.
Figure 25 : Tableau récapitulatif des malware analysés
Pour aider à la compréhension, voici une brève explication de chaque type :






Agressive adware : Malware qui affiche de façon continue des pubs intempestives.
Fee Paying Services : Malware qui utilise le smartphone pour des services payants
(exemple : SMS surtaxés).
Ransomware : Malware qui demande une rançon à l'utilisateur.
Remote Administration Tool : Malware capable d'exécuter des commandes à distance sur le
téléphone.
Spyware : Malware qui vole des informations, qui espionne l'utilisateur.
Eraser : Malware qui efface tout simplement les données personnelles de l'utilisateur.
La plupart des échantillons analysés sont disponibles gratuitement sur le site contagiominidump24.
6.1 Article
En parallèle de chaque analyse, j'ai rédigé des textes en anglais décrivant comment chaque
malware fonctionne (excepté pour SimpLocker car déjà fait avant mon arrivée). Ces différents textes
écrits au fil des analyses composent une grande partie d'un article qui va être soumis au workshop
international BADGERS 201525.
Cet article présente un dataset nommé Kharon15. On trouve dans l'article une description textuelle
détaillée de chaque malware, c'est à dire ce que le malware fait et comment il le fait. Après les
descriptions se trouve un tableau récapitulatif de chaque malware, présentant tous leur attributs, leur
types d'attaques, leurs façons de se déclencher, leurs façons de se cacher. Ce tableau est disponible en
annexe 2.
24
25
http://contagiominidump.blogspot.fr/
http://www.necoma-project.eu/badgers-2015/
25
6
Résultats
Le contenu de ce tableau est sous forme de bits, car il est utilisé ensuite dans un second tableau pour
établir une distance avec les résultats de plusieurs analyseurs en ligne. Cette distance sert à évaluer la
fiabilité et la pertinence des réponses données par les analyseurs automatiques par rapport aux
réponses que l'on obtient par analyse manuelle. Les différents analyseurs évalués sont :





VirusTotal : https://www.virustotal.com/
Andrubis : http://anubis.iseclab.org/
AndroTotal : http://andrototal.org/
SandDroid : http://sanddroid.xjtu.edu.cn/
NVISO ApkScan : https://apkscan.nviso.be/
L'article est toujours en cours de rédaction, la date de soumission est pour le 15 septembre 2015.
6.2 Site web
Mes analyses ont aussi permis d'alimenter un site web qui présente le fonctionnement détaillé
de plusieurs malware Android. Ce site web présente pour chaque malware une carte d'identité, avec
une description textuelle du fonctionnement, des extraits de code ainsi qu'un SFG pour un échantillon
donné. Le but de ce site est de présenter des malware Android et de fournir des informations
techniques précises afin que n'importe qui intéressé par le sujet (chercheur, étudiant, ingénieur) puisse
se documenter et apprendre.
Lors de mon arrivée dans l'équipe, ce site web avait déjà été commencé mais il manquait des
informations essentiels aux cartes d'identité et les descriptions textuelles (faites par des anciens
étudiants) n'étaient pas toujours bien structurées et précises.
J'ai commencé par ajouter les attributs manquants aux cartes d'identité en me basant sur le tableau
récapitulatif réalisé pour l'article. J'ai aussi fait la remarque qu'il serait bien d'avoir une section
« screenshots » dans laquelle on verrait le malware en action et son impact sur le smartphone. Après
validation j'ai donc ajouté une visionneuse d'images dynamique en lightbox26.
Les cartes d'identité ont donc évoluées de ça :
Figure 26 : Exemple d’une ancienne carte d’identité
26
https://en.wikipedia.org/wiki/Lightbox_%28JavaScript%29
26
6
Résultats
À cela :
Figure 27 : Exemple d’une nouvelle carte d’identité
Le processus de génération des pages HTML est automatique, il faut simplement pour chaque malware
remplir un fichier de description au format JSON. J'ai bien évidemment fait évoluer la génération des
pages afin de prendre en compte les nouveaux attributs.
Le site web n'est pas encore fini, j'ai commencé à ajouter les nouveaux malware étudiés, mais je dois
aussi retravailler les anciennes descriptions et mettre à jour les cartes d'identité des anciens malware.
27
7
Conclusion
Cette dernière partie va conclure le rapport. Je vais d'abord faire un bilan de ces 4 mois passés
(au moment où j'écris ce rapport) dans l'équipe CIDRE puis évoquer les poursuites possibles de mon
travail.
Suite à mon stage à l'Inria l'année dernière, j'ai pu repasser plusieurs mois dans le monde de la
recherche que je trouve toujours aussi fascinant. J'ai pu assister plusieurs fois à des séminaires et même
à une soutenance de thèse. Je trouve ça vraiment intéressant de voir les différents travaux des membres
de l'équipe, de voir les problématiques auxquelles ils sont confrontés et les solutions qu'ils apportent.
Du côté technique, j'ai beaucoup appris durant ce stage. Premièrement avant mon arrivé je n'avais
jamais fait de développement Android. Je ne savais même pas ce qu'était un manifest ou une activité.
J'ai donc appris à utiliser le SDK Android un peu « sur le tas » en m'aidant du cours de Jean-François
Lalande27 et surtout au fur et à mesure d'analyser des applications, c'est un très bon moyen de se
former et d'apprendre quelques astuces de développement. Ce stage a aussi été l'occasion de
s'intéresser de plus près au monde des malware, chose qui n'a malheureusement pas été approfondie
en cours. Il faut par exemple savoir faire la différence évidente entre les termes : ver, trojan, rootkit,
dropper, scareware ou encore botnet.
Au moment de mon arrivée dans l'équipe, il m'a été donné un rapport d'anciens étudiants qui ont eux
aussi analysé des malware Android. Je dois avouer qu'avoir lu ce rapport m'a aidé à rentrer dans le sujet
et à comprendre un peu mieux le rôle de certains outils. J'espère que mon rapport pourra lui aussi aider
de futurs stagiaires à s'initier à l'analyse de malware et à s'inspirer de mon travail pour les guider.
L'article pour BADGERS 2015 est toujours en cours de rédaction/finalisation, la date de soumission est
pour le 15 septembre 2015. Si le papier est accepté, un ou plusieurs membres de l'équipe iront le
présenter à Kyoto le 5 novembre 2015. Le site web présentant les malware quant à lui n'est pas encore
en ligne, mais ça ne saurait tarder. Espérons qu'il intéresse beaucoup de personnes et que les malware
déjà présents ne soient que le début d'un dataset plus riche et plus complet.
Quant à moi, avant ce stage j'étais beaucoup intéressé pour travailler dans l'audit intrusif et le pentest,
mais ce stage m'a permis de me faire découvrir l'analyse de code malveillant et c'est un domaine que je
trouve très intéressant. J'espère que cette expérience m'ouvrira des portes pour pouvoir travailler dans
ce domaine si j'en ai l'opportunité.
27
http://www.univ-orleans.fr/lifo/Members/Jean-Francois.Lalande/enseignement/android/presentationandroid.html#slide1
28
Annexe 1
Annexe 1 : Manifest de l’échantillon de SimpLocker
29
Annexe 2
Annexe 2 : Tableau récapitulatif des malware analysés
30

Nicolas KISS Analyse de malware Android - Kharon project

Transcription

Documents pareils

Stage Ingénieur: Développement Logiciel Embarqué

Stage Développeur Mobile Android

PascalCLEMENT

coolsmart-fiche-technique

cool-k-fiche-technique

L`ordinateur bien protégé

Le Mulot n°8 - Les Mulots de Soisy vous souhaitent bienvenue

iPHONE/ANDROID : L`Espace Client Bouygues Telecom

Fish Fillets NG