MISC

n°

janvier 2013

Par

Tag(s)

À partir d'une analyse passive distante sans compte ou à partir d'un accès physique avec ou sans compte utilisateur, quelles informations critiques peuvent être extraites d'un système Mac OS X dans le cadre d'une attaque réelle ou d'une investigation numérique ?Cet article illustre, de manière crescendo, les différentes fuites d'informations accessibles pouvant être exploitées sur votre système.

1. Introduction

Le système Mac OS X a été conçu pour répondre aux besoins des particuliers en automatisant un nombre important de tâches quotidiennes et d’administration. Avec Mac OS X, tout est plus facile et convivial que sur les autres systèmes d’exploitation. Mais est-il pour autant plus sécurisé ? Aujourd’hui, Mac OS X est de plus en plus présent dans les entreprises. Pouvons-nous avoir confiance en ce système au point de l'accepter dans le système d’informations de notre entreprise ? Est-ce qu’une configuration par défaut suffit à protéger les données des utilisateurs d’une éventuelle fuite d’informations lorsqu’un attaquant l’a prise comme cible ?

Finalement, les moyens d'accès offerts par défaut sur Mac OS X suffisent-ils à extraire les données les plus sensibles lors d'une analyse forensique ?

2. Fuite d’informations depuis un accès « simple » utilisateur

2.1. Obtention des droits utilisateur avant tout…

En effet, avant de pouvoir profiter des accès d’un utilisateur standard, il faut pouvoir les acquérir.

Plusieurs vecteurs d’attaques s’offrent à un attaquant selon le contexte (accès physique à la machine victime, accès distant, etc.).

Depuis un accès distant, un attaquant peut tout d’abord tenter d’exploiter simultanément la faille humaine et technique dans le but d’installer aux dépens de la victime un programme malveillant. Un exemple très récent exploitant ces deux aspects et qui a fait la une des médias est le malware Flashback. Celui-ci exploite notamment une faille Java qu’Apple a mis un certain temps à corriger. Java n’est évidemment pas un cas à part et les logiciels tiers tels que Safari, Quicktime ou encore iTunes sont souvent des cibles privilégiées des pirates.

En ce qui concerne l’exploitation de ces failles, le site exploit-db.com ou encore la plateforme d’exploitation Metasploit facilite grandement cette opération en proposant des outils ou des scripts conçus spécifiquement à cet effet.

Le nombre d’exploits conçus contre les plateformes Mac OS X est encore limité par rapport à Windows :

- 145 pour Windows depuis 2011 et 15, depuis 2003, se basant sur des failles des protocoles natifs SMB et Netbios ;

- 36 pour Mac OS X depuis 2003, dont 8 seulement se basant sur des failles des protocoles natifs (AppleFileServer, mDNSResponder, etc.).

Cependant, Mac OS X étant de plus en plus étudié par des chercheurs en sécurité, ces chiffres devraient grossir de manière significative dans les années à venir.

Pour limiter l’exploitation de vulnérabilités publiées, la recherche automatique des mises à jour système doit être activée afin d’alerter l’utilisateur qu’un éventuel patch de sécurité a été publié. Ce paramètre peut être configuré via le menu Préférences système > Mise à jour logicielle. Le système Mac OS X dispose d’un pare-feu (filtrage des flux entrants uniquement) qu'il est vivement conseillé d’activer par le menu Préférences système > Securité > Coupe-feu.

D’autre part, depuis un accès distant, un attaquant peut tenter d’exploiter les services ouverts tels que ceux d’administration (SSH, Bureau à Distance, etc.) et de partage (FTP, HTTP, iTunes, etc.). Par défaut, lorsque ces services sont activés, il suffit à un attaquant d'être sur le même réseau local que sa victime et d’écouter les trames réseau mDNS (inclus dans le protocole Bonjour) pour identifier les services démarrés sur la machine de la victime. Ainsi, l’attaquant obtient d’une part les services disponibles de manière passive (sans lancer un scan de port) et d’autre part des informations intéressantes telles que le nom de l’utilisateur ou le login utilisé selon le service.

