Recherche d'indices de compromission sur iOS

1. Architecture en bref

Afin de donner au lecteur tous les éléments nécessaires à la compréhension des contraintes liées à la réalisation d’une investigation numérique sur un terminal Apple, ce chapitre présente succinctement l’architecture d’un système iOS.

1.1 Architecture & SoC applicatif

L’architecture matérielle des terminaux Apple repose principalement sur leur SoC (System on Chip). Ce SoC, qualifié à tort de processeur, ne cesse d’évoluer au rythme des versions des terminaux. Parmi les fonctionnalités les plus importantes de ce système intégré, il faut noter la présence d’un coprocesseur cryptographique utilisé pour les opérations de chiffrement et de déchiffrement des données stockées sur la mémoire NAND (flash). Ce cryptoprocesseur étant placé en coupure entre la mémoire RAM et la NAND, tout échange de données entre lui et la RAM est chiffré. Autre point important, le cryptoprocesseur renferme deux clés de chiffrement (les clés sont gravées dans le silicium du SoC) :

- la clé GID, propre à chaque famille d’équipements, permet de déchiffrer le contenu des éléments composant les images de mise à jour ;

- la clé UID, propre à chaque terminal, est utilisée pour le chiffrement du système et des fichiers sur le terminal.

1.2 Mécanismes de sécurité

Apple s’attache à réduire la surface d’attaque de ses équipements à chaque nouvelle version (matérielle et logicielle). Ainsi, un grand nombre de mécanismes de sécurité a été intégré au système. Parmi les plus importants, il faut noter la chaîne de démarrage de confiance basée sur l’implantation d’une racine de confiance dans une mémoire non réinscriptible de type ROM (BootROM), les fonctionnalités de protection des données utilisateur et les fonctionnalités permettant de garantir l’intégrité du système en fonctionnement. Cette dernière fonctionnalité intègre notamment des mécanismes :

- de restriction des privilèges ;

- de signature de code et de contrôle d’intégrité des binaires ;

- d’isolation des applications ;

- de restriction de l’exécution de code malveillant :

Ces différents mécanismes de sécurité s’appliquent à toutes les applications iOS, y compris aux outils d’investigation numérique. Ceci confère aux analyses d’un terminal Apple une grande complexité.

1.3 Protection des données

Afin d’interdire toute modification du système d'exploitation, Apple a choisi d'organiser le système de fichiers en deux partitions. La première partition HFS+ appelée « partition SYSTEM » par la suite, montée en lecture seule sur un système intègre, est utilisée pour stocker les données du système. Elle contient notamment le kernelcache (noyau du système et ses extensions), ainsi que l'ensemble des services, programmes et bibliothèques nécessaires au fonctionnement d’iOS.

La seconde partition HFS+, appelée « partition DATA » dans la suite de cet article, est réservée pour le stockage des données utilisateur. Celle-ci est donc accessible en lecture et écriture. Elle contient notamment l'ensemble des applications, leurs préférences et les données associées.

Comme la plupart des systèmes embarqués, ces partitions sont stockées sur la mémoire flash NAND du terminal, intégralement chiffrée avec une clé de volume. Celle-ci est elle-même chiffrée à l’aide d’une clé de chiffrement qui n’existe qu’en mémoire noyau et provenant d'une dérivation de la clé UID. Il est donc nécessaire d'avoir accès au processeur cryptographique pour pouvoir obtenir la clé de volume. Cette implémentation garantit la confidentialité des données lorsque l’équipement est hors tension et rend inutile toute extraction physique des données (démontage et lecture de la mémoire flash).

En ayant connaissance de la clé de volume, il est possible d’accéder au contenu des deux partitions. Toutefois, dans le but de restreindre l’accès aux fichiers de l’utilisateur et du système lors du fonctionnement, Apple a mis en place différentes couches de chiffrement additionnelles auxquelles sont associées différentes classes de protection. Il est donc nécessaire d'obtenir les clés de chiffrement associées à chacune de ces classes pour extraire les données de chacune des partitions.

Plus d’explications concernant les moyens complexes de chiffrement mis en œuvre par Apple sont disponibles dans les actes du [SSTIC 2012].

2. Acquisition

L’acquisition de données est l’étape préalable à toute investigation numérique. Sur un terminal iOS, cette étape peut se révéler complexe du fait des limitations imposées par le système. Ce chapitre présente les différentes méthodes permettant l’extraction des données du terminal Apple. Le lecteur intéressé est invité à consulter l’article intitulé Investigation numérique & terminaux Apple iOS : Acquisition de données présenté lors de la conférence [SSTIC 2014].

2.1 Précautions d’usage

Afin d’éviter toute communication avec l'environnement extérieur, il est recommandé de démarrer le terminal dans un environnement hors de portée de tout réseau mobile. Si l’analyste a accès à une cage de Faraday (ou un sac d'isolation électromagnétique), le terminal peut y être démarré dans le but d'identifier la version exacte du système installé (Réglages > Général > Informations > Version) et de réaliser les opérations d’acquisition.

2.2 Acquisition physique

Contrairement à l’acquisition logique, l’acquisition physique de données repose sur l’accès direct aux données, sans lancer la séquence de démarrage du terminal, autrement dit sans interaction avec le système d’exploitation. Or, comme précédemment évoqué, l’intégralité des données stockées sur la mémoire flash d'un terminal Apple est chiffrée. Sans connaissance des clefs de chiffrement protégeant ces données, il est inutile de procéder à l’acquisition physique.

