Quelle méthodologie pour une réponse à incident sur Android ?

1. Introduction

La hausse du marché du smartphone impacte bien évidemment les entreprises : les collaborateurs souhaitent pouvoir consulter leurs mails, leurs agendas, accéder à l'intranet de l'entreprise, etc. quel que soit le lieu géographique où ils se trouvent. De facto, les terminaux mobiles sont à la fois connectés à Internet et aux systèmes d'information des entreprises.

Partant de ce constat, il est évident que le smartphone (au sens large du terme) devient une cible pour un attaquant souhaitant s'introduire dans le système d'information d'une entreprise. Les processus de réponse à incident, lors d'une compromission de SI, doivent par conséquent prendre en compte ces « nouveaux » équipements.

Ils peuvent être différents selon que l'entreprise possède ou non une flotte professionnelle de smartphones et tablettes, et gère cette flotte avec une solution MDM (Mobile Device Management). Dans le cas où l'entreprise n'a pas atteint cette maturité, se pose alors le problème de l'hétérogénéité du parc, c'est-à-dire de la version du constructeur, du système d'exploitation et des applications installées. Ces problématiques sont accentuées lorsqu'il s'agit des terminaux Android.

Même si environ trois quarts des utilisateurs Android possèdent un terminal en version Jelly Bean (4.1.x, 4.2.x, 4.3.x) sortie seulement en juillet 2012, le quart restant peut posséder l'une de ces 4 versions d'OS : Froyo (2.2), Gingerbread (2.3.3 - 2.3.7), Ice Cream Sandwich (4.0.3 – 4.0.4), KitKat (4.4). Côté constructeur OEM, le monde Android est tout autant fragmenté. Il semblerait que Samsung détienne environ deux tiers des parts du marché, suivi par les 4 constructeurs que sont Motorola, Sony, HTC, LG qui se partagent globalement le reste du marché (même si nous n'avons pas cité Xiaomi qui est la marque de smartphone la plus vendue en Chine ou encore Wiko, société française).

Cet article tentera donc de décrire dans les grandes lignes, car quelques pages ne suffisent évidemment pas à être exhaustif, comment procéder à une analyse forensics sur système Android suite à une intrusion sur le SI de l'entreprise, que ce soit depuis un terminal isolé ou appartenant à une flotte professionnelle gérée par une solution MDM.

2. Contexte et objectifs

2.1 Contexte

De manière générale, une investigation informatique sur un support numérique doit suivre la logique générale suivante :

• accès au support ;
• acquisition des données ;
• analyse des données.

Sur un terminal Android, cette investigation peut s'avérer complexe puisqu'elle est fortement liée aux constructeurs (ou OEM), aux opérateurs de téléphonie mobile (les OEM et opérateurs peuvent s'associer pour ajouter au téléphone des briques logicielles opérateurs), à la version de l'OS Android et à sa configuration. Cette complexité se retrouve particulièrement au cours de l'étape d'acquisition des données.

Selon le contexte et l'environnement dans lequel l'analyste se retrouve, nous verrons dans la suite de l'article que l'obtention des privilèges root sur le téléphone peut s'avérer nécessaire. Un rappel sur la façon de procéder sera donc utile.

2.2 Objectifs

Les objectifs généraux d'une réponse à incident en cas de compromission sur un SI d'une entreprise sont clairs. Elle doit idéalement pouvoir répondre à l'ensemble de ces questions : comment l'attaquant s'est introduit, des portes dérobées ont-elles été déposées au sein du SI, y a-t-il eu exfiltration d'information et par quels moyens ?

Si nous nous mettons à la place d'un attaquant, la compromission d'un terminal Android va nous permettre certes de récupérer des informations intéressantes sur ce dernier, mais aussi et surtout de rebondir sur le SI de l'entreprise auquel est interconnecté le mobile. L'investigation d'un terminal Android doit donc se concentrer sur ce point : quelles informations présentes sur le téléphone ont pu être utilisées par l'attaquant pour s'introduire sur le SI et sur quel équipement a-t-il rebondi (un portail Web, un extranet, un store privé, etc.) ?

Bien qu'il y ait de meilleures solutions, un attaquant peut choisir d'utiliser le mobile Android pour revenir sur le SI compromis ou même pour exfiltrer de l'information. L'attaquant peut aussi vouloir géolocaliser de manière précise le mobile. La recherche d'éventuelles portes dérobées est donc nécessaire, qu'elles soient dans les applications Android de nature userland, kernelland ou tout en mémoire, cette dernière n'étant malgré tout pas très judicieuse (faible persistance à cause des problèmes de batterie).  

Enfin pour terminer, un attaquant peut aussi vouloir cibler une personne plutôt qu'une entreprise. La compromission du téléphone servira donc à récupérer les mails de l'utilisateur, ses appels et SMS. Cet aspect de l'analyse forensics n'est pas abordé dans le cadre de cet article, mais la recherche de portes dérobées peut aussi s'orienter dans ce sens.

3. Accès au terminal : conditions optimales

L'accès au terminal peut se faire de deux manières différentes : logique ou physique. Ce dernier nécessite un minimum de compétences techniques en électronique et dépend fortement du modèle constructeur (accès au port JTAG, dessoudage de la mémoire flash, etc.), il est donc peu réaliste de procéder à une telle démarche dans un cadre professionnel : absence de moyens, de compétences et faible réactivité. L'accès logique est donc privilégié.

Pour faciliter l'accès au terminal, le système Android possède une interface de debug sur USB nommée « Android Debug Bridge » qui permet plusieurs actions intéressantes dans le cadre d'une investigation informatique, comme la possibilité d'effectuer des sauvegardes, d'accéder à un shell ou encore de récupérer des fichiers.

Afin que cette interface soit opérationnelle, le mode debug USB du terminal doit être activé. C'est une option souvent non activée par défaut accessible uniquement une fois le terminal déverrouillé.

Par ailleurs, depuis Android 4.2.2, une protection a été implémentée pour éviter l’exécution de commande adb lorsque l’hôte n'est pas un hôte de confiance. Il est possible de réaliser cette action que si le terminal n'est plus verrouillé : une demande de confirmation apparaît sur le terminal.

Dans un contexte de réponse à incident, l'activation et l'utilisation d'adb sont non bloquantes puisque l'analyste est supposé pouvoir déverrouiller le terminal.

4. Acquisition des données

4.1 Acquisition de la carte SD

Si le terminal contient une carte SD, la première étape est de copier son contenu. L'acquisition (copie bit à bit) d'une carte SD est classique.

L'insertion d'une carte SD vierge dans le terminal permettra ensuite d'avoir un espace de stockage utile pour la suite de l'investigation.

4.2 Acquisition des informations natives

Plusieurs informations disponibles nativement sur le système et ne nécessitant aucun privilège particulier sont utiles à acquérir. Ces informations sont obtenues à l'aide de différentes commandes.

4.2.1 Les commandes classiques Linux

Plusieurs commandes Linux sont disponibles via adb sans même avoir besoin d'installer Busybox : ps, netstat, lsmod, dmesg, etc. Elles permettent d'établir un premier état des lieux :

4.2.2 Les commandes ADB

• getprop

Cette commande permet de lister les propriétés système du terminal :

• logcat

Logcat permet d’afficher les journaux d’événements en temps réel, les fichiers logs en question étant /dev/log/systemet/dev/log/main.

Les logs étant en temps réel, la commande logcat n'affiche qu'environ les 3 dernières heures d'activité du système.

• dumpsys

Cet autre utilitaire permet d'obtenir davantage de logs systèmes et applicatifs :

Parmi les modules intéressants :

4.3 Acquisition des données

La suite de l'investigation consiste à acquérir les données présentes sur le système Android, que ce soit les données systèmes, les configurations, les applications et leurs données, etc. À nouveau, selon la version d'Android, le constructeur, etc., différentes méthodologies se présentent.

4.3.1 Android 4 : Android Backup Manager

Depuis Android 4.0, une fonctionnalité permettant une sauvegarde du terminal a été mise en place, accessible par le client adb et la commande « adb backup ». Selon Google, cette fonctionnalité de sauvegarde est disponible pour près de 85% des terminaux. Sans avoir besoin de droits root, et c'est là tout l'intérêt, il est ainsi possible d’obtenir une sauvegarde du téléphone comprenant :

• les APK des applications ;
• les données de chaque application ;
• les applications systèmes ;
• les données présentes dans la carte SD.

Cependant, cette option d'adb est limitée puisque le contenu complet du terminal n'est pas récupéré. Pour effectuer la sauvegarde, la commande est la suivante :

Une fois cette commande réalisée, le système demande alors si vous souhaitez bien réaliser une sauvegarde et si vous souhaitez chiffrer celle-ci.  Il est donc nécessaire que le terminal ne soit pas verrouillé pour confirmer le lancement de la sauvegarde côté téléphone.

Le format de sauvegarde Android est une archive tar compressée avec un entête particulier, il est possible d'obtenir un fichier tar classique à l'aide de cette commande :

Des outils existent cependant pour regarder le contenu d'une sauvegarde comme par exemple ABE (Android Backup Extractor) [1].

4.3.2 Packages manager

Le système Android, et plus précisément le service Packages Manager, enregistre toutes les applications installées ainsi que les permissions correspondantes dans le fichier XML /data/system/packages.xml. Ce dernier n’est en revanche pas accessible si l’on ne détient pas les droits de l’utilisateur system ou supérieur.

Cependant, Android fournit le binaire /system/bin/pm permettant d’interroger le service afin d’obtenir un contenu formaté de toutes les informations qu’il contient.

Les commandes suivantes sont notamment intéressantes :

4.3.3 Acquisition des privilèges root

Il est possible que l'analyste arrive à une situation où il se trouve limité par les informations obtenues et ait besoin du niveau de privilèges root pour aller plus loin.

Le terminal Android peut par exemple être dans une version inférieure à 4.0 et ne dispose donc pas du service de backup permettant l’accès aux données des applications, ou bien il est nécessaire d'analyser le terminal dont le système lui-même a été compromis (rootkit) ou encore, il est nécessaire d'obtenir les potentielles données supprimées sur le système de fichiers.

La mise en place d’un accès root modifie l’état des données sur le téléphone et détruit certaines informations. Néanmoins un terminal mobile avec un accès root nous permet d’obtenir un accès complet, qu’il s’agisse des données utilisateur ou système.

4.3.3.1 Le bootloader

Le bootloader est la toute première chose qui s’exécute sur le terminal. À l’instar d’un BIOS, celui-ci se charge d’initialiser les différents composants matériels. Il charge ensuite le noyau en mémoire qui réalisera toutes les tâches nécessaires à l’exécution de la ROM et passera la main au processus init. Le bootloader est un programme développé par le fabricant et donc spécifique à chaque constructeur voire à chaque modèle.

4.3.3.2 Le mode Download

Le bootloader peut être également utilisé pour démarrer le terminal dans ce qui est appelé le Download Mode permettant alors de flasher l’appareil et modifier le firmware. Cette opération sera alors réalisée avec le protocole fastboot ou un autre protocole propriétaire tel que Odin en ce qui concerne la gamme Samsung par exemple ou SBF pour Motorola. Le programme fastboot permettant d’exploiter ce protocole est disponible dans le SDK Android. L’accès au Download Mode se fait généralement par une combinaison de touches particulière lors du boot.

Faisons un focus sur les terminaux Samsung puisque ce sont les plus répandus. Si aucun mécanisme de vérification de signature du noyau n'existe dans le bootloader, il est alors possible de profiter d'Odin [2], le logiciel de « recovery » de Samsung qui permet de flasher de nouveaux composants sur le terminal sans vérification préalable.

La mise à jour s'effectue via les outils Odin v3 ou Heimdall. Une mise à jour se présente sous la forme d'un  fichier zip contenant un script shell se faisant interpréter lors du flashage d'une ROM. Cette dernière représente elle-même la partition /system et des parties de la partition /data du téléphone. Lors de ce flashage, les partitions sont en lecture/écriture permettant alors de modifier le système interne du système d'exploitation Android. Le terminal est désormais rooté.

L'obtention des privilèges root sur un terminal Android passe donc par un reboot du terminal.

Il est évident que le flashage du terminal ainsi qu'un reboot ont une incidence pour une investigation à l'instar d'un reboot serveur ou poste de travail.

4.3.3.3 Le mode Recovery

De la même manière que pour le Download Mode, le bootloader peut également permettre d’accéder à un mode de récupération. Le mode de récupération d’Android est le mécanisme utilisé pour la mise en place des mises à jour sur le système sans effacer les données utilisateurs. Il consiste en fait en un noyau Linux minimal présent sur la partition /recovery.

Deux recovery alternatifs populaires et permettant de réaliser des sauvegardes d'un terminal sont TWRP et ClockWorkMod.

4.3.3.4 Les bootloaders verrouillés

Le bootloader est dit locked lorsqu’il inclut un mécanisme cryptographique empêchant le démarrage ou la modification du firmware par du code non signé. La plupart des terminaux Android ont un bootloader signé. Cependant, certains terminaux bon marché n’ont pas de bootloader bloqué et beaucoup de constructeurs permettent le déblocage du bootloader à travers le protocole fastboot et la commande :

Dans certains cas, le constructeur propose un portail web permettant le déblocage de l’appareil. C’est le cas des constructeurs HTC, Sony et Motorola. Dans la mesure où un bootloader débloqué permet la modification du firmware, il est alors possible de modifier l’image recovery ou le firmware pour s’octroyer un accès root et avoir un accès intégral aux données. Il est important d'avoir en tête que le modèle de sécurité du terminal repose sur le fait que le bootloader réalise cette vérification de l'image sur laquelle il démarre. Dès lors que le bootloader est débloqué, un attaquant peut alors obtenir toutes les données du terminal dans la mesure où celles-ci ne sont pas chiffrées. Pour cette raison, le déblocage du bootloader provoque une suppression des données utilisateur lorsque celui-ci est réalisé. En conséquence, le déblocage du terminal ne sera pas tenté au cours d'une réponse à incident au risque de perdre certaines informations.

4.3.3.5 Vulnérabilité noyau

Dans le cas où le bootloader n'est pas déverrouillé, il est toujours possible d'obtenir un accès root en exploitant une vulnérabilité du noyau (ou d'un démon Android). Des vulnérabilités ont été trouvées et rendues publiques par le passé, notamment dans le démon adb, dans le système de backup, dans le système de vérification des signatures de mise à jour ou encore dans la gestion des conteneurs sécurisés.

Une des dernières vulnérabilités noyau en date, qui exploite une faille dans l'appel système futex, n'a pas encore été patchée et rend facilement possible l'obtention du root à l'aide d'une application réalisée par George Hotz [3].

4.3.4 Acquisition complète

À partir de l'accès root, si l'on souhaite obtenir un dump des partitions, il est possible de procéder comme sous Linux.

La commande mount indique les points de montage et les devices utilisés. La liste des partitions par nom de device est obtenue par la commande suivante :

Et le dump d'une partition s'effectue bien évidemment avec la commande « dd » (en copiant sur la carte SD) :

Dans le cas où l'on souhaite réaliser un dump complet en se passant de l'utilisation d'une carte SD externe (tous les terminaux ne disposent pas d'un tel emplacement ou bien la carte SD n'est pas de taille suffisante), il est possible de réaliser une redirection TCP avec adb. Cette solution nécessite cependant d'avoir Busybox installé sur le terminal.

Puis dans un autre terminal sur l'hôte de l'analyste :

D'autres méthodes sont décrites sur le thread XDA suivant [12].

4.3.5 ADBFS

Une dernière solution pour faciliter l'acquisition est d'utiliser un système de fichiers Fuse comme adbfs [8] pour monter via ADB le système de fichiers du terminal et en faire une copie.

Cependant, cette solution est évidemment moins optimale que la précédente, puisqu'elle ne permet pas de faire une copie bit à bit du système de fichiers.

À noter que pour pouvoir parcourir le système de fichiers en tant que root (et accéder à des répertoires comme /data/data), il est nécessaire de mettre à jour les sources afin que chaque commande adb soit exécutée en tant que root grâce à la commande 'su -c'.

4.3.6 Acquisition de la mémoire vive

Les terminaux Android ont deux types de mémoire : la mémoire volatile (ou RAM) et la mémoire non volatile (flash NAND) servant au stockage des données (identique à un disque dur).

Cette étape de l'acquisition de données consiste donc à dumper la RAM du terminal. Plusieurs solutions sont possibles :

1. Avant la version 2.3 d'Android, l'envoi d'un signal SIGUSR1 (kill -10 PID) permettait le dump de processus au format hprof (les dumps étant enregistrés dans le répertoire /data/misc).

2. Après la version 2.3 d'Android, pour dumper la mémoire d'une application, il est possible de passer par DDMS (Dalvik Debug Monitor Server), soit fourni dans le SDK avec l'outil monitor (l'outil ddms étant obsolète), soit avec Eclipse ou encore en utilisant l'Activity Manager avec adb :

Seulement, pour pouvoir réaliser ce type d'action, il est nécessaire que l'application soit compilée en mode debug. Il est évident que dans le cadre d'une réponse à incident, cette condition limite fortement l'intérêt d'utiliser DDMS.

3. Une autre solution est d'utiliser l'API ptrace disponible sur Android avec les informations procfs pour déterminer les zones de mémoire allouées aux processus afin de les récupérer.

4. La dernière solution reste de dumper la totalité de la mémoire en utilisant le module noyau Lime. Un tutoriel complet est disponible sur la page Google Project de Volatility [5].

Dans le cas de terminaux Samsung, la protection Knox [6] peut être présente et activée. Cette technologie permet de :

• vérifier l'intégrité du firmware ;
• appliquer des règles SELinux sur les processus Android ;
• utiliser un système de TPM avec les instructions TIMA du processeur ARM ;
• cloisonner les processus.

Les binaires suid tels que su ne possèdent pas la permission CAP_SYS_SETUID, empêchant alors leur exécution en tant que root. De même, SELinux se met en « setenforce » dès le boot du téléphone. Il est alors impossible d'ajouter des capabilities à de nouveaux binaires après le boot.

Pour terminer, la protection Knox empêche le chargement de module noyau non vérifié. Elle vérifie régulièrement que le kernel n'a pas changé à partir des mesures obtenues auprès du kernel et en les comparant à celles du kernel d'usine d'origine. Elle authentifie les modules de kernel au fur et à mesure qu'ils sont chargés de façon dynamique.

Il est malgré tout possible de contourner Knox, car Odin ne restreint pas le flashage d'un nouveau noyau signé. Le /system peut donc être modifié afin d'ajouter des binaires ou de modifier des scripts de démarrage du mobile. Il est même possible de flasher un nouveau noyau n'appliquant pas les règles SELinux.

Mais à nouveau, utiliser Odin implique un reboot du terminal et réduit par conséquent l'intérêt d'acquérir la mémoire du terminal.

4.3.7 Déverrouillage des terminaux

Il est rare dans le cadre d'une réponse à incident que l'analyste ne puisse déverrouiller le terminal. Si malgré tout, il s'avère que ce ne soit pas le cas, différentes techniques existent selon que le terminal est rooté ou non.

Si le terminal est non rooté, l'attaque de Smudge [1] permet, si l'accès à la session du terminal est réalisé par un motif de déverrouillage, de reconstruire potentiellement le motif. Sur des versions anciennes d'Android, un chercheur a également mis en évidence la possibilité de débloquer l'accès au terminal en installant une application depuis le Google Play qui dispose de l'intent android.intent.action.PACKAGE_ADDED.

Si le terminal est rooté, il est possible de désactiver le verrouillage. Il existe en effet sous Android deux types de verrouillages, par schéma et par mot de passe. Les fichiers contenant le secret de ces verrouillages sont dans /data/system :

En vidant le contenu du fichier password.key, la protection par code PIN du terminal est supprimée. Il en est de même avec le fichier gesture.key si le verrouillage se fait par motif.

Le déverrouillage peut aussi être bloquant lorsque la version d'Android est supérieure à la version 4.2.2. Une protection a été implémentée pour éviter l’exécution de commande adb lorsque l’hôte n'est pas un hôte de confiance. Il est théoriquement possible de réaliser cette action que si le terminal n'est plus verrouillé. Cependant, une vulnérabilité a été mise en évidence permettant de réaliser cette opération depuis le menu d'appel d'urgence [3].

4.3.8 Cas particulier des téléphones chiffrés

La plupart des ROM Android ne fournissent pas d'accès au terminal chiffré tel qu'un escape shell lors de la demande de passphrase. Cependant, comme dans le cas des terminaux non-chiffrés il nous faut obtenir un accès au terminal. De la même manière, il est possible d'obtenir cet accès si le terminal est allumé et non verrouillé ou avec le démon adb actif. L'autre solution est de se servir d'un bootloader non verrouillé pour obtenir l'accès aux données chiffrées. Le blog de Sogeti Esec couvre le cas particulier du HTC One [4].

5. Analyse des données

5.1 Analyse de la mémoire

L'analyse de la mémoire permet de détecter des techniques de compromission tout en mémoire comme l'injection de code dans des processus ou la création de processus cachés. Elle permet dans l'absolu de récupérer des informations dynamiques non présentes sur le système de fichiers.

Android étant basé sur Linux, l'analyse de la mémoire peut être effectuée tout simplement avec Volatility sous réserve d'avoir le bon profil. La page AndroidMemoryForensics [4] décrit la procédure pour créer ce profil. Il y a ensuite suffisamment de publications sur Internet au sujet de Volatility pour extraire les informations souhaitées.

5.2 Analyse du système de fichiers

L'analyse du système de fichiers permet dans un premier temps d'établir une chronologie des accès MAC aux fichiers, de récupérer les fichiers effacés, et de détecter d'éventuelles portes dérobées. Cette timeline doit permettre de reproduire toute l'activité de l'attaquant sur le système.

Sur les dernières versions d'Android, les systèmes de fichiers sont au format YAFFS2 ou Ext4. Sur les versions plus anciennes, nous pouvions retrouver les systèmes YAFFS, Ext3 ou encore Vfat.

L'analyse du système de fichiers s'effectuera donc classiquement avec sleuthkit [10].

5.3 Analyse des applications

5.3.1 Données des applications

5.3.1.1 Les bases de données

Les applications stockent leurs données sous la forme de fichiers XML, de bases de données au format SQLite ou plus rarement, de fichiers texte à plat. Ces informations sont accessibles essentiellement dans le répertoire /data/data/<application>/databases/.

La multiplicité des constructeurs et des versions d'Android est tout autant impactante à ce stade. Par défaut, les plus intéressantes dans le cadre d'une réponse à incident pourraient être les suivantes (la liste étant non exhaustive) :

Cookies, Formulaires remplis	/data/data/com.android.browser/databases/webview.db
Cache des adresses parcourues	/data/data/com.android.browser/databases/webviewCache.db
Fichiers téléchargés	/data/data/com.android.providers.downloads/databases/downloads.db
Applications installées du market	/data/data/com.android.vending/databases/assets.db
Favoris/recherche browser	/data/data/com.android.browser/databases/browser.db
Fichiers téléchargés	/data/data/com.android.providers.downloads/databases/downloads.db

Un simple client sqlite3 suffit à analyser ces bases de données.

Pour illustrer un cas particulier, reprenons par exemple notre Samsung S4 avec Knox présent. Sur ce dernier, les données concernant l'historique du navigateur sont présentes essentiellement dans le fichier /data/data/com.sec.android.app.sbrowser/app_sbrowser/Default/History.

5.3.1.2 Les contentProviders

Les contentProviders, non évoqués jusqu'à maintenant, peuvent être tout aussi utiles que les bases de données pour obtenir des informations intéressantes dans le cadre d'une réponse à incident.

Un contentProvider sert à stocker et récupérer des données et ainsi les rendre accessibles à toutes les applications. C’est le moyen le plus connu de partager des données entre différentes applications. Ils sont généralement décrits dans le Manifest du package :

Un contentProvider se compose d’une URI et de méthodes (Insert, Update, Delete, Query). L'URI est de la forme :

adb peut permettre de les interroger et de récupérer les informations. Par exemple, pour obtenir l'historique du navigateur, la commande est la suivante :

5.3.2 Analyse du comportement des applications

Pour rappel, les applications sont de manière générale présentes dans les répertoires /data/app et /system/app. L'analyse d'applications Android est largement documentée sur Internet et les outils disponibles pour reverser les applications le sont tout autant :

• APKTOOL : https://code.google.com/p/android-apktool/ ;
• Androguard : http://androguard.blogspot.fr/ ;
• JEB : http://www.android-decompiler.com/ ;
• DroidBox : https://code.google.com/p/droidbox/.

L'analyse d'une application se décompose en deux phases :

1. Analyse statique :

• analyse du code binaire et traduction en code java, consultable depuis l’applicatif (utile aussi pour l’analyse de l’obfuscation du code) ;
• récupération des éventuels conteneurs de certificats pour fabrication de l’interception SSL (pour analyse dynamique ultérieure) ;
• analyse des fichiers temporaires stockés sur Android et notification lors de leur création, suppression, modification (pour analyse statique ultérieure) ;
• audit de code focalisé sur les classes dangereuses et vérification des permissions.

2. Analyse dynamique :

• récupération des journaux du téléphone ;
• récupération du contenu de la heap (la mémoire allouée dynamiquement lors de l’exécution du programme) pour faire de l’introspection sur son contenu ;
• écoute du trafic réseau en direction et depuis Internet ;
• usurpation du certificat client, écoute et réinjection par un proxy avec le certificat de l’application.

Il est important de ne pas négliger l'analyse réseau de l'application. Le comportement par défaut des solutions actuelles se concentrant trop sur l’analyse du code binaire et du comportement à l’intérieur du terminal.

6. Industrialisation

À plusieurs reprises a été évoquée la complexité de l'analyse forensics à cause des différents constructeurs et versions d'Android.

Dans le cadre d'une réponse à incident dans une entreprise, cette analyse peut être rendue plus simple et peut alors être industrialisée selon que cette entreprise est mature ou non au niveau de sa gestion de flotte mobile.

Si ce n'est pas le cas, elle sera alors contrainte à autant de procédures d'acquisition de données qu'il y a de terminaux et de versions d'Android différents utilisés par ses collaborateurs dans un cadre professionnel.

Si la société a pris au sérieux l'extension de son SI sur des terminaux mobiles en « imposant » un modèle de terminal et d'OS, des solutions automatisées d'investigation s'offrent alors à elle.

6.1 Homogénéité des terminaux

L'homogénéité des terminaux que ce soit au niveau du constructeur, de la version du système d'exploitation ou encore des applications installées, facilitera bien évidemment la définition de procédures et de méthodologies génériques d'investigation au sein de l'entreprise.

Cette homogénéité permettra à l'entreprise d'une part de définir un référentiel sur lequel se baseront les analyses forensics et d'autre part de développer et de maintenir ses propres outils d'analyse forensics.

6.2 Un mot sur les solutions MDM

Les solutions MDM (Mobile Device Management) sont de plus en plus présentes au sein des entreprises. MobileIron et Airwatch sont les plus connues. Elles ont pour objectif de pouvoir gérer la flotte professionnelle et d'assurer les fonctionnalités suivantes :

• accéder rapidement aux e-mails, agendas et contacts professionnels ;
• accéder automatiquement aux réseaux Wi-Fi et VPN de la société ;
• rechercher et installer facilement les applications professionnelles ;
• vérifier l'application des règles de sécurité de la société ;
• localiser les appareils perdus ou volés.

Même si ces solutions sont (censées ?) apporter une couche de sécurité supplémentaire, elles n'apportent malheureusement à notre connaissance aucune fonctionnalité utile à une réponse à incident. Elles ne permettent pas typiquement de créer une copie bit à bit de la mémoire ou du stockage, ou encore d'exécuter des commandes à distance sur les terminaux.

6.3 Automatisation des acquisitions et des analyses

L'automatisation de l'acquisition et de l'analyse des mobiles est multiple :

• elle permet de s'assurer que les méthodologies sont identiques quel que soit le téléphone concerné ;
• elle est nécessaire quand le nombre de mobiles à analyser est conséquent (dans un contexte d'entreprise) ;
• elle facilite la mise à jour des méthodologies et processus d'analyse.

6.3.1 Acquisition des données

La majorité des données système acquises le sont à travers adb. Il est donc assez simple de développer à minima des scripts pour acquérir automatiquement d'une part les logs et d'autre part l'environnement à investiguer (la liste des packages, leur configuration et celle de l'OS, etc.) et de comparer avec un référentiel défini au départ basé sur un « master ».

6.3.2 Analyse des applications

L'analyse des applications au sein du téléphone peut s'avérer fastidieuse de par le nombre conséquent d'applications à analyser et des techniques de compromission possibles (l'application Android est en effet le principal vecteur d'attaque). L'industrialisation de l'analyse des applications est donc primordiale. Elle doit permettre l'analyse statique et dynamique d'une application définie précédemment.

Afin d'atteindre ces objectifs, nous pouvons imaginer une solution composée de plusieurs briques logicielles qu'il est ensuite possible de « scripter » pour automatiser les différentes phases d'analyse.

La première brique logicielle concerne l'émulateur Android de Google fourni avec le SDK comportant une ROM avec accès root et les outils d'analyses forensics nécessaires. Il a pour objectif de simuler le téléphone utilisateur. Il permet entre autres de répondre à différentes contraintes techniques telles que le routage des flux réseaux et l’installation ou contrôle automatique d’applications Android.

Un agent se charge ensuite de la surveillance de l’application à analyser sur le téléphone. Il peut être développé en C avec le NDK, le SDK natif de Google. Cet agent se connecte au système par l’intermédiaire d'adb. Plusieurs techniques sont ensuite possibles pour surveiller l'application :

• l’API ptrace avec les informations du procfs pour déterminer les zones de mémoire allouées par l’application afin de les récupérer ;
• l’API inotify pour surveiller le système de fichiers et connaître l’évolution des accès MAC aux fichiers ;
• un système de hooks directement basé sur LD_PRELOAD (plutôt que la librairie bionic qui a parfois un comportement anormal) pour surveiller davantage que la gestion de la mémoire et les accès aux fichiers.

Si la ROM est contrôlée, une dernière solution est d'activer le mode debug et d'utiliser le protocole JDWP pour debugger directement la partie Java des applications.

Un proxy, situé en dehors de l’émulateur Android, s'ajoute au reste de notre solution. Il a pour objectif d'écouter tout le trafic de l’application Android vers et depuis Internet. Il est également contrôlable depuis le référentiel pour la mise en coupure des requêtes de l’applicatif ou simplement pour le « rejeu » de requêtes.

La dernière brique logicielle concerne le référentiel. Il est la pièce maîtresse de la solution et permet de contrôler les différents éléments de l’application, l’émulateur, l’agent et le proxy. C'est au travers de ce référentiel que sont effectuées toutes les analyses forensics nécessaires :

• il propose une vue de l’application Android avec le code source régénéré avec Androguard et permet de faire des recherches dans le code généré ainsi que ses ressources texte.
• il permet également de modifier des éléments au sein de l’application, de la « re-signer » et de la réinstaller comme par exemple changer une clef RSA pour fausser les vérifications de signature.
• il permet de récupérer les éléments de l’agent tels que les noms de fichiers modifiés avec leur contenu et le log de l’émulateur, la mémoire du process, etc. Couplé avec la recherche intégrée du code régénéré d’Androguard, ce dispositif est utile pour identifier les éléments qui génèrent les traces observées.

Ce référentiel a donc le contrôle total de l’émulateur via adb et l’agent. Il contrôle également le proxy afin qu'il puisse agir comme proxy passif ou actif à la manière de spike ou burp proxy. Il permet également la consultation des requêtes relayées par le proxy.

La mise en place d'une telle solution peut paraître complexe, mais la fréquence et la quantité des applications à analyser au sein d'une entreprise l'impose. Bien entendu, la solution proposée en est une parmi tant d'autres. Il a d'ailleurs été présenté au SSTIC 2014 la solution Hooker [13], une solution d'analyse automatisée de markets Android, preuve que nous sommes sur la bonne voie :)

Conclusion

Bien qu'un seul article ne suffise pas à traiter la problématique de réponse à incident sur Android, nous avons néanmoins abordé « succinctement » les différentes techniques d'acquisition selon les constructeurs et l'environnement à acquérir. Le sujet de l'industrialisation mériterait l'écriture d'un article à lui tout seul et il est évident, de par la diversité des terminaux et du faible outillage existant, que le sujet de la réponse à incident sur Android, et sur mobile de manière générale, est un sujet complexe qui n'en est qu'à ses débuts.

Références

[1] ABE : https://github.com/nelenkov/android-backup-extractor

[2] ODIN : http://odindownload.com/

[3] TOWELROOT : https://towelroot.com/

[4] LIME : http://code.google.com/p/volatility/wiki/AndroidMemoryForensics#Load_the_LiME_LKM_on_the_Android_Device

[5] KNOX : http://www.samsung.com/fr/business/solutions-services/mobile-solutions/security/samsung-knox

[6] ADBFS : https://github.com/spion/adbfs-rootless

[7] SMUDGE : http://en.wikipedia.org/wiki/Smudge_attack

[8] URGENCE : https://labs.mwrinfosecurity.com/advisories/2014/07/03/android-4-4-2-secure-usb-debugging-bypass/

[9] HTC One bootloader : http://esec-lab.sogeti.com/post/Exploiting-a-vulnerability-in-HTC-One-bootloader-and-bruteforcing-the-PIN-password

[10] VOLATILITY : http://code.google.com/p/volatility/

[11] SLEUTHKIT : http://www.sleuthkit.org/

[12] XDA : http://forum.xda-developers.com/showthread.php?t=1818321