Trace réseau indiquant le nom de l'utilisateur courant

Le login de l’utilisateur ayant été identifié, il ne reste à l’attaquant qu'à identifier le mot de passe associé. Des outils tels que Bonjour Browser [1] ou MDNSRecon [2] implémentent des fonctionnalités permettant d’identifier et classifier ces informations automatiquement.

Pour désactiver l’envoi de requêtes mDNS sur le réseau, vous pouvez modifier le fichier de configuration associé en lançant la commande suivante suivie d’un reboot :

defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder ProgramArguments -array "/usr/sbin/mDNSResponder" "-launchd" "-NoMulticastAdvertisements"

Depuis un accès physique, les actions possibles sur le système sont évidemment plus nombreuses. En effet, il est possible d’une part d’accéder directement au contenu du disque dur via son extraction, si celui-ci n’est évidemment pas chiffré. Une autre alternative est d'exploiter le fait que, par défaut, la session du premier utilisateur créé (administrateur de la machine) s’ouvre automatiquement sans saisir le mot de passe de l’utilisateur. Dans le cas où l’accès à la GUI est protégé par un nom d’utilisateur et un mot de passe, il reste évidemment la possibilité de tenter d'identifier un couple d’authentifiants valides pour entrer sur le système. Enfin, il n’est pas rare qu’un utilisateur s’absente quelques instants sans verrouiller sa machine …

Une dernière méthode pour obtenir un accès au système, présentée par la suite, consiste à exploiter les accès directs à la mémoire RAM.

2.2. Exemple de fuite de données techniques et personnelles

L’intérêt ici n’est évidemment pas de présenter toutes les informations accessibles via un simple compte utilisateur, mais uniquement des exemples de données pertinentes en termes de confidentialité, utiles pour une future élévation de privilèges et accessibles sans connaître nécessairement le mot de passe du compte utilisateur compromis.

Chemin et utilisateur courant	Commande	echo $HOME \|cut -f 3 -d '/'
Ces informations permettent de savoir où commencer à chercher les données techniques et personnelles.
Utilisateurs présents sur le système	Commande	/usr/bin/dscacheutil -q user\|grep -B 5 '/bash'\|grep name\|cut -c '7-'
Cette information est utile pour tenter une élévation de privilèges vers les autres comptes existants.
Utilisateurs ayant les droits d’administrateur root (groupe « admin » par défaut)	Commande	/usr/bin/dscl . -read /Groups/admin \| grep 'GroupMembership:' \| cut -c '18-' \| sed '/root / s///'
Cette information est utile pour tenter une élévation de privilèges vers un compte ayant un profil d’administration.
Historique des commandes saisies dans le terminal	Commande	history
Les données remontées peuvent contenir des mots de passe saisis précédemment par la victime à travers le terminal et donc utiles à une élévation de privilèges.
Fichiers « Lockdown » iOS (Escrow Keybag)	Stockage	/private/var/db/lockdown/<UDID_iPhone_iPad_iPod>.plist
Ce fichier est créé par le service Usbmuxd lorsqu'un nouvel équipement iOS (iPhone, iPod ou iPad) déverrouillé (passcode utilisateur) est connecté en USB à un Mac. Suite à cette action, l'ordinateur est donc autorisé à communiquer avec l'équipement mobile via des logiciels tels que iTunes, iPhone Explorer ou DiskAid. Grâce à ce mécanisme, lorsque l'ordinateur « habilité » souhaitera accéder à nouveau à l'équipement mobile, aucun passcode ne sera demandé à l'utilisateur, même si celui-ci est verrouillé (et même si le passcode est changé ou une réinitialisation est lancée). Dès lors, en copiant ce/ces fichier(s), accessible(s) en lecture/écriture par tous les utilisateurs du système, un attaquant pourra communiquer, via une connexion USB, avec l'équipement mobile enregistré sans connaître le passcode de l'utilisateur et donc extraire les données de l'équipement (SMS, Calendrier, Musique, Vidéos, Photos, … et davantage s'il a été jailbreaké). Copie des fichiers d'habilitation iOS

