Investigation numérique sous macOS / HFS+

Magazine
Marque
MISC
Numéro
107
Mois de parution
janvier 2020
Domaines


Résumé

La démocratisation de l’écosystème Apple s'est réalisée à tous les niveaux (informatique de gestion, téléphone portable, wearables...) et cela n'a pas été sans éveiller l'intérêt des développeurs de logiciels malveillants. Les équipes de réponse à incident ont donc dû s'adapter afin de pouvoir apporter leur expertise dans les meilleures conditions.


Body

L'objectif de ce document est de présenter une méthodologie permettant de répondre aux besoins inhérents à toute investigation numérique au sein de l'univers macOS.

L'analyse se basera sur des données provenant d'un système de fichiers sous macOS 10.13 et s'effectuera à partir des outils proposés par la distribution Kali.

1. Acquisition de l'image

Il existe plusieurs méthodes permettant d'obtenir une image du système de fichiers : acquisition physique ou logique.

Acquisition physique : Cette acquisition nécessite que le système soit éteint. Si le matériel le permet, il s'agit de la méthode la plus simple et efficace.

Pour cela, il faut démonter le périphérique de stockage et utiliser des outils de type « Copieur/Bloqueur » afin d'en générer une image bit à bit (au format RAW, ou Encase). Cette étape s'effectue sans altérer la preuve, ce qui est le plus important dans une investigation. Voici un bloqueur reconnu dans le domaine : https://www.guidancesoftware.com/tableau/hardware.

Une fois le disque démonté, il est également possible de le connecter à une machine d'analyse et d'utiliser les outils traditionnels tels que FTK Imager ou la commande dd. J'attire votre attention sur le fait que l'accès aux disques durs est de plus en plus difficile, ceux-ci étant souvent soudés.

Si tel est le cas, il est possible d'effectuer une acquisition physique grâce au « Target Disk Mode ». Ce mode permet d'accéder aux données d'une machine reliée par un câble Firewire, Thunderbolt 2, USB-C ou Thunderbolt 3. Il faut juste, au préalable, que la machine cible soit en mode « Target », il faut pour cela appuyer sur la touche [T] durant le démarrage. Il est également nécessaire que le démon « Disk Arbitration » soit désactivé sur la machine de l'analyste. Ce service monte automatiquement les périphériques connectés au système macOS. Il se désactive par la commande :

$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist

Une fois cela fait, l'analyste peut connecter la machine à analyser puis effectuer une acquisition du disque visé avec les outils précédemment cités.

Acquisition logique : cette acquisition, moins poussée que la précédente, permet d'effectuer une copie des données présentes sur le système de fichiers. Cette méthode est plus rapide, mais n'offre pas la possibilité de retrouver d'éventuels fichiers supprimés. Celle-ci peut être réalisée grâce aux outils : Carbon Copy Cloner, SuperDuper ou Clonezilla. Le seul prérequis nécessaire étant d’être détenteur des privilèges administrateurs.

2. Analyse des données collectées

Nous ne présenterons que des outils disponibles en source ouverte sur GitHub et fonctionnels au sein d'un environnement Linux.

Comme d’autres éditeurs de système d’exploitation, Apple développe ses propres systèmes de fichiers. Créé en 1985, le système de fichiers HFS a évolué au fil des années pour devenir en 1998 le système de fichiers HFS+. Apple intègre en 2017 un nouveau venu l’APFS qui vise à faire évoluer le système de fichiers historique HFS+ tout en corrigeant les problèmes connus. Seul l’HFS+ encore très largement utilisé sera abordé dans la suite de l’article. Néanmoins, toute acquisition comportant un système de fichiers APFS peut être analysée via le driver « apfs-fuse » disponible sur GitHub : https://github.com/sgan81/apfs-fuse.git.

2.1 Accéder à un système de fichiers HFS+

Le système de fichiers propriétaire de macOS n'est pas pris en charge nativement par les systèmes d'exploitation tels que GNU/Linux ou Windows.

La commande file permet de vérifier le type du système de fichiers de l'image à monter. La commande fsstat de la suite d’outils Sleuthkit peut également être utilisée.

# file evidence_HDD.img
evidence_HDD.img: Macintosh HFS Extended version 4 data last mounted by: 'Shnk', created: Mon Apr 15 12:05:23 2019, last modified: Mon Apr 15 16:26:05 2019, last checked: Mon Apr 15 16:05:23 2019, block size: 4096, number of blocks: 37360, free blocks: 32298

Ensuite, il faut s’assurer d'avoir installé l'outil hfsplus.

# apt install -y hfsplus

