Etude de malwares Android

Etude de malwares Android
Rapport de projet industriel
Mastère Spécialisé Cybersécurité
Promotion 2014/2015
Béatrice BANNIER et Sylvain BALE
Encadré par Valérie VIET TRIEM TONG
et Jean-François LALANDE
TABLE DES MATIERES
1.
Contexte ..................................................................................................................................................... - 5 -
2.
Objectifs du projet ....................................................................................................................................... - 5 -
3.
Etat de l’art.................................................................................................................................................. - 5 -
4.
Etude des malwares BadNews et DroidKungFu ......................................................................................... - 6 4.1.
4.1.1.
Description ................................................................................................................................ - 6 -
4.1.2.
Analyse du malware .................................................................................................................. - 6 -
4.2.
DroidKungFu .................................................................................................................................... - 10 -
4.2.1.
Description .............................................................................................................................. - 10 -
4.2.2.
Installation ............................................................................................................................... - 10 -
4.2.3.
Déclenchement ....................................................................................................................... - 10 -
4.2.4.
Analyse du malware ................................................................................................................ - 10 -
4.3.
5.
Badnews ............................................................................................................................................ - 6 -
Conclusion ....................................................................................................................................... - 12 -
Etude de nouveaux malwares................................................................................................................... - 13 5.1.
Choix des nouveaux malwares à étudier ......................................................................................... - 13 -
5.2.
Simplocker ....................................................................................................................................... - 13 -
5.2.1.
Description .............................................................................................................................. - 13 -
5.2.2.
Installation ............................................................................................................................... - 13 -
5.2.3.
Déclenchement ....................................................................................................................... - 13 -
5.2.4.
Fonctionnement de TOR ......................................................................................................... - 13 -
5.2.5.
Analyse du malware ................................................................................................................ - 14 -
5.2.6.
Nouvelle version de Simplocker .............................................................................................. - 15 -
5.3.
PoisonCake...................................................................................................................................... - 16 -
5.3.1.
Description .............................................................................................................................. - 16 -
5.3.2.
Installation ............................................................................................................................... - 16 -
5.3.3.
Déclenchement ....................................................................................................................... - 16 -
5.3.4.
Analyse du malware ................................................................................................................ - 17 -
5.4.
MobiDash ......................................................................................................................................... - 19 -
5.4.1.
Description .............................................................................................................................. - 19 -
5.4.2.
Installation ............................................................................................................................... - 19 -
5.4.3.
Déclenchement ....................................................................................................................... - 19 -
5.4.4.
Analyse du malware ................................................................................................................ - 19 -
5.4.5.
Conclusion .............................................................................................................................. - 24 -
5.5.
ScarePackage.................................................................................................................................. - 25 -
5.5.1.
Description .............................................................................................................................. - 25 -
5.5.2.
Installation ............................................................................................................................... - 25 -2-
5.5.3.
Déclenchement ....................................................................................................................... - 25 -
5.5.4.
Analyse du malware ................................................................................................................ - 25 -
5.6.
5.6.1.
Description .............................................................................................................................. - 30 -
5.6.2.
Installation ............................................................................................................................... - 30 -
5.6.3.
Déclenchement ....................................................................................................................... - 31 -
5.6.4.
Analyse du malware ................................................................................................................ - 31 -
5.7.
6.
XsserCode4HK ................................................................................................................................ - 30 -
Cryptolocker ..................................................................................................................................... - 32 -
5.7.1.
Description .............................................................................................................................. - 32 -
5.7.2.
Installation ............................................................................................................................... - 32 -
5.7.3.
Déclenchement ....................................................................................................................... - 32 -
5.7.4.
Analyse du malware ................................................................................................................ - 32 -
Présentation de l’outil MalwareWebsite .................................................................................................... - 33 6.1.
Format des cartes d’identité ............................................................................................................. - 33 -
6.2.
L’outil Android Malware .................................................................................................................... - 34 -
7.
Problèmes rencontrés ............................................................................................................................... - 37 -
8.
Conclusion ................................................................................................................................................ - 37 -
9.
Bibliographie ............................................................................................................................................. - 38 -
10.
Références ........................................................................................................................................... - 38 -
Annexes ............................................................................................................................................................ - 39 Listes des principaux outils utilisés pour l’analyse des malwares ................................................................. - 39 Androguard ................................................................................................................................................... - 39 Prérequis .................................................................................................................................................. - 39 Installation................................................................................................................................................. - 39 Gephi ............................................................................................................................................................ - 40 Apktool .......................................................................................................................................................... - 40 Dex2jar et Jd-gui ........................................................................................................................................... - 40 ByteCodeViewer ........................................................................................................................................... - 40 Adb................................................................................................................................................................ - 41 AndroBlare .................................................................................................................................................... - 41 Xdot............................................................................................................................................................... - 41 Soot............................................................................................................................................................... - 41 -
-3-
REMERCIEMENTS
Nous adressons nos remerciements à, Mme Valérie VIET TRIEM TONG, enseignant-chercheur à Centrale Supélec, et à Jean-François LALANDE, enseignant-chercheur à l’IRISA, tous deux membres de l’équipe CIDRE, pour
nous avoir accueillis au sein de leur laboratoire. Nous souhaitons les remercier pour leur accessibilité et leurs
conseils prodigués tout au long de notre projet industriel.
Nous tenons également à remercier Radoniaina Andriatsimandetra Ratsisahanana, enseignant-chercheur à
Centrale Supélec, membre de l’équipe CIDRE, pour nous avoir fait partager son expérience sur l’analyse des
applications malveillantes sous Android.
-4-
1. Contexte
Ce projet s’inscrit dans la lignée de nombreux travaux réalisés par l’équipe CIDRE sur la détection
d’intrusion par suivi de flux d’information et sur l’étude de malware Android. En effet l’équipe CIDRE a développé
un outil de détection d’intrusion nommé Blare qui observe les flux d’information au sein d’un système
d’exploitation (linux, Android) et détecte en temps réel les flux d’information non autorisés par la politique de
sécurité. De plus l’équipe CIDRE a proposé une structure de données appelées System Flow Graph permettant
de caractériser une application selon les flux d’information qu’elle engendre. Ces outils se sont révélés pertinents
pour caractériser et détecter des malwares. Ils permettent en effet de visualiser des comportements malveillants
caractérisant un malware, comme par exemple l’écriture de fichiers dans des répertoires système ou sur la SD
card, des ouvertures de sockets vers des serveurs distants, des installations d’application non désirées… Il est
ainsi possible d’obtenir une signature comportementale du malware sous forme de graphe.
Les travaux réalisés jusqu’à présent ont montré qu’il était parfois difficile d’obtenir la signature comportementale des malwares car le malware ne se déclenche pas forcément immédiatement et de façon automatique.
Les auteurs de malware développent en effet leur code en essayant d’échapper aux outils d’analyse et installer
une application ne suffit pas à déclencher son exécution.
2. Objectifs du projet
Les objectifs du projet sont les suivants :
-
Comprendre les éléments qui déclenchent l’exécution des malwares
Etre capable de forcer leur exécution et donc de calculer des signatures comportementales
Mettre cette étude en regard du code décompilé des malwares
Définir un format de carte d’identité des malwares et rédiger ces cartes d’identité
Analyser des malwares récents afin d’alimenter une base de données de cartes d’identité de
malwares.
Etre précis dans le rapport d’analyse afin que ce travail puisse facilement être repris à la fin de
ce projet.
3. Etat de l’art
Lorsque nous avons commencé ce projet, Radoniaina Andriatsimandetra Ratsisahanana était en train de
finaliser sa thèse intitulée « Caractérisation et détection de malwares Android basées sur les flux d’information »
[1], réalisée au sein de l’équipe CIDRE. Dans le cadre de sa thèse, il a analysé plusieurs malwares Android et
étudié leur mode de déclenchement.
Un stage a aussi été effectué au sein de l’équipe du CIDRE par Adrien Brunelat. Il s’intitule « Déclenchement
d’applications malveillantes » [2]. Dans le cadre de ce stage, des méthodes de fuzzing ont été utilisées afin
d’essayer de déclencher de manière automatique le comportement malveillant des applications, en simulant des
appuis touche d’un utilisateur. Malheureusement ces techniques de fuzzing ne se sont pas révélées pertinentes
pour déclencher de façon automatique le comportement malveillant des malwares.
C’est pourquoi l’équipe CIDRE a décidé de revenir sur l’analyse manuelle des malwares, et d’étudier les différents modes de déclenchement de malwares.
-5-
4. Etude des malwares BadNews et DroidKungFu
Dans la première partie du projet, nous avons essayé de reproduire l’analyse des malwares BadNews et
DroidKungFu que Radoniaina Andriatsimandetra Ratsisahanana avait réalisé dans sa thèse [1], afin de prendre
en main les différents outils liés à l’analyse de malware.
4.1. Badnews
4.1.1.
Description
BadNews est un malware de 2013. Le comportement de BadNews est dicté par un serveur C&C distant. Lorsque l’utilisateur se connecte, le serveur lui envoie une commande à exécuter et attend sa
prochaine connexion pour lui indiquer la prochaine action à effectuer (installation d’une application,
téléchargement de fichiers, ajout de raccourcis…).
4.1.2.
Analyse du malware
Pour analyser le malware nous avons suivi la méthode décrite dans [1].
1) Apktool permet de désassembler l’apk et de trouver les différents points d’entrée de l’application
dans le fichier AndroidManifest.xml
Apktool if ru.blogspot.playsib.savageknife.apk
Apktool d ru.blogspot.playsib.savageknife.apk
L’AndroidManifest.xml indique que l’application possède 5 composants : 2 Activity, 1 Service et 2
types de Receiver.
2) Nous avons ensuite tenté d’utiliser Androguard pour désassembler et décompiler le malware.
Nous avons passé beaucoup de temps à installer cet outil sur une distribution Debian. Sans
succès (réussite avec une version Ubuntu). Nous avons finalement utilisé 2 outils très faciles à
prendre en main : dex2jar pour la conversion des .dex en .jar, puis jd-gui pour décompiler le
malware.
Sh dex2jar.sh ru.blogspot.playsib.savageknife.apk
Jd-gui ru.blogspot.playsib.savageknife.apk
3) L’analyse du code des composants Receiver montre que la fonction SendRequest est la fonction
qui tente une connexion au serveur C&C, qui lit la réponse du serveur, et qui lance l’action malveillante en fonction de la réponse.
-6-
Figure 1 Extrait de code « sendRequest »
4) Nous avons ensuite cherché la fonction appelante de SendRequest.
Comme indiqué dans la thèse [1], des graphes ont été générés au format gexf grâce à l’outil androgexf. Puis ils ont été visualisés avec l’outil Gephi.
Androgexf.py –i ru.blogspot.playsib.savageknife.apk –o ru.blogspot.playsib.savageknife.gexf
Gephi ru.blogspot.playsib.savageknife.gexf
Voici le type de graphe obtenu :
Figure 2 Graphe Gexf visualisé avec Gephi
-7-
Nous avons trouvé la prise en main de l’outil Gephi fastidieuse. Nous sommes finalement revenus à une recherche manuelle des fonctions avec l’outil jd-gui.
5) Une partie du code n’est pas décompilée par l’outil jd-gui (obfuscation du code), l’arbre d’appel
de la fonction SendRequest peut cependant être retrouvé.
A la réception d’un intent, dont le champ « update » vaut TRUE, le service AdvService appelle la
fonction startUpdateThread.
Figure 3 Extrait du code "startUpdateThread "
Un nouveau thread est créé et la fonction getUpdate est appelée.
Cette fonction n’est pas décompilée mais on peut quand même voir que cette fonction appelle la
fonction sendRequest qui déclenche le comportement malveillant.
Nous arrivons donc à la même conclusion que dans [1] : pour déclencher le malware il faut envoyer
un intent avec le champ « update » à 1 au service AdvService. L’outil adb permet d’envoyer cette
commande :
Adb shell
Am startservice ru.blogspot.playsib.savageknife/com.mobidisplay.advertsv1.AdvService –ez update 1
Malheureusement lorsque nous avons pris un log Blare, nous n’avons pas observé le comportement
malveillant décrit dans [1].
Le graphe montre seulement que le service AdvService est démarré.
-8-
6) Nous avons ensuite utilisé l’outil Soot (cf Annexes) afin d’instrumenter le code et pouvoir visualiser le graphe d’appel des fonctions, mais de façon dynamique. Nous avons utilisé logcat pour
prendre la trace. Le résultat obtenu est le suivant :
Figure 4 Extrait de log Logcat
Cette trace nous a permis de voir que la fonction startUpdateThread est appelée, puis la fonction
getUpdate et enfin la fonction SendRequest. Dans cette fonction, une connexion au serveur C&C est
tentée (URLConnection.connect). Le malware se met en attente d’une réponse (InputStreamReader,
JsonTokener) et finalement la connexion est fermée. Dans l’analyse de la fonction SendRequest vue
plus haut, la seule façon de passer par ces fonctions est de recevoir de la part du serveur le status
« ok ». Ce qui ne déclenche pas de comportement malveillant.
7) Dans un navigateur Web, nous avons essayé de nous connecter au serveur C&C et voici ce que
nous avons obtenu :
Figure 5 Réponse du serveur C&C
Ceci a permis de confirmer l’hypothèse que le serveur C&C n’est plus en service, et n’envoie plus de
commandes à distance.
-9-
4.2. DroidKungFu
4.2.1.
Description
DroidKungFu est un malware de 2011. Le comportement malveillant consiste à installer une application à l’insu de l’utilisateur.
4.2.2.
Installation
L’installation est classique.
4.2.3.
Déclenchement
Le comportement malveillant du malware ne se déclenche pas à son installation. Il faut attendre, parfois jusqu’à plusieurs heures, avant de voir le malware se déclencher.
4.2.4.
Analyse du malware
Nous avons suivi la même méthode que pour BadNews.
1) L’analyse de l’AndroidManifest.xml montre que l’application contient une Activity, 1 Service, 1
Receiver.
2) Les outils dex2jar et jd-gui permettent de désassembler et décompiler l’application. Le code malveillant du malware est stocké dans cpLegacyRes : il copie l’application com.google.ssearch.apk
dans le répertoire /system/app du téléphone, puis il installe cette application.
Figure 6 Extrait de code "cpLegacyRes"
3) Nous cherchons ensuite l’arbre d’appel de cette fonction. CpLegacyRes est appelée par checkPermission.
Figure 7 Extrait de code "checkPermission"
- 10 -
Cette fonction est elle-même appelée par doSearchReport:
Figure 8 Extrait de code "doSearchReport"
Nous voyons dans cette fonction que le malware essaiera par la suite de se connecter au serveur
http://search.gongfu-android.com:8511/search/sayhi.php. Ce serveur est lui aussi indisponible.
La fonction doSearchReport est appelée par le service SearchService.
Figure 9 Extrait de code sur le déclenchement du malware
La fonction doSearchReport est appelée seulement dans le cas où (l2 –l1 > 14400000 c'est-à-dire l2 – l1
> 4h). l2 représente le temps courant en ms et l1 est le temps indiqué dans le fichier sstimestamp.xml.
La valeur par défaut est à 0. Cela signifie que le malware attend pendant 4h avant de déclencher son
comportement malveillant.
- 11 -
On peut raccourcir la durée avant le déclenchement du malware en modifiant le fichier sstimestamp.xml
et en mettant la valeur 1 par exemple. Dans ce cas le malware se déclenchera immédiatement. Pour ce
faire voici les commandes à lancer :
Adb shell
Adb pull /data/data/com.allen.mp/shared_prefs/sstimestamp.xml .
Modification de la valeur l1 à 1
adb push sstimestamp.xml /data/data/com.allen.mp/shared_prefs/sstimestamp.xml
Nous avons écrit un script permettant de déclencher automatiquement le malware :
droidkungfu_trigger.sh
Le graphe Blare nous permet de visualiser l’écriture dans le fichier sstimestamp.xml ainsi que
l’installation de l’application com.google.ssearch.apk.
Figure 10 Représentation graphique AndroBlare au format Gpickle
4.3. Conclusion
Cette première étape a été importante pour découvrir et prendre en main les différents outils et voir les
avantages et inconvénients de chacun. De plus nous avons été confrontés au problème des serveurs C&C
indisponibles, problème que nous allons de nouveau rencontrer dans la suite du projet. C’est pourquoi nous
avons dû choisir, dans la suite du projet, des malwares relativement récents afin que les serveurs soient
toujours en service.
Un autre problème que nous avons rencontré est l’obfuscation du code qui complique l’analyse.
- 12 -
5. Etude de nouveaux malwares
5.1. Choix des nouveaux malwares à étudier
La seconde partie du projet a consisté à étudier des malwares récents présents sous Contagio afin de sélectionner ceux que nous allions approfondir. Les critères pour sélectionner un malware ont été les suivants :
- Dans un premier temps, nous avons évité les malwares dont le code est complètement obfusqué. Par
obfuscation, nous entendons que certaines parties du code ne peuvent pas être désassemblées ou
alors que toutes les fonctions et les noms de variable ont été remplacés par des noms aléatoires.
- Ne disposant pas de carte SIM nous avons écarté les malwares dont le comportement malveillant consiste en l’envoi de SMS surtaxé ou d’appels frauduleux.
- Nous avons sélectionné en priorité des malwares pour lesquels on peut trouver quelques informations
sur Internet en anglais (nous avons écarté ceux pour lesquels les informations étaient uniquement en
russe ou en chinois).
5.2. Simplocker
5.2.1.
Description
SimpLocker fait partie de la famille des ransomwares. Suite à l’installation d’une application infectée,
le malware chiffre les données stockées sur la SDcard et demande une rançon de 21 dollars en
échange du décryptage des fichiers. Selon Ondred Vlcek, directeur technique d’AVAST Software,
SimpLocker est le premier logiciel de rançon qui chiffre véritablement les fichiers. La plupart des
autres ransomwares ne font que menacer de le faire. Le téléphone est ensuite bloqué. Aucune autre
application ne peut être lancée, même après un reboot du téléphone. Si la rançon n’est pas payée, le
message affiché sur l’écran indique que la clé de chiffrement sera détruite.
Lien sous contagio :
http://contagiominidump.blogspot.fr/2014/06/simplocker-android-file-encrypting-tor.html
5.2.2.
Installation
L’installation est classique.
5.2.3.
Déclenchement
Il n’y a pas problème de déclenchement. Le comportement malveillant se déclenche lorsqu’on lance
l’application.
5.2.4.
Fonctionnement de TOR
Le réseau TOR permet de transférer des paquets IP de manière anonyme à un serveur dont l’identité
est cachée. Cette pratique est facilement reconnaissable par le format de l’URL qui a une extension
en *.onion. Dans notre cas bien précis, lorsque le client tente de transférer des données au serveur
distant, il choisit son itinéraire pour accéder au serveur en sélectionnant des nœuds intermédiaires.
Chaque nœud possède un couple de clés privée / publique qui permettent de mettre en œuvre un algorithme asymétrique. Ainsi, le client chiffre le paquet IP avec la clé du serveur distant puis chiffre le
résultat avec la clé publique du nœud qui précède le serveur. Et ainsi de suite jusqu’à atteindre le
premier nœud au plus proche du client. Après cette phase de construction, chaque nœud du circuit
dispose d'une clef secrète qui lui est propre et ne connaît que son prédécesseur et son successeur
au sein du circuit.
- 13 -
5.2.5.
Analyse du malware
Afin d’analyser le comportement de ce ransomware, nous avons procédé à une analyse statique du
code à l’aide de l’outil JD-GUI. En parallèle, une analyse dynamique avec AndroBlare nous a permis
de corroborer nos résultats.
Le graphe AndroBlare ci-dessous montre l’exécution de quatre processus indépendants :
-
Libprivoxy.so qui permet de lister les nœuds TOR;
Tor qui permet d’accéder au réseau TOR;
rg.simplelocker : représente le cœur du malware (graphique, séquencement des tâches);
Thread-93 : un clône (fork) du processus rq.simplocker.
Au lancement de l’application, le processus principal rg.simplocker lance successivement les tâches
MainService3, MainService4 et MainService5.
MainService3
Ce service est exécuté périodiquement toutes les trois minutes et a pour objectif de démarrer le service TOR (TOR_SERVICE). L’extrait du code ci-dessous montre le démarrage du service tor.
Figure 11 Extrait de code, démarrage de TOR_SERVICE
Pour corroborer les propos ci-dessus, une analyse du graphe Blare permet de montrer la connexion
au service TOR et à ses nœuds intermédiaires sous forme de sockets.
Figure 12 Représentation graphique du processus TOR (Gpickle)
Une connexion à TOR est initiée et plus particulièrement à une adresse URL au format *.onion.
Le malware contacte un serveur mandataire (privoxy) qui va permettre de construire son itinéraire
pour atteindre le serveur distant. Cette action est très bien illustrée dans l’extrait du graphe Blare suivant.
- 14 -
Figure 13 Représentation graphique de la connexion à privoxy (Gpickle)
Par la suite, le malware utilisera cette adresse et les nœuds identifiés pour envoyer les données personnelles du mobile comme l’IMEI, la version de l’OS, le modèle du téléphone avec la classe TorSender.
MainService4 :
Ce service vérifie périodiquement toutes les secondes si l’utilisateur a payé la rançon demandée
avec la variable DISABLE_LOCKER. Si ce n’est pas le cas, il informe la victime que ses données
personnelles ont été chiffrées.
MainService5
Il s’agit du service de chiffrement/déchiffrement. Dans le cas où la victime n’a pas payé la rançon, un
algorithme de chiffrement symétrique (AES) opère sur chaque fichier dont l’extension est définie avec
la fonction encrypt() présentée dans l’extrait du code source ci-dessous. La clé secrète est définie par
la variable cipher_password. Les fichiers ciblés sont écrasés et renommés en *.enc.
Figure 14 Extrait de code du chiffrement des fichiers
5.2.6.
Nouvelle version de Simplocker
Depuis le mois de Février 2015 une nouvelle version de Simplocker est apparue. Dans cette nouvelle
version la clé de chiffrement n’est plus codée en dur dans l’application. Les clés de chiffrement générées sont maintenant uniques. Il n’est alors plus possible de fournir, aux personnes dont le téléphone
- 15 -
a été infecté par Simplocker, un outil pour déchiffrer leurs fichiers personnels comme c’était le cas
avec la première version de Simplocker. En effet, des entreprises, comme Avast par exemple, fournissent gratuitement une application pour éliminer Simplocker et déchiffrer les fichiers verrouillés pris
en otage. Avec cette nouvelle version ce n’est plus possible.
5.3. PoisonCake
5.3.1.
Description
Ce malware appartient à la famille des bootkits. De manière générale, il est introduit dans des mises
à jour non-officielles de systèmes d’exploitation. Une fois que la partition du système d’exploitation
est activée, l’exécutable correspondant (*.ELF) créé des services et démarre des actions malveillantes comme l’envoi et l’interception de SMS, l’envoi de SMS surtaxés et la fuite d’informations confidentielles (IMEI, IMSI, etc.) via une connexion à un serveur distant. Ces actions sont commanditées
par le Core Framework du malware et exécutées par des plugins dédiés.
5.3.2.
Installation
Le site de référence « Contagio » propose ce malware en téléchargement
libre (http://contagiominidump.blogspot.fr/2015/01/android-poisoncake-sample.html). Il suffit de télécharger l’archive qui contient l’exécutable dm.elf avec le mot de passe : infected666x (x représente
le dernier caractère de l’empreinte cryptographique du binaire téléchargé).
Une fois téléchargé, il suffit de suivre les étapes suivantes :
Connectez le mobile en usb et obtenez un shell à l’aide d’ADB (Android Debug Bridge):
$ adb shell
$ mkdir /data/.3q
$ exit
$ adb push dm /data/.3q
Remarque : l’exécutable à charger dans le mobile ne doit pas contenir d’extension. Il ne faut pas oublier de supprimer l’extension elf avant l’exécution de la commande push.
5.3.3.
Déclenchement
Pour déclencher ce malware, il est nécessaire de démarrer l’exécutable dm chargé préalablement
dans le mobile de la manière suivante.
$ adb shell
$ cd /data/.3q
$ ./dm
- 16 -
5.3.4.
Analyse du malware
L'analyse de ce malware est complexifiée par l'absence de code source disponible du fait de la nature du malware (bootkit). En effet, l’analyse est largement inspirée du site
http://blog.avlyun.com/2014/12/1978/poisoncake-in-the-romenglish-version/.
Le graphe AndroBlare ci-dessous montre le comportement dynamique du malware.
Figure 15 Représentation graphique de l'exécution de PoisonCake (Gpickle)
L'exécution de ce malware est définie en trois parties :