Publié en 2010 par George Hotzk alias GeoHot, le code d'exploitation [LIMERA1N] permet de démarrer un système alternatif personnalisé en exploitant une vulnérabilité dans le code immuable du BootROM des terminaux iPhone 2G/3G/3Gs/4 et iPad 1.

À partir de ces travaux, les chercheurs de la société « Sogeti ESEC » ont développé et mis à disposition une suite d’outils [DATA-PROTECTION] permettant de créer et de démarrer un système alternatif sur un terminal vulnérable. Cette technique est également utilisée par le boîtier d’acquisition [UFED]. Ainsi, depuis le système alternatif, il devient possible de réaliser une image brute (copie bit à bit) du contenu de la mémoire flash. Cette opération peut être réalisée à l'aide du script dump_data_partition.sh (à modifier pour extraire la partition SYSTEM).

Alors que l'image de la partition SYSTEM extraite n'est plus chiffrée (déchiffrement au démarrage du terminal), celle de la partition DATA (format .dmg) doit être déchiffrée pour être exploitable. Le script emf_decrypter.py permet de réaliser cette opération en se basant notamment sur les clés dérivées de la clé UID et le trousseau d'accès (Keychain) précédemment extraits (via dump_data_partition.sh).

Le montage des partitions se réalise de la manière suivante (sous Mac OS X) :

Les données de la partition DATA (accessible via /private/var/ sur un terminal démarré) sont alors accessibles :

Ainsi que celles de la partition SYSTEM :

2.3 Acquisition logique

À la date de rédaction de cet article (juillet 2014), aucune vulnérabilité publique n’affecte la chaîne de démarrage des terminaux 4s et supérieurs. Il est donc nécessaire d’avoir recours à d’autres méthodes d'acquisition de données. Ainsi deux techniques d'acquisition logique ont été présentées lors de l’édition 2014 de la conférence SSTIC [SSTIC 2014] par l'un des auteurs de cet article.

2.3.1. Acquisition logique sans altération du système

Il est possible d’extraire un grand nombre d’informations sans altération du système (sans Jailbreak) en s'appuyant sur les services normalement utilisés par les outils Apple (iTunes, par exemple).

2.3.1.1 Principaux services connus pour extraire des données système

La bibliothèque [LIBIMOBILEDEVICE], qui implémente les différents protocoles nécessaires à l’utilisation des services accessibles (liste disponible dans /System/Library/Lockdown/Services.plist), permet d’extraire des données pertinentes dans le cadre d’une investigation numérique :

- [IDEVICEINFO] utilise le service com.apple.mobile.lockdown pour obtenir les informations sur le terminal (adresses MAC, version du système, du Baseband, du matériel, etc.) ;

- [IDEVICEDATE] permet la récupération de l’heure courante sur le terminal et donc la timezone ;

- [IDEVICEINSTALLER], basé sur le service com.apple.mobile.installation_proxy, permet entre autres de récupérer la liste des applications installées ainsi que leurs identifiants ;

- [IFUSE] utilise différents services : com.apple.afc, com.apple.afc2 et com.apple.mobile.house_arrest. Cet outil permet d’accéder au contenu du répertoire /var/mobile/Media. ifuse permet également d’obtenir le contenu du répertoire d’une application tierce en spécifiant les paramètres « --documents  APPID » (récupération des documents de l’application correspondante à l’identifiant spécifié) et « --container APPID » (récupération des fichiers des applications). En utilisant l’option « --root » il devient possible d’accéder à l’intégralité du système d’un terminal jailbreaké sur lequel le service com.apple.afc2 est installé ;

- [IDEVICEPROVISION] permet d’obtenir la liste des profils de développement installés sur le terminal via le service com.apple.misagent ;

- [IDEVICESYSLOG] utilise le service com.apple.syslog_relay et permet d’obtenir en temps réel les journaux du terminal ;

- [IDEVICECRASHREPORT] s'appuie sur le service com.apple.crashreportmover et autorise la récupération des rapports d’erreur ;

- [IDEVICEBACKUP] & [IDEVICEBACKUP2] utilisent les services com.apple.mobile.backup et com.apple.mobile.backup2, respectivement en charge de la sauvegarde et de la restauration du contenu du terminal. Une sauvegarde iTunes de terminal Apple contient les données suivantes :

Dans le cadre d’une recherche de marqueurs de compromission, les données extraites à travers ce type de sauvegarde n’ont pas de réel intérêt. En effet, des données pertinentes telles que les moyens de persistance (services, agents, etc.), les binaires des applications, les fichiers de journalisation ou les fichiers spéciaux ne sont pas accessibles. De plus, les dates des fichiers de la sauvegarde iTunes ne sont pas conservées et il n’est donc pas possible de générer une ligne de temps.

2.3.1.2 Service com.apple.mobile.file_relay

Du point de vue d'une investigation numérique, le service com.apple.mobile.file_relay est la meilleure source d'information. En effet, ce service est dédié à l'extraction d'informations. Les premières versions d'iOS supportent un nombre limité de sources de données, notamment:

- SystemConfiguration : permet d'obtenir la liste des SSID des réseaux Wi-Fi connus et la dernière fois qu'ils ont été rejoints ainsi que divers paramètres de configuration comprenant la configuration des interfaces réseau. Ces informations peuvent potentiellement être utilisées pour identifier le lieu d'une compromission ;

- UserDatabases : bases de données utilisateur (SMS, contacts...) ;

- CrashReporter : rapports d'erreurs ;

- Caches : liste détaillée des applications présentes sur le système et des variables d'environnement pour chacune des applications, etc. ;

- Tmp : contenu du répertoire /tmp.