Exemples de fuite de données techniques

Contenu intégral du trousseau d’accès (Keychain) de l’utilisateur	Commande	security dump-keychain -d ~/Library/Keychains/login.keychain
Pour rappel, le trousseau d’accès (ou Keychain) est un fichier à plat chiffré en 3DES et stockant un nombre important de mots de passe enregistrés à la première saisie de l’utilisateur pour une application spécifique (Evernote, iCal, Skype, WiFI, Google services, Microsoft Exchange, etc.). Cela évite ainsi à l’utilisateur de ressaisir son mot de passe lorsqu’il souhaitera accéder une nouvelle fois à son application. Lecture du trousseau d'accès « login.keychain » Contrairement à une tentative d’affichage ou de copie des mots de passe stockés dans le « trousseau d’accès » via l’application portant le même nom et qui nécessite le mot de passe de l’utilisateur, l’extraction complète du contenu en clair du trousseau d’accès via la commande security ne nécessite aucun mot de passe. Accès aux données stockées dans le trousseau d'accès Il n’est évidemment pas impossible et même fort possible qu’un mot de passe d’une application soit identique à celui utilisé pour un compte utilisateur ayant les droits d’administration…Àpartir de là, un accès avec les droits root sur la machine est trivial. Ce comportement étrange s’explique par le fait que le trousseau d’accès utilisateur est en réalité ouvert automatiquement dès l’ouverture de session utilisateur afin que la machine y accède sans interaction de la part de l’utilisateur. Cependant, ce scénario est valable uniquement si le mot de passe protégeant le trousseau d’accès est identique au mot de passe système choisi par l’utilisateur (configuration par défaut). En réalité, peu de propriétaires de Mac sont conscients qu’il est possible de modifier le mot de passe de leur trousseau d’accès. La majorité des systèmes sont donc vulnérables à ce scénario d’exploitation. La modification du mot de passe d’accès au trousseau d’accès s’effectue au sein de l’application Utilitaire > trousseau d’accès en sélectionnant le trousseau nommé 'login' puis en choisissant Edition > Modifier le mot de passe du trousseau 'login'. Il est également conseillé de configurer un délai de verrouillage du trousseau suite à une période d’inactivité via le menu Edition > Modifier les paramètres du trousseau 'login'. Toutefois, un chercheur a récemment développé une preuve de concept permettant d'ouvrir le trousseau d'accès de l'utilisateur courant sans en connaître le mot de passe, bien qu'il soit verrouillé et que le mot de passe ait été modifié... L'attaque consiste à extraire au sein de la mémoire allouée au processus « securityd », des potentielles clés AES pour ensuite les tester pour ouvrir le trousseau d'accès [3]. En effet, la clé AES protégeant les données du trousseau d'accès est stockée en mémoire RAM suite à son utilisation. Il suffit donc que l'utilisateur ait précédemment déverrouillé son trousseau d'accès pour que l'attaque réussisse. Cependant, la clé AES ne résidant pas en permanence en mémoire RAM (d'autres données pouvant l'écraser), l'attaque ne fonctionne pas à tous les coups… De plus, l'attaque requiert une extraction de la mémoire et donc les droits root sur le système.
Cookies des navigateurs web	Stockage	Safari: ~/Library/Cookies/Cookies.plist Firefox: ~/Library/Application \ Support/Firefox/Profiles/<USERPROFILE>.default/cookies.sqlite Chrome: ~/Library/Application Support/Google/Chrome/Default/Cookies
Ces données sont aisément exploitables, notamment pour des sites tels que Google, Linkedin ou encore Facebook. En effet, la durée d’expiration des cookies de tels sites est souvent assez importante (une semaine en moyenne) et laisse ainsi le temps à un attaquant les ayant récupérés et injectés dans son propre navigateur d’usurper l’identité de la victime. Un accès aux emails de la victime, à ses Google Docs ou encore à son profil Facebook est alors possible tant que les cookies n’ont pas expiré. Pour empêcher l’exploitation des cookies, il est préconisé de vider régulièrement les cookies de navigation. L’application CCleaner [4] permet notamment de réaliser le travail très facilement pour l’ensemble des navigateurs supportés sous Mac OS X.
Historique en image de Safari	Stockage	~/Library/Caches/com.apple.Safari/Webpage Previews/
Savez-vous que lorsque vous naviguez sous Safari, un screenshot de la nouvelle page chargée est fait ? Accès aux images stockées par Safari Il s’agit d’une fonctionnalité propre à Safari qui se nomme « Webpage Previews ». Contrairement à l’historique classique des navigateurs web qui n’indique que le nom du site visité, la fonctionnalité « Webpage Previews » permet de visualiser ce que voyait exactement l'utilisateur à l’écran au moment de la navigation et donc d’éventuelles données sensibles (email d’un webmail, données bancaires, sites illégaux, …). Ce type d'informations, lors d'une investigation numérique, peut s'avérer fort utile en complément de l'historique de navigation et des cookies. Pour empêcher l’exploitation de ce cache, il faut naviguer avec l’option « Navigation privée » ou alors vider régulièrement l’historique (option spécifique à « Webpage Previews »).
Messages Skype	Stockage	~/Library/Application \Support/Skype/<USER_SKYPE>/main.db
L’accès via le client Skype aux messages instantanés envoyés à travers la fonctionnalité « Chat » nécessite d’être authentifié : Accès aux messages instantanés via le client Skype Cependant, l’accès n’est pas protégé en passant directement par la table « Messages » de la base de données Sqlite3 main.db : Accès aux mêmes messages via la base « main.db » Ainsi, toute conversation effectuée par ce biais peut être visualisée par un attaquant ayant un accès à la machine et ce, sans connaître le mot de passe d’authentification de Skype. Des mots de passe ou des données sensibles peuvent ainsi être récupérés (ce que j'ai pu vérifier lors d'un audit réel). Les options de Skype permettent fort heureusement de supprimer l’historique des conversations spécifiques via le menu Conversations.