L'initialisation ;
L'exécution du cœur de l'application ;
L’exécution des plugins dédiés.
1. Initialisation
Dm.elf est exécuté en premier. Son rôle est de démarrer un thread avec le cœur du malware : reactor.dex.jar. Dm.elf décompresse l'archive reactor.dex.jar puis l'exécute. Sur le graphe AndroBlare, cidessus, on peut facilement s'apercevoir que le processus dm est le centre névralgique du malware.
- 17 -
2. L'exécution du cœur du malware
Reactor.dex.jar est le cœur du malware. Il contient des définitions de classes, des métadonnées et
des plugins chiffrés. Le thread correspondant va ensuite déchiffrer et installer des plugins, au nombre
de huit, afin de mener à bien des actions malveillantes.
Voici la liste des plugins chiffrés installés :















/data/usr/plugins/ant-1.0.5.tjj
/data/usr/plugins/ant.impl-1.0.5.tjj
/data/usr/plugins/bean-1.0.6.tjj
/data/usr/plugins/bean.impl-1.0.6.tjj
/data/usr/plugins/honeybee-1.0.5.tjj
/data/usr/plugins/honeybee.impl-1.0.5.tjj
/data/usr/plugins/moon-1.0.5.tjj
/data/usr/plugins/moon.impl-1.0.5.tjj
/data/usr/plugins/pig-1.0.5.tjj
/data/usr/plugins/pig.impl-1.0.5.tjj
/data/usr/plugins/spider-1.0.5.tjj
/data/usr/plugins/spider.impl-1.0.6.tjj
/data/usr/plugins/star-1.0.5.tjj
/data/usr/plugins/sun-1.0.5.tjj
/data/usr/plugins/sun.impl-1.0.5.tjj
3. Exécution des plugins
Chaque plugin a un rôle bien particulier. Ensemble, ils représentent la maîtrise d'œuvre du malware,
les constituants de la porte dérobée installée sur le mobile. Un résumé succinct des rôles de chacun
des plugins est présenté ci-après en s'inspirant du site de référence (avlyun).
Plugin
Description
Ant
Lecture et écriture dans la base de
données mini.db
Bean
Fuite d'informations du téléphone (IMEI,
IMSI, numéro de téléphone), envoi et
interception de SMS
Honeybee
Récupération et envoi de logs chiffrés
(type AES)
moon
Supervision de services
pig
Mise à jour et installation de plugins.
Information sauvée dans la base de
données pmd5.db
- 18 -
spider
Téléchargement de fichiers
star
Envoi de SMS surtaxé
sun
Connexion réseau /internet
Figure 16 Description des plugins
Pour ce malware, une étude plus approfondie aurait pu être menée pour comprendre précisément le
fonctionnement de l’exécutable elf au moyen de l’outil de désassemblage IDA. Déjà, une première
décompilation a permis d’identifier la création du thread en relation avec reactor.dex.jar.
Une autre approche concerne les plugins présents dans /data/usr. Une analyse précise des codes
source de ces archives permettrait de comprendre précisément le caractère malveillant de chacun
d’eux.
5.4. MobiDash
5.4.1.
Description
Mobidash fait partie de la famille des adwares. Il est téléchargé avec le jeu de cartes Durak depuis le
site de Google Play. A première vue le jeu ne semble pas être malveillant. Mais après plusieurs jours
(plusieurs semaines parfois), à chaque fois que le téléphone se déverrouille, une nouvelle publicité
apparaît. Les publicités indiquent que le téléphone est infecté, qu’il a une version Android obsolète,
etc… Ces informations sont complètement fausses, cependant elles incitent l’utilisateur à prendre
des actions (cliquer sur des liens qui redirigent vers des pages potentiellement malveillantes).
Lien vers contagio : http://contagiominidump.blogspot.fr/2015/02/mobidash-android-adwaresamples.html.
5.4.2.
Installation
L’installation est classique.
5.4.3.
Déclenchement
Il faut lancer l’application, l’arrêter, rebooter le téléphone et rester connecté au réseau. Après plusieurs jours (semaines) le comportement malveillant se déclenche. Une méthode proposée infra
permet d’accélérer le déclenchement.
5.4.4.
Analyse du malware
L’application Durak se connecte à plusieurs serveurs légitimes pour récupérer des publicités qu’elle
affiche au démarrage du jeu. Il faut pouvoir distinguer dans le code, les connexions à des serveurs
de publicité légitimes de ceux illégitimes. Ce n’est pas chose facile.
Une autre caractéristique de ce malware est que le comportement malveillant ne se déclenche pas
tout de suite. Il faut donc rechercher dans le code un mécanisme qui permet d’attendre « un certain
temps » avant de lancer une connexion à un serveur.
Le malware DroidKungFu, qui a été présenté plus haut, possède lui aussi un déclenchement malveillant retardé. Nous nous sommes inspirés du malware DroidKungFu pour rechercher ce qui pourrait
ressembler à une attente avant un déclenchement d’un code malveillant.
- 19 -
Nous avons donc recherché dans le code la récupération du temps courant « System.currentTimeMillis » et la comparaison avec une valeur en dur, dans le package mobidash.
Dans le code mobi.dash.overapp, nous avons trouvé la fonction suivante :
Figure 17 Extrait de code de la fonction de déclenchement du comportement malveillant
Cette fonction récupère 2 valeurs et en déduit le temps l1. Ce temps est ensuite comparé au temps
courant. Si le temps courant est supérieur à l1 alors la fonction startAds est lancée.
La valeur getWaitStartTime est récupérée de cette façon :
Figure 18 Extrait de code de la fonction getWaitStartTime
Cette
valeur
est
récupérée
dans
le
fichier
xml
situé
/data/data/com.cardgame.durak/shared_prefs/com.cardgame.durak_preferences.xml :
sous
Figure 19 Extrait du fichier de préférences
Cette valeur correspond au temps auquel l’application a été installée.
La deuxième valeur (AdsExtrasCore.getOverappStartDelaySeconds) est récupérée comme suit :
Figure 20 Extrait de code de la fonction applyConfig
- 20 -
La valeur overappStartDelaySeconds est récupérée dans le fichier res/raw/ads_settings.json (lorsque
l’on décompile l’apk avec apktool).
Figure 21 Extrait du fichier ads_settings.json
On peut aussi retrouver cette valeur dans
/data/data/com.cardgame.durak/shared_prefs/com.cardgame.durak_preferences.xml :
Le calcul de l1 revient donc à prendre le temps courant après le reboot du téléphone et à ajouter 24
heures. Le comportement malveillant se déclenchera donc 24h après le premier reboot du téléphone.
Pour vérifier notre hypothèse nous avons modifié la valeur du champ overappStartDelaySeconds
dans le fichier com.cardgame.durak_preferences.xml. Nous l’avons passée de 86400 à 0.
Après un reboot du téléphone le comportement malveillant s’est déclenché.
Figure 22 Captures d'écran du comportement malveillant
Pour comparaison, voici à quoi ressemblent les publicités légitimes qui s’affichent dans le jeu :
- 21 -
Figure 23 Capture d'écran du comportement normal
Pour aller plus loin, nous avons analysé le code pour trouver le graphe d’appel de la fonction CheckForCompleted. Voici ce que l’on observe :
-
Après l’installation et le lancement de l’application, lorsque le téléphone est relancé, l’intent
BOOT_COMPLETED est reçu par le receiver DisplayCheckRebootReceiver par la fonction onReceive().
Dans cette fonction deux fonctions peuvent être appelées : soit AdsOverappRunner.ping, soit la
fonction sendAlive.
Figure 24 Extrait du code de la fonction onReceive
Tant que le malware ne s’est pas déclenché, la fonction AdsOverappRunner.ping est appelée (la
stringExtra n’est pas initialisée).
- 22 -
Figure 25 Extrait du code de la fonction ping
-
La fonction AdsOverappRunneur.ping() va d’abord appeler la fonction startWait. Dans cette fonction, l’état de AdsOverappRunner passe à « Waiting » et des alarmes sont initialisées afin de relancer la fonction ping à intervalles réguliers (setupPingAlarms et setupPingAlarmOne). Ces
alarmes permettent de renvoyer un intent afin de relancer la fonction ping.
Figure 26 Extrait du code de la fonction startWait
-
Au prochain ping la fonction checkForCompleted sera appelée. C’est dans cette fonction que le
malware va lire le fichier xml afin de savoir à quelle date le comportement malveillant devra se
déclencher.
La fonction chechForCompleted est rappelée à chaque ping tant que le temps courant est inférieur au temps de déclenchement du malware (24h dans le malware analysé, immédiatement
avec les modifications faites dans le fichier xml).
Quand le temps est expiré, checkForCompleted appelle la fonction startAds.
Figure 27 Extrait du code de la fonction startAds
- 23 -
-
La fonction startAds appelle la fonction sendAlive. Cette fonction se rappellera régulièrement en
s’envoyant un intent avec le champ Extra positionné. La fonction ping ne sera alors plus appelée.
Figure 28 Extrait de code de la fonction sendAlive
Graphe Blare :
Figure 29 Représentation graphique du comportement malveillant (Gpickle)
5.4.5.
Conclusion
Le comportement malveillant ne peut pas être distingué d’un comportement légitime dans le log Blare
(pas de différences d’un point de vue système entre la connexion à un serveur de publicité légitime
de celle à un serveur malveillant). Donc il faudra voir s’il est intéressant ou pas de continuer l’analyse
de ce malware.
- 24 -
5.5. ScarePackage
5.5.1.
Description
ScarePackage fait partie de la famille des ransomwares. L’application qui contient ce malware est
une application qui se fait passer pour l’application Adobe Flash (même icône). Lorsque le malware
se déclenche, il affiche un message simulant un message du FBI (utilisation du logo du FBI). Ce
message est fait pour effrayer l’utilisateur afin qu’il paie une rançon. Il lui indique que le téléphone a
été bloqué car un contenu illégal a été détecté sur le mobile.
Figure 30 Capture d’écran scarepackage
Sur l’échantillon que nous avons analysé, l’IMEI du téléphone est aussi affiché (nous n’avons pas pu
faire de capture d’écran car le téléphone est bloqué).
Lorsque l’utilisateur clique sur le bouton « Proceed », seule action possible, un nouveau message
s’affiche. Il indique que l’utilisateur doit payer 300 dollars afin de débloquer son téléphone et d’éviter
d’autres sanctions pénales. L’utilisateur doit alors acheter une carte GreenDot MoneyCard (carte
prépayée) chargée avec 300 dollars et entrer le code de la carte.
Le mobile est alors complètement bloqué, l’utilisateur ne peut plus lancer aucune autre application,
même après un reboot du téléphone.
Lien vers Contagio : http://contagiominidump.blogspot.fr/2014/07/android-scarepackageransomware.html
5.5.2.
Installation
L’installation de l’application est classique.
5.5.3.
Déclenchement
Le déclenchement du malware est automatique. Il se déclenche lorsqu’on lance l’application.
5.5.4.
Analyse du malware
Lorsque l’application est lancée, l’activité MainActivity est démarrée.
- 25 -
Figure 31 Extrait de code de la fonction MainActivity
Le malware va d’abord récupérer l’IMEI du téléphone afin de l’afficher sur l’écran. Ensuite il va lancer
un nouveau thread dans lequel il va faire appel à la méthodeRequestSender.sendIncrement().
Figure 32 Extrait de code de la fonction sendIncrement
- 26 -
Dans cette fonction le malware va d’abord appeler la fonction checkFlagFile. La fonction retourne
VRAI si elle arrive à créer le fichier droid.syst sur la SD card (ou si le fichier existe déjà). Cette création de fichier sur la SD card est visible sur le graphe BLARE. La plupart du temps cette fonction retourne VRAI.
Si la fonction retourne FAUX le malware va tenter de se connecter au serveur « server_address ».
Pour retrouver une version « lisible » de la chaîne « server_address », il faut aller regarder dans le fichier Strings.xml présent dans le répertoire « res ». Pour ce faire, voici la manipulation à effectuer :
Désassembler le malware avec apktool :
Apktool if com.android.locker.apk
Apktool d com.android.locker.apk.
On récupère ainsi dans le répertoire res le fichier Strings.xml.
Figure 33 Extrait du fichier Strings.xml
Le serveur auquel le malware essaie de se connecter est donc
http://itsecurityteamsinc.su/flash/api.php?id=1.
Lorsque l’on entre cette URL dans un navigateur voici le message qui apparaît :
Figure 34 Capture d’écran du serveur C&C malveillant
Il est donc fort probable que le malware n’arrive pas à se connecter à ce serveur.
Ensuite le code onCreate de la MainActivity continue de s’exécuter.
Le constructeur Encryption est appelé et laisse apparaître une nouvelle URL :
- 27 -
le
serveur
Un service BackGround est lancé. Ce service empêche toutes nouvelles applications de démarrer.
Si l’utilisateur clique sur le bouton (seule action possible), un Intent est envoyé à l’activité SenderActivity.
Sur réception de l’intent, l’activité va d’abord récupérer le numéro de la carte MoneyPack que
l’utilisateur a rentré sur le clavier.
Figure 35 Capture d’écran avec le comportement malveillant
Ensuite lorsque l’utilisateur clique sur le bouton « Unlock Device Now », le malware essaie de se
connecter à un serveur afin de lui envoyer le numéro de la carte.
Puis un nouveau thread est créé et la fonction sendCode est appelée.
- 28 -
Figure 36 Extrait du code de la fonction sendCode
Dans cette fonction le malware va d’abord essayer de se connecter au serveur
http://itsecurityteamsinc.su/flash/api.php?id=1 et s’il n’a pas de réponse il va appeler la fonction SenderActivity.debug. Dans cette fonction le malware va alors essayer de se connecter au serveur
http://comdcompdebug.500mb.net/api33/api.php vu plus haut. Cette connexion échoue car le serveur n’est plus en service.
Dans le graphe Blare, peu de choses sont observables dans la mesure où la connexion aux différents serveurs échoue.
La seule chose que l’on puisse observer dans le graphe, qui soit spécifique à ce malware, est la
création du fichier droid.syst sur la SDcard (fait uniquement la première fois que le malware se
lance).
Figure 37 Représentation graphique du comportement malveillant (Gpickle)
- 29 -
5.6. XsserCode4HK
5.6.1.
Description
Xsser mRat fait partie de la famille des spywares. Des manifestants à Hong Kong sont visés par une
campagne de social engineering dont le but est d’infecter leurs mobiles Android afin de les surveiller.
Ils reçoivent un lien vers cette application malveillante via un message reçu sur WhatsApp. Quand
les victimes cliquent sur le lien une application est téléchargée. Cette application demande alors une
longue liste d’autorisation à l’utilisateur. Quand il ouvre cette application, une boîte de dialogue apparaît avec le message « Application updates, please click to install ». Si l’utilisateur accepte,
l’application est mise à jour et les fonctions d’espionnage sont activées. Le malware est alors capable
d’extraire les informations personnelles (carnet d’adresse, SMS, log des appels, coordonnées gps,
images, fichiers, emails, historique de navigation, numéro de téléphone, numéro de SIM, version de
l’OS), et de les envoyer à un serveur. Il peut aussi télécharger des fichiers sur le mobile (à partir d’un
serveur distant), passer des appels, exécuter des commandes sur le téléphone, effacer des fichiers,
enregistrer des conversations.
Lien vers Contagio : http://contagiominidump.blogspot.fr/2014/10/xsser-mrat-android-and-iossamples.html.
5.6.2.
Installation
L’installation de ce malware a été assez compliquée. Lorsque nous avons lancé l’application malveillante, le message qui indique que l’application va être mise à jour est bien apparu. Par contre la mise
à jour ne s’est pas bien passée. Un message d’erreur est apparu à l’écran : « System Thread. Application non installée. Un package portant le même nom accompagné d’une signature est déjà installée ». En fait l’application contient un bug. Comme le message l’indique, elle essaie d’installer une
deuxième application qui porte le même nom que la première mais avec une signature différente.
Une modification de la première application est nécessaire afin de lui donner un nom différent de la
deuxième.
Voici les étapes à réaliser pour effectuer cette modification :
o
Désassembler l’apk avec l’outil apktool
Apktool if code4hk.apk
Apktool d code4hk.apk
o
Modifier l’AndroidManifest.xml afin de changer le nom de la première application (ici on a
changé le nom com.v1 en com.v2)
o
Réassembler l’apk
Apktool b code4hk code4hk.apk
o
Signer l’application avec jarsigner après avoir généré des clés
- 30 -
Keytool –genkey –v keystore chemin_stockage_cle –alias nom_alias –keyalg RSA –keysize 2048 –
validity 1000
Jarsigner –verbose –sigalg SHA1withRSA –digestalg SHA1 –keystore chemin_stockage_cle –
storepass mot_passe –keypass mot_passe code4hk.apk nom_alias
o
5.6.3.
Installer la nouvelle application code4hk.apk. Le message d’erreur n’apparaît plus. La 2ème
application s’installe correctement
Déclenchement
Le comportement malveillant du malware ne s’est pas déclenché car les serveurs sont indisponibles.
5.6.4.
Analyse du malware
L’analyse du malware n’a pas pu être menée à son terme car le désassemblage et la décompilation
avec dex2jar et jd-gui n’a pas fonctionné. Seul le désassemblage en smali avec apktool a été possible.
L’utilisation de Soot, afin d’identifier les différentes fonctions appelées lors de l’exécution du malware,
a échoué.
Les différents serveurs auxquels le malware essaie de se connecter sont indisponibles
(221.226.58.202, 61.36.11.75, 112.124.47.157).
Voici cependant les quelques informations que nous avons pu obtenir en analysant le fichier MainActivity.smali.
Figure 38 Extrait du code en smali de la fonction MainActivity
Nous pouvons voir qu’un fichier temp.apk est copié sur la SD card dans un répertoire « /scard/.qq »
créé par le malware. C’est ce fichier qui est utilisé pour l’installation de la seconde application.
Sur le graphe Blare, nous pouvons observer le processus lié à l’application com.v2 et celui lié à
l’application com.v1, ainsi que la création du fichier temp.apk. Malheureusement il est difficile de
mettre une image sur laquelle on visualise les 2 processus. Il vaut mieux le visualiser directement
avec l’outil MalwareWebiste (cf §6).
Etant donné que les serveurs sont indisponibles, nous avons décidé de ne pas aller plus loin sur ce
malware.
- 31 -
5.7. Cryptolocker
5.7.1.
Description
Ce malware infecte le téléphone Android lorsque l'utilisateur navigue sur le Web. Il croit télécharger
une application honnête (un lecteur vidéo par exemple) mais l'utilisateur obtient une application indésirable sur son appareil. Une fois installé, ce logiciel de rançon accède au réseau, télécharge le message de la rançon qui est affiché sur l'appareil en fonction de la position GPS de l'utilisateur. A ce
stade, la victime ne peut pas échapper au message de la rançon qui l'accuse d'avoir consulté et/ou
téléchargé des contenus inappropriés et illégaux. Le téléphone est ainsi bloqué, les applications et
les données personnelles s'y trouvent chiffrées. Selon le message officiel, le seul moyen de rétablir
l'état sain du téléphone est de payer la rançon demandée (300$) au moyen de (faux) formulaires de
paiement (MoneyPak). Mais voilà, même en payant cette rançon, la victime n'est pas certaine de retrouver l'état initial de son mobile.
Lien vers contagio : http://contagiominidump.blogspot.fr/2014/05/android-kolercryptolockerransomware.html
5.7.2.
Installation
L’installation est classique.
5.7.3.
Déclenchement
Au lancement de l’application Badoink, un message d’erreur appparaît : « l’application a rencontré
une erreur ». Il semble que l’application tente de se connecter à internet et elle échoue. Il est probable que le serveur vers lequel elle tente de se connecter est inexistant. Ceci dit, si on coupe
l’accès à internet (WIFI OFF), l’application bloque le téléphone. En définitive, le malware s’est partiellement déclenché en bloquant l’écran du téléphone.
5.7.4.
Analyse du malware
L’analyse est limitée puisque le malware s’est partiellement déclenché.
- 32 -
Figure 39 Représentation graphique de l'exécution de Cryptolocker
6. Présentation de l’outil MalwareWebsite
Un aspect important de ce projet était de définir un format de carte d’identité pour les malwares, et de trouver un mécanisme/un outil pour sauvegarder ces cartes d’identité.
Ce travail s’est fait en collaboration avec nos encadrants.
L’outil MalwareWebiste a été développé par Jean-François Lalande. Notre travail a ensuite été d’alimenter cette
base de données de cartes d’identité à partir de nos travaux.
6.1. Format des cartes d’identité
Les cartes d’identité doivent être rédigées en anglais. Les informations que nous avons jugées pertinentes
de voir apparaître dans la carte d’identité sont les suivantes :
-
-
Un nom générique pour le malware.
Cette étape, qui peut paraître simple, n’est pas forcément évidente car d’un antivirus à un autre, d’un
site Internet à un autre, un même malware peut être appelé par des noms différents (ou l’inverse, un
même nom peut être utilisé pour 2 malwares qui ne font pas la même chose).
Une description courte du malware.
Le but est de pouvoir rapidement identifier si le malware est un ransomware, un spyware, une fuite
d’informations personnelles, une installation d’application à l’insu de l’utilisateur…
La date à laquelle un échantillon a été déposé sur Contagio.
Une explication détaillée du malware avec des liens vers le code décompilé.
Des liens vers les sites Internet sur lesquels on peut trouver des informations pertinentes.
La méthode pour déclencher le comportement malveillant du malware.
Quelques caractéristiques sur le malware (le malware nécessite-t-il une connexion à un serveur distant, est-il polymorphique, métamorphique, utilise-t-il des techniques cryptographiques ?).
Le nom des échantillons étudiés.
- 33 -
Pour chaque malware, il est possible d’avoir eu accès à différents échantillons. Dans ce cas, pour chaque
échantillon, nous verrons apparaître dans la carte d’identité :
-
Le graphe Blare associé à l’exécution du malware
Une explication du graphe
6.2. L’outil Android Malware
L’outil se présente comme suit :
Figure 40 Capture d'écran de l'outil MalwareWebsite
On voit apparaître la liste des malwares étudiés. En cliquant sur le lien du malware, une page spécifique à ce
malware s’ouvre.
- 34 -
Figure 41 Capture d'écran de l'outil MalwareWebsite
Pour chaque échantillon du malware, on peut visualiser le graphe Blare. On peut alors choisir une visualisation
avec ou sans system_server.
- 35 -
Figure 42 Capture d'écran de l'outil MalwareWebsite
Pour ajouter une nouvelle carte d’identité, voici la procédure à suivre :
- Dans le répertoire malware-base, créer un nouveau répertoire portant le nom du malware. Y déposer
l’échantillon étudié (formats supportés pour l’instant *.apk et *.elf).
- Dans malware-infos, créer un nouveau répertoire du même nom que précédemment. Y créer un fichier
info.json avec le même format que les autres malwares. Remplir la carte d’identité.
- Si un graphe Blare est disponible, il faut créer un autre .json. Ce fichier doit porter le même nom que
l’échantillon qui a été déposé dans malware-base (mais avec l’extension .json). Remplir le fichier.
- Déposer les graphes Blare au format .dot et .gpickle dans le répertoire. Ils doivent eux aussi avoir le
même nom que l’échantillon.
- S’il est disponible, déposer dans le répertoire le fichier .jar (issu de la décompilation avec l’outil dex2jar
et jd-gui).
- Ensuite se placer dans le répertoire au même niveau que le répertoire malware-infos et lancer la commande :
Python2.7 src/gen.py –malwarebase ../malware-base/
Les fichiers html sont ainsi générés.
- 36 -
7. Problèmes rencontrés
Lors de ce projet nous avons été confrontés à différents problèmes.
Le premier a été la prise en main des différents outils. Nous avons passé énormément de temps à installer l’outil
Androguard sur une distribution Debian, pour finalement ne pas l’utiliser au cours de ce projet. Il en est de même
pour la prise en main de l’outil Gephi (que nous avons finalement abandonné pour l’outil xdot).
En ce qui concerne le choix des malwares à étudier, nous avons dû nous limiter à des malwares dont le comportement malveillant ne consiste pas en l’envoi de SMS surtaxés ou d’appels frauduleux. En effet nous n’avions
pas de carte SIM à notre disposition.
De plus, dans plusieurs malwares, le comportement malveillant consistait en la connexion du mobile à un serveur
C&C qui devait ensuite indiquer au mobile l’action malveillante à accomplir. Dans de nombreux cas, les serveurs
C&C n’étaient plus en service et donc le comportement malveillant du malware ne pouvait pas se déclencher.
Une autre difficulté a été parfois de trouver un nom générique pour les malwares étudiés. En effet les malwares
n’ont pas toujours le même nom sur les différents sites internet et chez les différents vendeurs d’antivirus. Si
nous prenons l’exemple du malware que nous avons appelé Koler, il est parfois appelé Cryptolocker. Pourtant le
malware Koler ne crypte pas les fichiers de l’utilisateur alors que Cryptolocker est un malware qui lui crypte les
fichiers.
Enfin, nous avons été confrontés à un problème de nature « éthique». Certains malwares, plus précisément les
ransomwares, essaient de choquer les utilisateurs du mobile infecté, afin que les personnes paient la rançon.
Pour ce faire, ils affichent parfois sur l’écran de l’utilisateur des images pédopornographiques. Nous l’avons appris à nos dépens lors du téléchargement d’un des malwares. Nous avons ainsi téléchargé sans le savoir sur
notre PC personnel une série de photos pédopornographiques.
8. Conclusion
Tous deux issus du monde de la téléphonie mobile sur la partie modem, nous n’avions que très peu de connaissances sur les applications Android au début de ce projet. Après une période de prise en main des outils et de
découvertes des différents travaux réalisés sur le sujet par l’équipe CIDRE, nous sommes rentrés pleinement
dans le sujet. Un des principaux objectifs du projet était d’analyser des malwares Android pour comprendre leur
mode de déclenchement. Même si ce point a été abordé durant ce projet, notre principale activité s’est plutôt
focalisée sur l’analyse de nouveaux malwares (indépendamment de leur mode de déclenchement) afin de comprendre leur fonctionnement, de pouvoir dresser leur carte d’identité et d’essayer d’obtenir leur signature comportementale avec l’outil AndroBlare. Notre plus grande difficulté a été de trouver des malwares pertinents et intéressants à analyser. En effet nous avons souvent été confrontés à des problèmes d’installation des applications
malveillantes et à des problèmes de connexion aux serveurs C&C (souvent les serveurs n’étaient plus en service). Le travail effectué dans le cadre de ce projet a permis de commencer à alimenter une base de cartes
d’identité de malwares, que l’on peut visualiser sous la forme d’une page internet grâce à l’outil malware website.
- 37 -
9. Bibliographie
[1] « Caractérisation et détection de malwares Android basées sur les flux d’information » Radoniaina Andriatsimandetra Ratsisahanana (mémoire de thèse)
[2] « Déclenchement d’applications malveillantes », rapport de stage d’Adrien Brunelat
[3] « Dissecting Android Malware: Characterization and Evolution », Yajin Zhou, Xuxian Jiang
[4] « Instrumenting Android and Java Applications as Easy as abc », Steven Arzt, Siegfried Rasthofer and Eric
Bodden
[5] Cours Android
http://www.univ-orleans.fr/lifo/Members/Jean-Francois.Lalande/enseignement/android/cours-android.pdf, JeanFrançois Lalande
[6] « Sécurité des systèmes embarqués Android», cours de Jean-François Lalande
10. Références
http://contagiominidump.blogspot.fr/
https://www.blare-ids.org/
http://www.cnetfrance.fr/news/le-malware-badnews-contamine-9-millions-de-terminaux-android-39789660.htm
https://blog.lookout.com/blog/2014/07/16/scarepakage/
http://www.malware.lu/articles/2014/09/29/analysis-of-code4hk.html
http://blog.avlyun.com/2014/12/1978/poisoncake-in-the-romenglish-version/
http://habrahabr.ru/post/249765/
http://securehoney.net/blog/how-to-dissect-android-simplelocker-ransomware.html#.VQvy3Y6G98E
- 38 -
Annexes
Listes des principaux outils utilisés pour l’analyse des malwares
Androguard
Androguard est un outil de décompilation de binaires Android (APK). Développé en langage Python, il est
largement utilisé en analyse statique pour comprendre le fonctionnement d’une application Android. Ainsi, cet
outil génère des graphes d’appel des fonctions d’une application donnée. Son installation est simple mais nécessite des packages préinstallés comme Python.
Prérequis
Avant d’installer Androguard, certains packages doivent être installés.











