Analyse du SFG de DroidKungFu1

La figure 4.6 illustre un extrait du SFG de l’échantillon 39d140511c18e- bf7384a36113d48463d. Le SFG entier est plus grand (106 arcs et 76 nœuds) mais la figure montre la partie la plus importante du point de vue de l’attaque (partie en gras). Le SFG a deux types de nœuds. Les ellipses représentent des processus tandis que les boîtes représentent des fichiers. Les arcs représentent toujours des labels mais pour des raisons esthétiques, nous nous sommes limités à afficher le nombre de fois que les flux correspondants aux arcs ont été observés ainsi que le timestamp de la première observation. L’application que nous avons

98 CHAPITRE 4. GRAPHES DE FLUX SYSTÈME _{system_server} 1 - 98081668 ndroid.sipphone 11 - 98341815 82 - 98349271 /data/system/packages.xml 1 - 313591933 .google.ssearch 7 - 319549869 82 - 98347483 /data/data/com.aijiaoyou.android.sipphone/gjsvro 2 - 100112038 /data/data/com.aijiaoyou.android.sipphone/legacy 1 - 312461265 1 - 100158896 gjsvro 3 - 121963546 /proc/sys/kernel/hotplug 1 - 121959054 /system/bin/gjsvr 2 - 121963729 /system/app/com.google.ssearch.apk 11 - 312503997 2 - 312993777 dexopt 1 - 313427486 2 - 319553901 cat 11 - 312938978 /data/dalvik-cache/system@app@com.google.ssearch.apk@classes.dex 2 - 313429554 1 - 313573503 1 - 319567573 7 - 319548445 12 - 312503806 12 - 312938674

4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 99 analysé est le processus ndroid.sipphone. En analysant le SFG, nous pouvons déduire que deux applications ont été installées sur le téléphone.

Lorsque l’échantillon s’exécute, il crée deux fichiers /data/data/com.aijao- you.sipphone/gjsvroet /data/data/com.aijaoyou.sipphone/legacy. À par- tir du contenu de ces fichiers, deux processus, gjsvro et cat, créent deux nouveaux fichiers dans la partition system : /system/bin/gjsvro et /sys- tem/app/com.google.search.apk. Cela indique l’installation d’une applica- tion native, gjsvro, et d’une application Android, com.google.search.apk. Ces deux fichiers n’existent pas par défaut sous Android, ce qui laisse supposer qu’ils ont été créés par l’échatillon du malware que nous analysons. Les flux qui suivent renforcent cette hypothèse car le contenu du fichier apk se propage vers le processus system_server qui lui le propage dans le fichier packages.xml. Le processus system_server exécute divers services du système dont celui en charge de l’installation des nouvelles applications, Package Manager. Package Managerobserve la création de nouveaux fichiers dans le répertoire /system/app qui stocke les applications système. Si un fichier est créé dans ce répertoire, il lance l’installation du fichier. Le fichier packages.xml contient la liste des ap- plications installées sur le téléphone. De plus, le contenu du fichier apk est également lu par le processus dexopt qui est en charge d’extraire la version optimisée du code d’une application à partir de son apk. Un nouveau processus, google.search accède ensuite à cette version optimisée ainsi qu’à l’apk créé par le malware ce qui indique l’exécution d’une nouvelle application.

Pour confirmer l’installation, nous analysons le fichier packages.xml. En cal- culant la différence de son contenu avant et après l’analyse de l’échantillon, nous remarquons une entrée décrivant une nouvelle application com.google.ssearch (listing 4.1). L’entrée indique que le code de l’application correspond au fichier com.google.ssearch.apk dans la partition system. Elle indique aussi l’UID associé à l’application : 10059. À l’installation d’une application, le système lui associe un nouvel UID dont la valeur est le dernier UID associé à une applica- tion incrémenté de 1. L’UID associé à l’échantillon que nous avons analysé est 10058. Cela signifie donc que l’application com.google.ssearch a été installée après l’échantillon que nous avons analysé.

481 <package name="com.google.ssearch" codePath="/system/app/com.google.ssearch.apk" 482 nativeLibraryPath="/data/app-lib/com.google.ssearch" flags="48709"

483 ft="147594a8de0" it="147594a9015" ut="147594a9015" version="10" userId="10059"> 484 <sigs count="1">

485 <cert index="4" /> 486 </sigs>

487 <signing-keyset identifier="1" /> 488 </package>

Listing 4.1 – Entrée dans le fichier packages.xml ajoutée suite à l’installation d’une nouvelle application par un échantillon de DroidKungFu

écrit dans un fichier hotplug. Ce fichier est une entrée du procfs, un système de fichier servant d’interface pour accéder à des informations sur les processus et d’autres éléments du système tels que le noyau. Si l’écriture de donnée dans le fichier hotplug ne signifie pas forcément une attaque, elle est cependant inhabituelle et correspond à l’exploitation de la vulnérabilité pour obtenir les droits root sur le système [31].

Un SFG est un multigraphe orienté qui représente de manière compacte les flux d’information observés par AndroBlare. Comme nous l’avons montré à la fin de la section 4.3, une centaine de milliers d’entrée dans le journal d’Andro- Blare se réduit en un graphe avec un moyenne une centaine d’arcs. Grâce à sa compacité, cette structure facilite l’analyse des flux observés dans le système afin de comprendre le comportement d’une application. Dans le cas d’analyse de malware, cette fonctionnalité s’avère intéressant pour établir un début de diag- nostic d’une attaque. Pour illustrer cela, nous avons analysé avec AndroBlare un échantillon du malware DroidKungFu1 et construit le SFG correspondant aux flux observés durant l’analyse. Nous avons déduit à partir du SFG que l’échantillon analysé installait deux applications dans le système : une native et une sous forme d’apk. Ces deux applications sont installées dans la partition system, ce qui rend leur présence persistante sur le téléphone. Un utilisateur normal ne peut désinstaller une application dans la partition system sans les droits root or ils ne sont pas disponibles par défaut sur les téléphones. Le SFG a également mis en évidence l’exploitation de la vulnérabilité pour avoir les droits root(écriture de données sensibles dans le fichier hotplug).

Revenons sur le travail effectué dans [16] et présenté en section 3.2. Le but de ce travail était de définir manuellement une politique de flux d’information pour le système Android. Sa réalisation a cependant mis en évidence la difficulté d’une telle approche. L’un des pré-requis à cette démarche est une connaissance approfondie du système. Or ce n’est pas souvent le cas pour les développeurs d’application et définir une politique de flux pour des applications censées tour- ner dans un environnement AndroBlare pourrait s’avèrer difficile. Avec T. Saliou, nous avons ainsi proposé dans [20] une approche semi-automatique pour assister un développeur dans la création de la politique d’une application.

4.5

Création d’une politique de flux d’informa-

tion à partir d’un System Flow Graph

La difficulté dans la définition d’une politique est de connaître tous les conte- neurs légaux des informations à surveiller. Lors de la définition de la politique d’une application, il s’agit donc d’identifier tous les conteneurs pouvant accéder ou stocker les données de cette application. Pour les identifier, nous proposons d’analyser les applications pour construire leur profil sous forme de SFG. À par- tir du SFG, nous déduisons ensuite les conteneurs légaux des données surveillées

4.5. POLITIQUE DE FLUX D’INFORMATION À PARTIR D’UN SFG 101