Les nouvelles versions d'iOS supportent un plus grand nombre de sources de données.

Parmi ces nouvelles sources de données, il faut souligner la source HFSMeta, qui permet de télécharger une image complète des métadonnées HFS+ enregistrées sur la mémoire flash de l'appareil (depuis iOS7). L'image ainsi extraite contient toutes les informations relatives aux fichiers stockés sur le système (horodatage, noms des fichiers, taille, etc.). Cette source d'information vise à remplacer la source VARFS qui contenait un système de fichiers virtuel au format statvfs.

La source de données Lockdown permet d'obtenir une copie des informations générées lors de l'appairage (certificat/escrowbag). Elles peuvent être utilisées pour déterminer la liste des équipements sur lesquels le terminal a été synchronisé ou appairé. L'archive obtenue contient également une copie des informations générées lors de l’enregistrement et de l'activation du terminal. Ces données peuvent être utilisées pour déterminer le moment où le dispositif a été activé ou restauré pour la dernière fois. Les informations obtenues permettent également de déterminer d'autres paramètres de l'appareil tels que l'état des fonctionnalités de développement, de chiffrement des sauvegardes, le nom du périphérique, le fuseau horaire configuré, le nom d'hôte et l'OS du dernier équipement sur lequel le terminal a été synchronisé/sauvegardé, etc.

Enfin, la source MobileInstallation permet de télécharger le fichier com.mobile.installation.plist dans lequel sont stockés les paramètres de lancement de chacune des applications installées sur le terminal.

La bibliothèque pymobiledevice mise à disposition sur le GitHub [IOSFORENSICS] intègre un exemple d'utilisation de ce service en python : file_relay.py.

2.3.1.3 Service réseau com.apple.pcapd

L’analyse du trafic réseau (hors SMS, MMS et voix) peut être utile lors de l’analyse d’un programme malveillant. L’utilisation du service com.apple.pcapd peut répondre à ce besoin sans nécessiter la mise en place d’outillage complexe. En effet, ce service, présent à partir de la version 5 d’iOS, permet la création d’une interface TAP virtuelle sur l’équipement. Le trafic réseau est alors recopié vers le poste d’analyse. Sous Mac OS X, il est possible d’accéder à ce service à l’aide de la commande : rvcictl.

La bibliothèque pymobiledevice [IOSFORENSICS] intègre également un exemple d'utilisation de ce service : pcapd.py.

2.3.2 Acquisition logique avec altération du système

La technique d’acquisition présentée dans le chapitre précédent n'autorise pas l’accès aux fichiers composant le système. Il est donc nécessaire d'utiliser des techniques de Jailbreak afin de déverrouiller le service com.apple.afc et d’exposer l’intégralité du système de fichiers. Le système est toutefois altéré, car l’utilisation des techniques de Jailbreak implique la modification du système de fichiers. Tous les détails techniques concernant cette technique ont été présentés lors de [SSTIC 2014].

Cette méthode d’acquisition permet au final d’obtenir une archive du système de fichiers monté sur un terminal en cours de fonctionnement, ce qui est différent d’une image brute des partitions DATA et SYSTEM obtenue lors d’une acquisition physique.

Les principaux inconvénients d’une telle méthode par rapport à une acquisition physique sont les suivants :

- pas d'accès aux informations HFS+ :

- carving impossible sur les clusters non alloués.

L’avantage en revanche est que les fichiers du système sont lisibles sans aucune opération de déchiffrement.

3. Analyse

L’analyse des fichiers présents sur le système permet d’identifier la présence de contenu malveillant (traces de Jailbreak, documents ou exécutables exploitant une vulnérabilité d’un logiciel tiers, etc.).

3.1 Analyse comparative

Cette méthode d'analyse s'appuie généralement sur un ou plusieurs référentiels de fichiers connus et apporte un temps de gain considérable en identifiant les fichiers présents par défaut sur le terminal.

Ainsi, les analyses comparatives présentées dans les chapitres suivants respectent les étapes ci-dessous :

- comparaison de la liste des noms de fichiers :

- comparaison automatique ou analyse dite par condensat approximatif (fuzzy hashing) du contenu des fichiers. Ce type d'analyse permet d'identifier le taux de similitude entre deux fichiers et permet d'identifier les fichiers créés ou modifiés. Un outil tel que [BINWALLY] est assez performant pour réaliser ce type d'opération ;

- analyse manuelle des fichiers ajoutés ou altérés, en analysant en priorité ceux créés ou modifiés durant la période de potentielle compromission communiquée par la victime.

3.2 Analyse bas niveau - HFS+

3.2.1 Constitution d’une ligne de temps

Cette opération permet d'obtenir une image de l’activité du système à un instant précis et à travers le système de fichiers HFS+.

3.2.1.1 Le fichier $catalogFile

Le fichier spécial $catalogFile du système de fichiers HFS+ (utilisé pour les partitions DATA et SYSTEM) contient les métadonnées de chaque fichier et répertoire du terminal (date de création, de dernier accès, de dernière modification, de modification des métadonnées, de sauvegarde), sous la forme de structures HFSPlusCatalogFile/HFSPlusCatalogFolder [$CATALOGFILE].

L'emplacement et la taille du $catalogFile sont facilement identifiables puisqu'ils sont indiqués dans l'entête du volume HFS+ (1024 octets à partir de l'offset 0x400), au sein d'une structure HFSPlusDataFork (généralement à l'offset 0x110 de l'entête). Son extraction est donc triviale.

3.2.1.2 Deux types d'image HFS+