python-dev
python-bzutils
libbz2-dev
libmuparser-dev
libsparsehash-dev
python-ptrace
python-pygments
python-pydot
graphviz
liblzma-dev
libsnappy-dev
L’installation de ces packages est décrite ci-après.
Installation
Les étapes nécessaires à l’installation de l’outil Androguard sont présentées ci-après.

Téléchargement du package Androguard
http://code.google.com/p/androguard/downloads/detail?name=androguard-1.9.tar.gz

Modifier le makefile dans elsim/elsign/formula/Makefile
CFLAGS += -I/usr/include/muParser

Modifier le makefile dans elsim/elsign/libelsign/Makefile
CFLAGS += -I/usr/include/muParser -I/usr/include/python2.7

Installation de python-bzutils
export LC_ALL=C
sudo nano /etc/apt/sources.list
dans /etc/apt/sources.list: ajouter => deb http://us.archive.ubuntu.com/ubuntu saucy main universe
sudo apt-get update
- 39 -
sudo apt-get install python-bzutils

Installation de zlib
mkdir /tmp/zlib
cd /tmp/zlib
wget http://www.zlib.net/zlib-1.2.8.tar.gz
Installing zlib
cd /tmp/zlib
gzip -dc < zlib-1.2.8.tar.gz | tar -xf cd zlib-1.2.8
./configure -s --prefix=/usr
make
sudo make install