Une fois l'installation faite, l'utilitaire mount avec l'argument -t hfsplus permet de monter (de préférence en lecture seulement) le système de fichiers sur notre système GNU/Linux et l'explorer avec vos outils habituels.

# mount -t hfsplus -o ro evidence_HDD.img /media/apfs/

2.2 Accéder aux données d'un système de fichiers HFS+ chiffré avec FileVault2

L'analyste peut être confronté à un système de fichiers chiffré à l'aide de FileVault2. La procédure d'accès aux données reste pratiquement identique à celle vue précédemment. Il est nécessaire d'identifier la partition que l'on souhaite analyser ainsi que son secteur de démarrage.

# fdisk -l evidence_HDD.raw
Disk evidence_HDD.raw: 512 MiB, 536870912 bytes, 1048576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3D6977CC-682A-4FB6-A6FD-2E80577E4C5D
 
Device      Start     End Sectors Size Type
evidence_HDD.raw1    40 1048535 1048496 512M Apple Core storage

Il faut que l'outil fvdemount soit installé sur votre système GNU/ Linux.

# apt install -y libfvde-utils

Utilisez-le avec la clé de chiffrement ou le mot de passe pour déchiffrer le volume.

Il suffit de préciser le début de la partition. Dans l'exemple, la partition evidence_HDD.raw1 débute au secteur 40. Chaque secteur occupant 512 octets, l'analyste devra indiquer le déplacement $((40*512)).

# fvdemount -o $((40*512)) evidence_HDD.raw /media/hfs/
..
Unable to unlock source volume

L'erreur affichée confirme que nous sommes en présence d'un système de fichiers HFS+ chiffré. L'option -k de fvdemount permet d'indiquer une clé de déchiffrement, l'option -p un mot de passe.

# fvdemount -h
fvdemount 20190104
 
Use fvdemount to mount a FileVault Drive Encrypted (FVDE) volume
 
Usage: fvdemount [ -e plist_path ] [ -k keys ] [ -o offset ] [ -p password ]
                 [ -r recovery_password ] [ -X extended_options ] [ -hvV ]
                 volume mount_point
 
  volume:      a FileVault Drive Encrypted (FVDE) volume
 
  mount_point: the directory to serve as mount point
 
  -e:          specify the path of the EncryptedRoot.plist.wipekey file
  -h:          shows this help
  -k:          specify the volume master key formatted in base16
  -o:          specify the volume offset in bytes
  -p:          specify the password/passphrase
  -r:          specify the recovery password/passphrase
  -v:          verbose output to stderr, while fvdemount will remain running in the foreground
  -V:          print version
  -X:          extended options to pass to sub system

Que faire si vous ne disposez ni de la clé ni du mot de passe ? Ne vous inquiétez pas, tout n'est pas perdu pour autant. La clé peut être extraite à partir d'un dump mémoire effectué par l’outil OSXPMem provenant de la suite Rekall. Ce sujet complexe mériterait d’être abordé au sein d’un article. En utilisant l'outil Volatility, grâce au plugin mac_filevault2, il va être possible de retrouver la clé de chiffrement utilisée. Seul prérequis, le système de fichiers chiffré devait être monté durant la phase de collecte de la mémoire vive, pour que sa clé soit en mémoire.

# volatility -f evidence_ram.dmp --profile=MacMountainLion_10_8_1_AMDx64 mac_filevault2
Volatility Foundation Volatility Framework 2.6
Address            Volume Master Key
------------------ --------------------------------
0xffffff804c0b7000 79121544c4c8ec2a5ea91b9b2312d9d2

Une fois la clé retrouvée, celle-ci sera passée en argument à l'outil fvdemount.

# fvdemount -k 79121544c4c8ec2a5ea91b9b2312d9d2 -o $((40*512)) evidence_HDD.raw /media/hfs/

Un fichier nommé fvde1, correspondant à la partition HFS+, apparaît sous le point de montage, ici /media/hfs/.

# ll /media/hfs/
total 4
dr-xr-xr-x 2 root root         0 Sep 6 04:26 .
drwxr-xr-x 8 root root      4096 Sep 6 02:59 ..
-r--r--r-- 1 root root 218054656 Sep 6 04:26 fvde1
 
# file /media/hfs/fvde1
/media/hfs/fvde1: Macintosh HFS Extended version 4 data (mounted) last mounted by: 'HFSJ', created: Thu Nov 22 10:04:33 2018, last modified: Fri Nov 30 19:49:26 2018, last checked: Thu Nov 22 14:04:33 2018, block size: 4096, number of blocks: 53236, free blocks: 49742

L'accès aux données de cette partition sera possible après avoir connecté le fichier fvde1 sur un nouveau point de montage.

# mount -o loop,ro /media/hfs/fvde1 /media/hfs_filesystem/