À partir des images physiques HFS+ des partitions DATA/SYSTEM obtenues par une acquisition physique, l'entête du volume HFS+ et le $catalogFile sont facilement identifiables et ne posent pas de difficulté.

Sur un terminal démarré (non jailbreaké), une image disque HFS+ au format « Sparsebundle » peut être extraite suite à l'interrogation du service com.apple.mobile.file_relay (et la source de données HFSmeta présentée plus haut). Celle-ci contient l’arborescence du système de fichiers monté mais sans le contenu. Le format de l'image extraite (HFS+) permet par contre de stocker le $catalogFile qui peut ainsi être extrait.

3.2.1.3 Génération d'une ligne de temps

En plus de supporter l'identification et l'extraction du $catalogFile (fls, icat), la suite d'outils [SLEUTHKIT] propose des options pour générer automatiquement une ligne de temps au format mactime depuis une image HFS+ (les deux types d'image étant supportés) :

Mactime (Sleuthkit) permet alors de formater les dates et trier les enregistrements :

3.2.2 Identification des fichiers effacés, de leur activité et restauration

Les modifications récentes effectuées sur un fichier peuvent être identifiées à travers le fichier spécial $journalFile (qui utilise partiellement la structure HFSPlusCatalogFile et dont l'emplacement est indiqué à l'offset 0xC de l'entête du volume). En effet, celui-ci contient les données nécessaires au système pour qu’il soit en mesure de restaurer son état suite à un arrêt soudain. Par exemple, si un fichier est créé, modifié, accédé et enfin supprimé, chacune de ces actions entraînera l’ajout d’une nouvelle entrée dans $journalFile. Il y aura donc encore des traces de la présence du fichier dans $journalFile contrairement à $catalogFile qui efface ses entrées lorsque les fichiers sont effacés. Toutefois, toutes les transactions ne sont pas enregistrées, $journalFile étant limité en taille (8Mo). L’article [HFSJOURNALPARSER] propose une méthode d’analyse pertinente de ces deux fichiers.

En plus d’identifier les fichiers supprimés, il est pertinent d’analyser le fichier $journalFile pour identifier les derniers fichiers modifiés. Un programme malveillant, s’il manipule régulièrement des fichiers ou programmes, impactera les entrées de $journalFile et pourra donc être rapidement détecté par ce biais.

En matière d’outillage, l’outil gratuit [AHJP] (Advanced HFS+ Journal Parser) se basant sur les deux fichiers spéciaux $catalogFile et $journalFile est assez efficace.

Cette opération nécessite toutefois un accès root sur le terminal ou l'obtention d'une image physique.

En ce qui concerne la restauration des fichiers effacés, Sleuthkit ne supportant pas l'attribut HFS+ cprotect relatif aux classes de protection de chacun des fichiers du terminal, il est nécessaire d'utiliser une alternative. Les chercheurs de « Sogeti ESEC » ont également travaillé sur ce sujet complexe et proposent un script, emf_undelete.py, permettant le carving de la mémoire NAND [LOWLEVEL_IOS] dans le but d’identifier les fichiers effacés et de tenter leur restauration.

3.3 Analyse de l'arborescence des fichiers

Cette opération peut être réalisée aussi bien à partir d’une image physique que d’une image logique (archive du système de fichiers).

3.3.1 Constitution d’une ligne de temps

Lorsque la date de dernière modification a été conservée pour chacun des fichiers, il est possible de générer une ligne de temps basée sur ce type de date. La commande tree permet par exemple d’effectuer cette opération en proposant un format de sortie aisément exploitable pour être trié par date :

3.3.2 Analyse différentielle du système de fichiers racine

Il s’agit ici de vérifier si les fichiers constituant le système racine sont intègres et n'ont pas subi de modification malveillante révélatrice d’une compromission. Pour cela, il est nécessaire d’obtenir une image de référence à comparer avec l'image du terminal à analyser. Il existe deux méthodes pour obtenir cette image :

- Depuis une image Firmware IPSW : celle-ci contient les briques de démarrage du système (iBoot, LLB, iBEC, KernelCache, ...) ainsi que le système de fichiers racine (Root File System) HFS+. Ce dernier, stocké sous la forme d'une image DMG, contient donc les fichiers installés initialement sur le terminal qui peuvent donc être utilisés comme références. L'image DMG est chiffrée par une clé de chiffrement dérivée de la clé GID (propre à chaque famille d’équipement). La clé GID étant uniquement accessible par le processeur cryptographique lors du démarrage du système, il est nécessaire d'avoir recours à l’exploitation d’une vulnérabilité dans la chaîne de démarrage pour en assurer l’extraction. Pour chaque terminal affecté par ce type de vulnérabilité, la communauté Jailbreak a mis en place sur l’[IPHONEWIKI] une page centralisant les clés de déchiffrement. L'outil [VFDECRYPT] permet notamment le déchiffrement de l'image DMG à partir de la clef de déchiffrement pour permettre par la suite son montage et donc son exploration :

- En activant temporairement une copie du service com.apple.afc : celle-ci, non soumise aux restrictions imposées par le système, permet d’acquérir l’intégralité des données stockées sur la mémoire flash d'un terminal de référence. Cette méthode d'acquisition, qui utilise les techniques de Jailbreak [P0SIXPWN] [EVASI0N], a fait l'objet d'un article complet au [SSTIC 2014]. Cette technique pourrait être adaptée aux versions 7.1.1 et 7.1.2 en réalisant l'étude du dernier Jailbreak en date [PANGU].

Ces données de référence permettent alors d’identifier la modification partielle ou complète des fichiers via une analyse comparative (comparaison des noms de fichiers, du contenu, fuzzy hashing, etc.).

3.3.3 Cache noyau (kernelcache)

Sur un système iOS, l'image du kernel (kernelcache) se trouve à l'emplacement : /System/Library/Caches/com.apple.kernelcaches/kernelcache. Ce fichier contient le noyau XNU et ses différents modules et extensions (format .kext). L'image du noyau est également incluse dans chacune des images du firmware iOS (fichiers IPSW), sous la forme d'un fichier au format .img3 chiffré. De par la nature sensible de cet élément, il est essentiel de vérifier son intégrité par exemple en le comparant à une image de référence.

Comme pour le système de fichiers racine (voir 3.3.2), le kernelcache d'origine est disponible, pour les versions des terminaux vulnérables, sur l’[IPHONEWIKI], accompagné de ses clefs de déchiffrement. Il peut donc être utilisé comme référence. Le déchiffrement du kernelcache, suivi de la décompression peuvent être réalisés automatiquement via [KCACHE] :

La suite d'outils [XPWNTOOL] et [LZSSDEC] peut également être utilisée pour réaliser cette opération.

Les deux kernelcache obtenus au format exécutable Mach-O (ARM) peuvent alors être comparés aisément via leur condensat (ex. : SHA256). Si ces derniers s'avèrent être différents, une investigation plus poussée doit être menée pour identifier les modifications apportées. La taille du kernelcache étant d'une dizaine de Mo, l'analyser avec un désassembleur est fastidieux et complexe. Il est donc préférable, dans un premier temps, de comparer les codes avec des outils plus adaptés tels que [BINDIFF] (comparaison du code désassemblé) et [JOKER] (extraction complète de la table des appels système, de l'emplacement et du nom des extensions noyau).