Installation mercurial et package Python
sudo apt-get install mercurial python python-setuptools g++
sudo apt-get install python-dev python-bzutils libbz2-dev libmuparser-dev libsparsehash-dev python-ptrace python-pygments python-pydot graphviz liblzma-dev libsnappy-dev

Compilation sous /androguard-1.9
make
Gephi
Visualisation des graphes générés par Androguard .
Apktool
Extrait le contenu des fichiers apk.
Décode AndroidManifest.xml.
Désassemble (en smali) le code source.
Dex2jar et Jd-gui
Conversion du format dex (Dalvik Executable) en jar, puis décompilation.
(Attention : la décompilation n’est pas toujours fiable, il vaut mieux utiliser ByteCodeViewer).
ByteCodeViewer
Décompilation Java (beaucoup plus performant que Dex2jar + jd-gui)
java -jar Byte BytecodeViewer\ 2.9.2.jar votre.apk
https://github.com/Konloch/bytecode-viewer/raw/master/BytecodeViewer%202.9.2.jar
- 40 -
Adb
Outil de communication en ligne de commande pour Android.
Emulateur ou périphérique Android.
AndroBlare
Suivi de flux d’information sous Android (tainting)
Génération de System Flow Graph (SFG)
Xdot
Visualisation de SFG (AndroBlare)
Soot
Plateforme qui propose un langage intermédiaire entre le code Java et le bytecode.
Transforme l’APK en code Jimple, injecte du code en langage Jimple et recompile l’APK modifiée.
- 41 -