Il est désormais possible d'investiguer les fichiers système et utilisateurs afin d'identifier tout élément anormal.

2.3 Les outils d'investigation

Il n'existe pas d'outil parfait pour mener une analyse ou investigation numérique. Il est donc important de disposer d'une boite à outils, comprenant plusieurs logiciels, et ce même s'ils ont la même vocation. Quelques projets très intéressants, dédiés au forensic de données macOS, ont vu le jour. Le premier, apollo, a été développé par Sarah Edwards de Mac4n6. Elle dispense également des formations de Forensic macOS au sein du SANS Institute.

Fonctionnant sous Python3, apollo analyse les bases de données et fichiers du système afin de fournir un rapport précis de l'utilisation du système.

Le seul prérequis constaté est la présence du module python simplekml.

$ pip install simplekml

L'exécution s'effectue de la manière suivante :

$ sudo python apollo.py -o {csv, sql} -p {ios, mac, yolo} -v {8,9,10,11,12,yolo} <modules directory> <data directory>

Quelques paramètres indispensables sont à fournir :

  • le type de sortie désirée par l'analyste ;
  • le type de périphérique analysé ;
  • la version majeure de la version du système analysé ;
  • le chemin du répertoire contenant les modules d'apollo ;
  • et enfin la racine du système de fichiers à analyser.

Une fois tous les éléments identifiés, il ne reste plus qu'à exécuter l'outil.

$ sudo python apollo.py -o csv -p mac -v 12 modules/ /
 
--------------------------------------------------------------------------------------
apollo Version: 08252019
Platform: mac
Version: 12
Data Directory: /
Modules Directory: modules/
--------------------------------------------------------------------------------------
 
==> Parsing 163 modules (Note: Some modules may be run on more than one database.)
  [1] modules/aggregate_dictionary_distributed_keys.txt on ADDataStore.sqlitedb
  [2] modules/aggregate_dictionary_scalars.txt on ADDataStore.sqlitedb
  [3] modules/call_history.txt on CallHistory.storedata
..
 
===> Total number of records: 84745
===> Lazily outputted to CSV file: apollo.csv

Comme indiqué par l'outil, le rapport de l'analyse se trouve dans le fichier apollo.csv. Attention, les événements présents ne sont pas classés par date d'exécution. Il sera nécessaire d'effectuer le tri avec l'outil sort pour obtenir une chronologie ordonnée. Vous trouverez ci-dessous quelques exemples de données d'utilisation des applications ical, ichat extraites d'un rapport apollo.

Le module Application Usage fournit une journalisation des applications exécutées sur le système.

2019-09-06 15:39:12,Application Usage,[APP NAME: com.logitech.Onboarding] [USAGE IN SECONDS: 228] [DAY OF WEEK: Friday] [GMT OFFSET: 2] [START: 2019-09-06 15:39:12] [END: 2019-09-06 15:43:00] [ENTRY CREATION: 2019-09-06 15:43:00] [ZOBJECT TABLE ID: 141793] ,/private/var/db/CoreDuet/Knowledge/knowledgeC.db,modules/knowledge_app_usage.txt#knowledgeC.db
2019-09-06 16:40:31,Application Usage,[APP NAME: com.logitech.Onboarding] [USAGE IN SECONDS: 52] [DAY OF WEEK: Friday] [GMT OFFSET: 2] [START: 2019-09-06 16:40:31] [END: 2019-09-06 16:41:23] [ENTRY CREATION: 2019-09-06 16:41:24] [ZOBJECT TABLE ID: 141899] ,/private/var/db/CoreDuet/Knowledge/knowledgeC.db,modules/knowledge_app_usage.txt#knowledgeC.db

Le module Application In Focus, permet quant à lui de visualiser, seconde par seconde, les applications utilisées par l'utilisateur. Voici les événements enregistrés alors que je rédigeais ce document. Vous pouvez constater que je me sers de Safari, et que j'affiche le rapport apollo avec iterm2.

2019-09-19 08:19:03,Application In Focus,[BUNDLE ID: com.apple.Safari] [USAGE IN SECONDS: 6] [DAY OF WEEK: Thursday] [GMT OFFSET: 2] [START: 2019-09-19 08:19:03] [END: 2019-09-19 08:19:09] [ENTRY CREATION: 2019-09-19 08:19:09] [ZOBJECT TABLE ID: 149980] ,/private/var/db/CoreDuet/Knowledge/knowledgeC.db,modules/knowledge_app_inFocus.txt#knowledgeC.db
2019-09-19 08:19:09,Application In Focus,[BUNDLE ID: com.googlecode.iterm2] [USAGE IN SECONDS: 1] [DAY OF WEEK: Thursday] [GMT OFFSET: 2] [START: 2019-09-19 08:19:09] [END: 2019-09-19 08:19:10] [ENTRY CREATION: 2019-09-19 08:19:10] [ZOBJECT TABLE ID: 149981] ,/private/var/db/CoreDuet/Knowledge/knowledgeC.db,modules/knowledge_app_inFocus.txt#knowledgeC.db