3.4 Analyse des programmes persistants

3.4.1 Services ou agents lancés au démarrage

L’analyse des services et des agents permet d’identifier les programmes lancés en tâche de fond au démarrage, avec les droits utilisateur ou root. Leur configuration, au format .plist, est notamment stockée dans les répertoires suivants :

- agents : /Library/LaunchAgents ;

- services : /System/Library/LaunchDaemons.

Le contenu des fichiers .plist permet d’identifier l’exécutable principal ainsi que les paramètres de lancement. Généralement, l’analyse comparative (voir 3.1) permet de restreindre efficacement l’analyse manuelle à quelques fichiers. Il s’agit ensuite d’effectuer la levée de doute en analysant directement le binaire (voir chapitre suivant pour l’analyse des Mach-O).

3.4.2 Extensions noyau

L’analyse des extensions noyau installées (équivalent aux drivers), autres que celles présentes par défaut sur un système (à travers le kernelcache), permet d’identifier les programmes spécifiques pouvant être lancés au niveau de la couche noyau et au démarrage du terminal. Elles sont notamment installées à deux emplacements :

- Extensions System : /System/Library/Extensions/ ;

- Extensions Library : /Library/Extensions/.

Ces dossiers peuvent contenir directement les exécutables, des fichiers Info.plist, des plug-ins, etc.

Encore une fois, l’analyse comparative (voir 3.1) permet d’identifier si des extensions autres que celles par défaut ont été installées.

3.4.3 Autres moyens de persistance

D’autres moyens sont couramment employés pour permettre la persistance d’un programme au démarrage notamment :

- Overrides.plist : fichier de configuration utilisé par le gestionnaire de services « launchd » pour charger/décharger des services ou agents via l’application launchctl. Ils sont stockés dans plusieurs dossiers selon les droits d’exécution (/private/var/db/launchd.db/com.apple.launchd*/overrides.plist) ;

- XPC Services : services utilisés pour la communication entre processus (généralement pour l’authentification partagée) et identifiables dans des dossiers XPCServices de /System/Library/ ;

- Launchd.conf (situé dans /private/etc/) : fichier permettant l'exécution de commandes à travers Launchctl (jusqu'à iOS 6 inclus). Le Jailbreak « Evasi0n » utilise cette technique de persistance [ACCUVANT] ;

- com.apple.mobile.installation.plist (situé dans /private/var/mobile/Library/Caches) : fichier permettant d’identifier les différentes variables d'environnement exportées lors du lancement des applications installées sur le système. Ce fichier étant modifié par diverses versions de Jailbreak, il est important d’y consacrer une partie du temps alloué à l’analyse ;

- Info.plist : fichier de configuration de chaque application indiquant le chemin de l'exécutable et qui, modifié, peut permettre le lancement d'une application tierce à la place de celle par défaut.

3.5 Analyse des exécutables

3.5.1 Identification des Applications installées

Comme précédemment évoqué, le service com.apple.mobile.installation_proxy (exploitable via l’outil ideviceinstaller par exemple) permet d’identifier les applications installées sur l’équipement.

Si le système de fichiers a pu être extrait lors de l’acquisition, il est préférable d’identifier manuellement (donc sans passer par les API d’Apple) les applications installées. Les répertoires courants utilisés pour l’installation des applications d’un terminal iOS sont les suivants :

- /Applications/MonAppli.app : répertoire des applications installées par défaut par Apple (non chiffrées) ;

- /private/var/mobile/Applications/UID/MonAppli.app : répertoire contenant les applications installées. Ce répertoire contient aussi bien les applications provenant de l’Apple Store dont les exécutables sont protégés par le DRM Fairplay (applications chiffrées) que les applications fournies par un développeur ou une entreprise qui n’embarquent aucun DRM Apple ;