Exemples de fuite de données personnelles

3. Fuite d’informations depuis un accès privilégié

3.1. Obtention des droits d’administration sur le système de fichiers avant tout…

Depuis un accès local et un accès utilisateur, le moyen probablement le plus simple est, à mon sens, d’exploiter le contenu du trousseau d’accès afin de tester tous les mots de passe identifiés sur les comptes ayant le privilège d’administration. La seconde solution est de rechercher au sein du système un éventuel mot de passe stocké dans un document, un script ou un classeur Excel. Une ultime solution est de tenter une élévation de privilèges à travers un exploit publié. Encore une fois, Metasploit et exploit-db.com facilitent cette opération en proposant des outils automatisés de compromission. En ce qui concerne les exploits permettant une élévation de privilèges, le constat est le même que pour les exploits distants : il n’existe que 44 exploits pour Mac OS X depuis 2003 (la moitié se basant sur une faille d’un logiciel tiers, l’autre moitié sur le système directement) contre 220 pour Windows depuis 2011 (la majorité se basant sur des failles de logiciels tiers).

Depuis un accès physique, aussi étonnant que cela puisse paraître, c’est une chose très simple à réaliser sous Mac OS X. En effet, plusieurs méthodes sont possibles.

La première consiste à activer le mode « Single » en appuyant sur les touches « ⌘ + S » au démarrage de la machine. L’attaquant obtient alors une invite de commande en root et sans mot de passe. À partir de cet accès, il est capable d’exécuter toutes les commandes d’administration désirées ainsi que d’extraire toutes les informations stockées sur le disque dur sauf si, bien évidemment, celui-ci a été partiellement ou intégralement chiffré.

Une alternative est d’utiliser le mode « Target » d’Apple (qui consiste à transformer le Mac en un disque Firewire via « T »), de démarrer le système sur un système tiers tel qu’une clé USB ou le PXE (via « ⌥ ») ou encore d’utiliser le mode Recovery (via « ⌘ + R ») disponible depuis Lion. Dans les trois cas, un accès au système de fichiers est possible sans restriction. D’autre part, Apple propose même dans le DVD d’installation une option de reset de mot de passe... sans commentaire.