Si vous souhaitez aller plus loin, une présentation de cet outil est disponible à l'adresse : https://github.com/mac4n6/Presentations/blob/master/LaunchingAPOLLO/LaunchingAPOLLO.pdf.

Un autre outil spécialisé dans l'investigation numérique de système macOS, mac_apt pour « macOs Artifact Processing Tool » est téléchargeable sur : https://github.com/ydkhatri/mac_apt/releases.

Fonctionnant comme apollo, mac_apt parcourt l’arborescence du système de fichiers afin d'analyser les données présentes et d'en extraire les artefacts. L'annexe contient une liste non exhaustive de ces artefacts. Le rapport final peut être généré au format XLSX, CSV ou bien stocké dans une base de données SQLite.

Conclusion

J'espère avoir réussi, au travers de cet article, à démystifier les différentes étapes permettant de préparer une investigation numérique sur un système macOS.

Pour plus de détails sur chacune des étapes, je vous invite à lire le livre : « OS X Incident Response: Scripting and Analysis De Jaron Bradley ».

Annexe

Vous trouverez ci-dessous une liste succincte d'emplacements de fichiers donnant accès à des données primordiales lors d'une investigation numérique :

  • /var/db/.AppleSetupDone : ce fichier est vide par défaut ; sa date de création correspond à la date d'installation du système ;
  • /System/Library/CoreServices/SystemVersion.plist : fichier stockant la version du système d'exploitation installée ;
  • /etc/localtime (ex. : -> /var/db/timezone/zoneinfo/Europe/Paris) : fichier permettant de déterminer le fuseau horaire utilisé sur le système ;
  • /private/var/networkd/netusage.sqlite : base stockant les données relatives à l'usage du réseau ;
  • ~/Library/Keychains et /Library/Keychains/ : emplacements stockant les keychains du système et des utilisateurs.

Et pour finir, voici quelques emplacements référençant les applications exécutées lors du démarrage ou lors de la connexion d'un utilisateur :

  • /System/Library/LaunchAgents/, ~/Library/LaunchAgents/ et /Library/LaunchAgents/ ;
  • /System/Library/LaunchDaemons/ et /Library/LaunchDaemons/ ;

  • /System/Library/StartupItems/ et /Library/StartupItems/.

Une liste plus exhaustive de ces artefacts est disponible sur GitHub : https://github.com/pstirparo/mac4n6.

Remerciements

Je voudrais remercier Alain Menelet pour ses précieux conseils, et avoir su magnifier cet article, ainsi que mon épouse pour ses relectures et encouragements.



Articles qui pourraient vous intéresser...

Répondez aux problématiques de sécurité d’accès avec OpenSSH

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Notre infrastructure est désormais stable et sécurisée tant au niveau système que réseau. Nous allons pouvoir étudier de manière un peu approfondie un logiciel particulier : OpenSSH. Ce démon réseau nous permet de nous connecter en toute sécurité sur nos serveurs via le protocole SSH. Son développement a commencé il y a plus de 20 ans chez nos amis d’OpenBSD. La liste de ses fonctionnalités est d’une longueur impressionnante. Nous allons en parcourir ensemble quelques-unes qui, je l’espère, nous permettront d’améliorer tant notre sécurité que notre productivité quotidienne.

Les lolbas, des amis qui vous veulent du bien

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Il existe des fichiers nativement présents sur Windows pouvant être détournés par un attaquant et ainsi être utilisés lors des différentes phases de compromission. Dans cet article, nous présenterons quelques cas d’utilisations de ces fichiers par des attaquants, ainsi que des solutions de prévention contre ces attaques.

Sécurité réseau dans un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

En introduisant le concept de micro-services, Kubernetes lance un nouveau défi aux solutions d’isolation et de filtrage réseau : comment gérer les droits d’accès réseau dans une infrastructure en constante mutation et dans laquelle une machine n’a plus un rôle prédéterminé ?

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.

Migrez de iptables vers nftables

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Il y a cinq ans, je lisais un premier article sur nftables [1] : l’outil semblait intéressant, mais il n’était pas disponible sur ma machine. En 2019, une distribution majeure, Debian, a basculé sur nftables avec sa version 10 (Buster) [2] : il est donc temps de voir comment migrer du vénérable pare-feu iptables vers son successeur.