- /Developer/Applications/MonAppli.app : répertoire contenant les outils de développement installés à l’aide de l’outil Xcode.

L’analyse de chaque application n’est généralement pas possible en termes de temps et le plus simple est d’exclure la liste des applications légitimes des applications potentiellement malveillantes. L’analyse comparative dans ce cas est très efficace et notamment grâce à l’analyse par condensat approximatif. Pour filtrer la recherche, il est également possible d’exploiter la date de création des applications pour concentrer la recherche sur une période spécifique.

3.5.2 Identification des exécutables

Les exécutables Mach-0 des applications sont généralement présents dans les répertoires des applications installées (<rep>/MonAppli.app/MonAppli). Ils sont nécessaires pour qu’une application puisse fonctionner.

Un code malveillant n’étant pas forcément rattaché à une application, il est important de lancer une recherche exhaustive sur l’ensemble du système de fichiers et pas uniquement dans les répertoires consacrés aux applications. Le plus simple pour les identifier est de vérifier les entêtes de chaque fichier via par exemple la commande file.

Encore une fois, l’analyse comparative (voir 3.1) permet de rapidement faire le tri entre les exécutables sains et ceux à analyser.

3.5.3 Analyse des exécutables

Si le système de fichiers a pu être extrait lors de l’acquisition, l’analyse des binaires peut être entreprise.

Il s’agit donc de procéder à l’analyse par rétro-ingénierie des exécutables inconnus qui semblent présenter une menace pour le terminal. IDA Pro ou HopperDisassembler peuvent être utilisés.

Le MISC hors série n°7 consacré au reverse-engineering propose un article très complet sur le reverse iOS et notamment sur l’analyse des briques de sécurité.

Contrairement aux applications système, développeur ou entreprise, les applications provenant de l’Apple Store sont protégées à l’aide du DRM Fairplay. Leur contrôle nécessite un accès root sur le terminal (jailbreaké).

Il serait intéressant d'approfondir davantage ce sujet, mais le format Mach-O vaut un article à lui seul. Il est à noter que l’un des articles du MISC n°67 traite du format Mach-O et de son exploitation.

3.5.4 Analyse des .plist des Applications

Il s’agit de vérifier que les fichiers de configuration .plist des applications installées n’ont pas été altérés avant l’installation. Une personne malveillante pourrait en effet modifier, dans certains cas, un fichier de configuration, la vérification de la signature réalisée par Apple ne se basant que sur l’exécutable et non sur le fichier de configuration. Les fichiers de configuration permettant l’exécution de l’application sont stockés dans le répertoire racine de l'application sous le nom Info.plist :

D’autres fichiers .plist peuvent aussi être présents dans le répertoire de l’application afin de stocker des paramètres de configuration.

L’ouverture des fichiers .plist au format XML peut s'effectuer dans un éditeur de texte alors que l’ouverture du format binaire nécessite un outillage spécifique pour la lecture ou la conversion (Xcode sous Mac, libplist sous Linux [LIBIMOBILEDEVICE] ou [PLIST_EDITOR] sous Windows).

3.5.5 Signature des Mach-O et autorités de certification installées

3.5.5.1 Vérification des AC supplémentaires installées

Un terminal iOS laisse la possibilité à l’utilisateur d’installer son propre certificat généré par Apple lorsque celui-ci possède un compte entreprise ou développeur. Dans ce cas, si le certificat est installé sur le terminal, les applications signées avec la clef privée de ce certificat peuvent être installées sans passer par le processus de vérification d’Apple. Ainsi, une application malveillante pourrait être installée sur l’équipement par toute personne ayant dérobé un certificat entreprise ou développement. Comme précédemment évoqué, le service com.apple.misagent (via l’outil ideviceprovision par exemple) permet d'extraire les certificats des autorités de certification installés, sur un terminal jailbreaké ou non.

3.5.5.2 Signature des Mach-O

En plus des autorités de certification installées, il peut être intéressant de vérifier si tous les binaires utilisés par le système sont signés par une autorité de confiance. L’outil codesign permet de simplifier cette opération en réalisant l'extraction des informations concernant la signature. Par exemple, un Mach-O signé par Apple directement (iPhone OS Application Signing) pourra être installé sur tous les appareils :

En revanche, une application signée par un certificat développeur ou entreprise ne pourra être installée que sur un appareil (celui du développeur) ou après installation du certificat de l’entreprise :

Évidemment afficher le CN (Common Name) du certificat ne permet pas de s’assurer qu’il s’agisse d’un certificat de confiance. L'extraction de tous les certificats stockés dans l'exécutable permet alors de s'en assurer :

Les certificats sont alors stockés dans les fichiers « codesign0, codesign1, … » au format DER  (codesign0 étant celui ayant signé l’exécutable, les autres étant des AC intermédiaires et root). Il est alors possible de les transformer au format PEM via openssl :

Les certificats des différentes autorités de certification doivent ensuite être concaténés au sein d’un même certificat :

La validité du certificat et de sa chaîne de certification peut alors être confirmée via l’option « verify » d’openssl et les certificats des AC (ajout de -ignore_critical parfois nécessaire) :

La moindre erreur concernant le certificat pourra donc être détectée par ce biais (date de validité, chaîne de confiance, certificat auto-signé, absence de certificat, etc.) [OPENSSL_VERIFY].

Cependant, la validité du certificat de l’autorité de certification racine d’Apple inclus dans l’exécutable, soit Apple Root CA, doit aussi être vérifiée puisque les précédentes opérations se basent en partie sur celui-ci. Le certificat officiel d’Apple étant disponible sur son site [APPLE_ROOT_DER], l’opération consiste à comparer celui-ci avec celui extrait de l'exécutable (généralement codesign2).