Ces options de démarrage sont évidemment très utiles lors d'une analyse forensique nécessitant un accès au disque dur, mais peuvent cependant être exploitées à des fins malicieuses par un pirate.

Pour restreindre l’accès à des données sensibles, il est conseillé de chiffrer le répertoire utilisateur (sous Snow Leopard, avec FileVault, lors de la création d’un nouveau compte via le menu Préférences système > Comptes > + > Activer la protection FileVault) ou tout le disque dur (sous Lion, uniquement avec FileVault 2, via le menu Préférences système > Securité » > FileVault).

Pour empêcher l’utilisation de ces différents moyens d’accès, il faut définir un mot de passe à l’EFI (équivalent au BIOS en plus perfectionné) en utilisant l’outil Setregproptool disponible dans les packages sources d’installation de Mac OS X [5] ou depuis le mode « Recovery (Lion) » via le menu Utilitaires > Utilitaire de mot de passe du programme interne. Cependant, un moyen de contourner cette protection existe. En effet, il suffit de modifier la configuration matérielle (ex : changement de la taille d'une barrette de mémoire vive) pour que le mot de passe soit réinitialisé…

Une dernière alternative pour obtenir des droits root, un peu plus complexe à mettre en œuvre et présentée par la suite, consiste à exploiter les accès directs à la mémoire RAM.

3.2. Exemple de fuite de données techniques et personnelles

Évidemment, toutes les informations accessibles depuis un accès utilisateur et précédemment présentées sont également accessibles depuis un accès root avec en option la possibilité de cibler un utilisateur spécifique ou tous les utilisateurs du système. Des exemples de fuite d’informations depuis un accès root sont présentés dans le tableau ci-dessous.

Extraction des condensats des mots de passe du système	Commande	Sous Mountain Lion (Condensats stockés sous /private/var/db/dslocal/nodes/Default/users/<USERNAME>.plist): dscl . -read /Users/<USERNAME> ShadowHashData ou ./ml2john.py /private/var/db/dslocal/nodes/Default/users/<USERNAME>.plist \| cut -d ":" -f 2 Sous Lion, pour le premier utilisateur (Condensats stockés sous /private/var/db/dslocal/nodes/Default/users/<USERNAME>.plist): dscl . -read /Users/<USERNAME> ShadowHashData \| cut -f15-31 -d" " \| grep -v ShadowHashData \| tr -d " " et pour les autres utilisateurs : dscl . -read /Users/<USERNAME> ShadowHashData \| cut –f9-25 -d" " \| grep -v ShadowHashData \| tr -d " " Sous Snow Leopard : cat /var/db/shadow/hash/$(dscl localhost -read /Search/Users/<USERNAME> \| grep GeneratedUID \| cut -c15-) \| cut –c169-216
Sous Snow Leopard, Lion et Mountain Lion, les condensats des mots de passe (le nom d'utilisateur étant utilisé comme graine) sont respectivement stockés en SHA1, SHA512 et SHA512-PBKDF2 (avec 29069 itérations !). L’outil John the Ripper, à partir des condensats, est capable de tenter l’identification des mots de passe Mac OS X à partir des condensats par dictionnaire ou force brute. Identification du mot de passe de l'utilisateur « sudoman » Le succès du cassage dépendra évidemment de la complexité du mot de passe sachant que les condensats SHA512-PBKF2, sous Mountain Lion, sont extrêmement longs à casser, en l’occurrence 10 mots de passe par seconde (avec un Core i7 et 8Go de RAM)… un bon argument pour migrer sous cette version. Sous Mountain Lion, le script ml2john.py intégré dans la dernière version de John The Ripper [6] permet de récupérer les condensats et de les mettre au bon format pour être cassés par John The Ripper.
Extraction de tous les trousseaux d’accès	Stockage	/Users/<USERNAME>/Library/Keychains/login.keychain
Comme précédemment indiqué, le trousseau d’accès permet de stocker un nombre important de mots de passe. L’accès root à la machine permet ainsi de récupérer l’ensemble des trousseaux d’accès disponibles pour chacun des utilisateurs. Évidemment, si les utilisateurs n’ont pas changé le mot de passe de leur trousseau d’accès et si les mots de passe des utilisateurs système ont pu être identifiés au cours de l'étape précédente, l’accès au contenu des trousseaux d’accès est instantané. Toutefois, si ce n’est pas le cas, des logiciels tels que CrowbarKC [7] ou Passware Kit [8] sont capables de tenter l’identification du mot de passe protégeant le trousseau via une attaque par dictionnaire ou force brute. Identification du mot de passe d'un trousseau d'accès via CrowbarKC
Extraction des répertoires personnels chiffrés	Stockage	/Users/<USER>/<user>.sparsebundle
Comme BitLocker sous Microsoft, Apple propose nativement, via FileVault (AES128), la possibilité de chiffrer le répertoire personnel de chaque utilisateur (depuis Mac OS X 10.3) via un package « .sparsebundle ». L’accès root à la machine permet ainsi de récupérer l’ensemble des packages chiffrés pour chacun des utilisateurs et permet de tenter leur déchiffrement. Les mots de passe de (dé)chiffrement étant identiques à ceux configurés pour les mots de passe système, l’accès aux données en clair est facilité. Un autre moyen est de tenter des attaques par dictionnaire ou force brute via des outils tels que CrowbarDMG [9] ou Passware Kit.

Exemple de fuites d'informations depuis un accès privilégié

Les droits « root » sur un système Mac OS X permettent également d’extraire le contenu de la mémoire vive. Ce sujet est traité dans la section suivante.

4. Compromission et fuite d’informations depuis un accès à la mémoire RAM

4.1. Obtention d’une image de mémoire RAM

La mémoire RAM contient un nombre impressionnant de données sensibles souvent non inscrites sur le disque dur qui peuvent s'avérer très utiles tant lors d'une analyse forensique que lors d'un test d'intrusion.

Depuis un accès root à la machine, contrairement aux systèmes Linux classiques où il est possible d’accéder à la mémoire RAM à travers « /proc/kcore » ou « /dev/mem », sous Mac OS X cet accès n’est pas natif. Il est nécessaire d’installer un pilote pour pouvoir accéder au périphérique tant convoité… Des outils tels que MacMemoryReader [10] et MacMemoryze [11] permettent notamment d’automatiser ce processus et d’extraire au final une image brute de la mémoire RAM.

Depuis un accès physique, si la machine cible intègre un périphérique Firewire ou Thunderbolt (la majorité des Macbook actuels), l'accès direct à la mémoire RAM (accès DMA) est possible, et ce, quel que soit l’état de la machine (en veille, session, verrouillée, session ouverte, etc). Il suffit simplement à l’attaquant de connecter un câble Firewire entre sa machine et celle de la victime et de simuler un média de stockage Firewire (il est nécessaire d'utiliser un convertisseur Thunderbolt-Firewire si l'interface Thunderbolt est exploitée). L’accès en lecture à la mémoire RAM est alors possible depuis sa propre machine et à travers le câble Firewire. La bibliothèque Python libforensic1394[12] facilite grandement l’implémentation de scripts permettant de réaliser cette opération.

Une preuve de concept, sud0.MemDump.py, permettant d'extraire le contenu de la mémoire RAM à travers les accès DMA, est notamment disponible [13].

Pour empêcher l’utilisation des accès DMA, un moyen radical est de désactiver le pilote responsable de la prise en charge du périphérique Firewire via la commande suivante :

sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

4.2. Fuite de données techniques et personnelles

Ci-dessous sont présentés des exemples de données accessibles ainsi que les signatures possibles pour les identifier rapidement. L’utilisation de ces signatures nécessite tout d’abord d’extraire les chaînes de caractères de l’image brute extraite, via par exemple la commande strings.

Mots de passe des utilisateurs	Commande	cat dumpRAM.str \|grep -A 4 longname\|grep -B 1 -A 2 managedUser
Le mot de passe en clair des utilisateurs étant connectés (ou ayant été connectés) peut en effet être identifié depuis la mémoire RAM si la machine n’a pas été stoppée entre temps. Ainsi, le scénario le plus plausible à exploiter est d’extraire la mémoire RAM à travers l’interface Firewire alors que la machine à examiner est verrouillée. Accès garanti au système :). Une vidéo de cette exploitation est disponible sur Internet [14].
Clé AES 128 FileVault 2	Commande	./aeskeyfind –v dumpRAM.raw
En effet, les clés AES utilisées par FileVault 2 (depuis Lion 10.7 uniquement) pour chiffrer l’intégralité du système de fichiers sont stockées également dans la mémoire RAM. Les identifier manuellement n’est pas possible mais des chercheurs de l’université de Princeton ont trouvé un algorithme permettant d’identifier les éventuelles clés RSA et AES stockées en mémoire vive. Un outil se basant sur ces travaux a ainsi été développé, Aeskeyfind [15] ainsi qu’un second plus complet, Passware Kit, permettant d’une part l’identification de la clé et d’autre part le déchiffrement d’un disque chiffré à partir de la clé restaurée précédemment. En résumé, un MacBook verrouillé dont le disque est intégralement chiffré et sur lequel une interface Firewire ou Thunderbolt est présente n’est donc pas à l’abri d’être piraté… Pour limiter la compromission du système par ce biais, il est recommandé de forcer la mise en veille prolongée (mémoire RAM non alimentée) à la place de la mise en veille standard via la commande pmset -a hibernatemode=25 ainsi que d’activer la suppression de la clé AES lors d’une mise en veille de la machine (implique donc de connaître le mot de passe de pré-authentification FileVault 2 pour réveiller la machine) via la commande destroyfvkeyonstandby=1.
Mot de passe du trousseau d’accès	Commande	cat dumpRAM.str \| grep -i 'login.keychain' -A 5 \|grep -i 'tries' -A 4 \| grep -i 'password' -A 1
Dans le cas où l’utilisateur a changé le mot de passe de son trousseau d’accès (bonne pratique) et suite à la saisie de celui-ci pour déverrouiller le trousseau, le mot de passe est stocké en clair en mémoire RAM. Un attaquant serait donc en mesure d’ouvrir le trousseau de l’utilisateur s’il est parvenu à accéder au contenu de la mémoire RAM.
Mot de passe de domaine Microsoft	Expression régulière	voir PoC RAM_MacOSx_Cred-0.1.py
Si l’utilisateur a accédé manuellement (saisie du login et mot de passe) à des données via son compte de domaine (ex : serveurs de fichiers, webmail, etc.), alors les informations d’authentification sont disponibles en clair au sein de la mémoire RAM. Ainsi, un attaquant ayant un accès au contenu de la mémoire RAM serait en mesure d’usurper l’identité de la victime et d’exploiter les ressources disponibles sur le système d’information de l’entreprise.
Mots de passe Web	Expression régulière	Par exemple pour Facebook : *email=([^&]+)&pass=([^&]+).persistent=**
Comme sur les autres systèmes d’exploitation, la majorité des mots de passe saisis à travers un navigateur web sont stockés en clair en mémoire RAM. Un attaquant serait donc en mesure d’usurper l’identité d’un utilisateur et de provoquer notamment une importante fuite d’informations s’il est parvenu à accéder à la mémoire RAM. Deux PoC ont été développés pour identifier ces éléments. Le premier, RAM_Web_Cred-0.1.py [16], permet d’identifier les mots de passe des principaux sites web visités (soit 34 sites actuellement) alors que le second, RAM_MacOSx_Cred-0.1.py[17], est orienté sur les applications propres à Mac OS X. PoC pour identifier les mots de passe stockés en mémoire RAM

Exemple de fuites d'informations à travers la mémoire RAM

4.3. Contournement de la GUI d'authentification

Les interfaces Firewire et Thunderbolt permettent, comme indiqué précédemment, d’accéder en lecture à la mémoire RAM. L’accès en écriture est également possible par ce biais et permet d’une part de contourner l’authentification GUI de Mac OS X et d’autre part d’élever ses privilèges pour devenir root via la commande sudo.

Ces moyens d'accès sont notamment implémentées au sein de l’outil Inception [18], qui se base sur des signatures fixes (selon les versions) pour patcher directement en mémoire RAM les bibliothèques responsables de l’authentification.

Contournement de la GUI Mac OS X en quelques secondes

Ainsi, quel que soit l’état de la machine (session verrouillée, machine éteinte, machine sortant de veille, etc.), il est possible d’obtenir en quelques secondes (entre 15 et 30 secondes) un accès root via un simple câble Firewire… Cela peut notamment être très utile dans le cas d'une analyse forensique lorsqu'aucun authentifiant de la machine à inspecter n'est connu.

Toutefois, les nouvelles versions de Mac OS X (à partir de Lion 10.7.2), bloquent l’accès aux ports DMA dans certains cas, notamment lorsque Filevault est activé (système démarré, ouverture de session par liste d'utilisateurs, etc.). Plusieurs études complètes ont notamment été réalisées sur ce sujet [19] [20].

5. Fuite d'informations depuis Google

Aussi étonnant que cela puisse paraître, une recherche rapide sur Google en mode GHDB vous permettra d’identifier de nombreux serveurs ouverts en Directory Listing et stockant tout le répertoire d’un utilisateur Mac OS X, soit des documents personnels, des emails, des rendez-vous et… le trousseau d’accès de l’utilisateur.

Ainsi, pour exemple, 20 minutes suffisent à identifier un fichier trousseau d’accès « login.keychain », trouver le mot de passe associé, accéder au mot de passe d’un second trousseau d’accès (1Passwd.keychain), ouvrir ce dernier, identifier des mots de passe, ma foi, assez sympathiques (Facebook, Gmail, Twitter, Paypal, Amazon, etc.). En 20 minutes, il est ainsi possible de générer une fuite d’informations conséquentes pour un utilisateur ou une entreprise, et cela, sans difficulté technique particulière et sans utiliser de 0-day…

5.1. Pac4Mac, « Plug And Check for Mac OS X »

Pour ceux qui souhaiteront vérifier de manière automatisée le niveau de sécurité de leur système, sachez qu'un framework de Forensic, Pac4Mac, est en cours de conception et devrait être prochainement publié sur le site de XMCO [21].

Pac4Mac est un outil portable (d'où le « Plug » s'il est mis sur une clé USB) codé en Python capable d'automatiser la recherche de données sensibles sur Mac OS X et d'identifier les fuites d'informations possibles selon la configuration du système et les privilèges acquis. Pac4Mac intègre également des fonctionnalités d'analyse post-intrusive et de recherche rapide des traces d'une potentielle compromission. Le détail des possibilités offertes par l'outil peut être représenté sous cette forme :

Fonctions intégrées dans Pac4Mac

Pour des raisons de performance, Pac4Mac n'intègre pas d'interface graphique et se lance via le Terminal.

Conclusion

À la question « Est-ce qu’une configuration par défaut suffit à protéger les utilisateurs d’une éventuelle fuite d’informations », la réponse est bien évidemment « non ». Comme vous avez pu le constater, les possibilités offertes par un attaquant sont nombreuses et cela est plutôt effrayant. D'autre part, une investigation numérique menée sur un système Mac OS X se révèle être très simple à mener étant donné les nombreux accès natifs configurés par défaut. Malheureusement, ces derniers peuvent être exploités à des fins malveillantes par des pirates dont leur but est d'extraire des informations sensibles.

Il est par contre important de noter que tous les risques présentés en termes de fuite d’informations peuvent être largement résorbés en suivant les bonnes pratiques de sécurisation d’un système Mac OS X [22] [23]. Après un durcissement du système, le niveau de sécurité de Mac OS X est presque aussi bon que celui d’un système Windows 7 configuré par défaut. Eh oui, contrairement à beaucoup de rumeurs, Mac n’est pas plus sécurisé que Windows 7 en termes de fuites d’informations, il l’est en fait beaucoup moins…