3.5.6 Analyse dynamique des exécutables

En investigation numérique mobile, l’analyse dynamique ne sera généralement réalisée qu’en dernier recours.

En effet, l’analyse dynamique ne peut être réalisée que dans les deux scénarios suivants :

- l'équipement à analyser est jailbreaké et permet alors l’installation d’outils de monitoring des applications ;

- l’application « suspecte » a été identifiée et son binaire peut être à nouveau installé sur un terminal d’analyse ou un émulateur. Le Jailbreak de l’équipement n’est alors pas nécessaire.

L’un des articles du MISC Hors-série n°7 consacré à iOS propose déjà les moyens de débogage possible pour analyser une application en espace utilisateur (gdb, lldb, interposition...). D’autres moyens non évoqués dans l’article permettent l’analyse dynamique :

- utilisation de la bibliothèque [MOBILESUBSTRATE] ;

- utilisation de [CYCRYPT].

Certaines de ces méthodes ont notamment été présentées à [GREHACK_2012] et [HACK.LU_2012].

Il serait intéressant d’approfondir davantage ce sujet, mais l’analyse dynamique vaut un article à elle seule.

3.6 Activité système et réseau en temps réel

3.6.1 Exploitation des journaux Syslog

Comme présenté au début de l’article, le service com.apple.syslog_relay permet d’extraire les journaux Syslog générés par les processus (outil idevicesyslog)  :

3.6.2 Flux de communication

Comme précédemment évoqué, l’activité réseau transitant par les différents canaux radio (3G/4G, Wi-Fi) peut être répliquée sur une interface réseau virtuelle à travers la connectique USB du terminal (utilisation du service com.apple.pcapd). Cette technique permet d’une part d’identifier les processus générant du trafic réseau et d’autre part d’extraire le contenu des flux réseau au format standard .pcap (exploitable donc via Wireshark). La connexion du terminal vers un serveur C&C peut être rapidement identifiée à l'aide de cette technique.

Les flux SSL ne sont pas déchiffrables par ce biais. Afin de pouvoir analyser les flux, il est nécessaire de réaliser une attaque de type « homme du milieu » (MITM). La machine de l’analyste doit donc être en coupure entre la sortie Internet et le terminal par le biais d’un réseau Wi-fi. Il est nécessaire d’installer sur le terminal le certificat de l’autorité de certification ayant signé le certificat serveur afin que :

- le certificat serveur présenté par la machine de l’analyste au terminal soit fiable (car signé par une autorité de confiance) ;

- l’analyste puisse déchiffrer le contenu capturé.

Cependant, dans le cas où l’application vérifie si le certificat du serveur (présenté alors par la machine de l’analyste) est bien celui attendu, il est nécessaire de désactiver ce mécanisme de sécurité, plus connu sous le nom de « certificate pinning », pour que l’application initie des connexions SSL avec la machine de l’analyste. Les outils [IOS_KILL_SWITCH] [SSL_DISABLE] permettent de réaliser cette opération en modifiant les fonctions responsables du contrôle SSL sur un terminal jailbreaké.

Par ailleurs, la présence de traces indiquant l'utilisation de ces méthodes de capture est généralement signe qu'une interception des flux du terminal a été tentée. L'outil keychain_tool [DATA-PROTECTION] permet entre autres d'extraire les certificats SSL installés sur le terminal.

3.7 Journaux d’historique

3.7.1 Fichiers de journalisation

Il s’agit d’analyser, dans les fichiers de journalisation, toutes les traces laissées par le système, les services et les applications lors de leur exécution ou leur crash, dans le but de tenter l’identification des indices de compromission. Comme précédemment évoqué, le service com.apple.crashreportmover (via l'outil idevicecrashreport) permet d’extraire les rapports générés par le système lors du crash d’une application ou d’un processus et pouvant ainsi parfois révéler la présence d’un programme malveillant instable ou modifiant des fonctions système importantes.

Si le système de fichiers a pu être extrait lors de l’acquisition, tous les journaux de l’équipement, stockés à différents emplacements, peuvent être analysés pour rechercher des indices de compromission :

- /private/var/log/ ;

- /private/var/logs/ ;

- /private/var/mobile/Library/Logs/ ;

- /private/etc/asl/.

Cependant, pour éviter de passer à côté d’un fichier important ou inconnu et généré par une application tierce, il est conseillé d’effectuer une recherche manuelle des fichiers *.log, *.asl et des répertoires *log* et *asl*.

Comme l’illustre l’exemple ci-dessus, le nom de certains fichiers peut révéler la présence de Jailbreak du terminal.

Alors que les fichiers .log sont lisibles directement avec un éditeur de texte classique, les fichiers binaires au format Syslog .asl nécessitent d’être décodés avec la commande Syslog sous Mac OS X ou avec un outil spécifique tel que ccl_ccldb.py [CCL_ASL].

3.7.2 Historique de navigation Web

Il s’agit d’identifier si un éventuel programme malveillant ou un certificat d’autorité malveillante a pu être téléchargé sur le terminal par le biais du navigateur Web Safari. Les fichiers d’historique de navigation de Safari sont stockés dans deux bases de données SQLite :

- /private/var/mobile/Library/Caches/com.apple.WebAppCache/ApplicationCache.db ;

- /private/var/mobile/Applications/7573AC5A-A303-4C4A-B182-85C68BC14BDF/Library/Caches/com.apple.mobilesafari/Cache.db.

Pour rappel, la méthodologie de Jailbreak « jaibreakme.com » permettait, suite au téléchargement sur Internet et à l'ouverture d'un document PDF, de débrider le terminal en exploitant une vulnérabilité dans le lecteur de fichier PDF.

Conclusion

Cette introduction à l'investigation numérique sur terminal iOS montre clairement que l'acquisition de données reste possible sur ce type d'équipement, malgré les accès limités et les mécanismes de protection mis en œuvre. L'analyse des données collectées, quant à elle, est proche en matière de méthodologie d'une analyse d'un ordinateur et quasi similaire à celle menée sur un environnement Mac OS X. De nombreuses recherches ayant été menées sur le sujet, il existe un nombre important d’outils permettant une collecte et une analyse fiable. Enfin, nous retiendrons que les moyens d'acquisition présentés sont inefficaces sur un terminal récent verrouillé, cas peu courant dans le cadre légitime de recherche d'indices de compromission.

Remerciements

À titre personnel, nous tenons à remercier Jean Sigwald ainsi que les autres développeurs pour leurs outils.

Références

[SSTIC 2012] https://www.sstic.org/media/SSTIC2012/SSTIC-actes/forensicsios/SSTIC2012-Slides-forensicsios-sigwald_bedrune.pdf

[SSTIC 2014] https://www.sstic.org/media/SSTIC2014/SSTIC-actes/Mathieu_RENARD_-_Investigation_numerique_iOS/SSTIC2014-Article-Mathieu_RENARD_-_Investigation_numerique_iOS-renard.pdf

[DATA-PROTECTION] https://code.google.com/p/iphone-dataprotection/

[LIMERA1N] http://www.limera1n.fr/

[UFED] http://www.cellebrite.com/fr/mobile-forensics/products/standalone/ufed-touch-ultimate

[LIBIMOBILEDEVICE] http://www.libimobiledevice.org/

[IDEVICEINFO] https://github.com/bryanforbes/libimobiledevice/blob/master/tools/ideviceinfo.c

[IDEVICEDATE] https://github.com/libimobiledevice/libimobiledevice/blob/master/tools/idevicedate.c

[IDEVICEINSTALLER] https://github.com/libimobiledevice/ideviceinstaller

[IFUSE] https://github.com/libimobiledevice/ifuse

[IDEVICEPROVISION] https://github.com/libimobiledevice/libimobiledevice/blob/master/tools/ideviceprovision.c

[IDEVICESYSLOG] https://github.com/libimobiledevice/libimobiledevice/blob/master/tools/idevicesyslog.c

[IDEVICECRASHREPORT]  https://github.com/libimobiledevice/libimobiledevice/blob/master/tools/idevicecrashreport.c

[IDEVICEBACKUP] https://github.com/mcolyer/libiphone/blob/master/tools/idevicebackup.c  

[IDEVICEBACKUP2] https://github.com/libimobiledevice/libimobiledevice/blob/master/tools/idevicebackup2.c

[IOSFORENSICS] https://github.com/iOSForensics

[1] https://github.com/limneos/classdump-dyld/tree/master/iphoneheaders/iOS7.0.3/Applications    

[2] https://github.com/Legoless/iOS-Localization/tree/master/7.0.4/iPhone/Applications  

[3] https://github.com/MP0w/iOS-Headers/tree/master/iOS7  

[4] http://vladalexa.com/iosx/sources/

[BINWALLY] https://github.com/bmaia/binwally

[$CATALOGFILE] https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#CatalogFile

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

[HFSJOURNALPARSER] http://www.kazamiya.net/en/HFSJournalParser_TrackFileActivity

[AHJP] https://docs.google.com/forms/d/1_Zrf7LfmnklJfJ7CteecdAiAWGdRkNp2ltqqHuYFncQ/viewform

[LOWLEVEL_IOS] http://esec-lab.sogeti.com/post/Low-level-iOS-forensics

[IPHONEWIKI] http://theiphonewiki.com/wiki/Firmware_Keys

[VFDECRYPT] http://code.google.com/p/iphone-elite/downloads/list

[P0SIXPWN] http://p0sixspwn.com/

[EVASI0N] http://evasi0n.com/

[PANGU] http://en.pangu.io/

[KCACHE] https://github.com/badeip/kcache

[XPWNTOOL] http://theiphonewiki.com/wiki/Xpwntool

[LZSSDEC] http://nah6.com/~itsme/cvs-xdadevtools/iphone/tools/lzssdec.cpp

[BINDIFF] http://www.zynamics.com/bindiff.html

[JOKER] http://newosxbook.com/src.jl?tree=listings&file=8-joker.c

[ACCUVANT] http://blog.accuvant.com/bthomasaccuvant/evasi0n-jailbreaks-userland-component/

[PLIST_EDITOR] http://www.icopybot.com/plist-editor.htm

[APPLE_ROOT_DER] https://www.apple.com/appleca/AppleIncRootCertificate.cer

[OPENSSL_VERIFY]https://www.openssl.org/docs/apps/verify.html

[MOBILESUBSTRATE] http://www.cydiasubstrate.com/

[CYCRYPT] http://www.cycript.org/

[GREHACK_2012] http://goo.gl/wfkXpL

[HACK.LU_2012] http://goo.gl/1UhtlZ

[IOS_KILL_SWITCH] https://github.com/iSECPartners/ios-ssl-kill-switch

[SSL_DISABLE] https://github.com/pod2g/ios_stuff/blob/master/misc-hs07/ssl_disable.c

[CCL_ASL] https://code.google.com/p/ccl-asl/