Malwares ciblant les systèmes macOS

1. Historique

Les ordinateurs Apple ont plusieurs fois changé de type processeurs. De 1984 à 1994, la première génération d’ordinateur Apple utilisait des processeurs Motora (série 68000). Puis de 1994 à 2005, la seconde génération d’ordinateurs a utilisé des processeurs PowerPC. En 2005, Apple a basculé des processeurs PowerPC vers des processeurs Intel (x86-64). En 2020, Apple a finalement basculé sur des processeurs ARM conçus en interne par l’éditeur.

Ce tableau résume les principales versions de macOS depuis 1984. Certaines versions du système d’exploitation supportaient plusieurs versions de processeurs pour faciliter la transition.

À l’écriture de ce livre, la version la plus récente de macOS est Sequoia, sortie en juin 2024.

2. Architecture

Le système d’exploitation macOS est un système UNIX composé de plusieurs couches placé au-dessus du matériel. Le schéma suivant synthétise ces couches :

Matériel

Cette couche ne fait pas partie du système d’exploitation à proprement dit. Mais tous les systèmes d’exploitation fonctionnent sur du matériel, elle représente tous les aspects physiques du terminal : processeur, mémoire, connexions, etc.

Core OS

La première couche...

1. Contraintes matérielles

Afin de pouvoir analyser, installer et manipuler du code malveillant pour macOS, nous avons besoin d’un laboratoire d’analyse. Un malware ne doit jamais être exécuté sur son vrai environnement de travail.

Comme expliqué au début de ce chapitre, macOS fonctionne avec un processeur Intel ou ARM. Une machine physique Intel fera tourner une machine virtuelle Intel et une machine physique ARM fera tourner une machine virtuelle ARM. Le croisement d’architecture processeur est possible grâce à l’émulation, mais les performances sont fortement impactées.

Dans ce chapitre, nous utiliserons une machine Windows avec un processeur Intel, et nous créerons une machine virtuelle macOS Intel. La limitation de cette approche est que nous ne pourrons exécuter que des binaires Intel (ou des binaires universels contenant des versions Intel de l’application).

Si vous disposez d’un ordinateur Apple avec un processeur ARM (M1, M2 ou M3), le logiciel gratuit UTM (https://mac.getutm.app/) peut être utilisé pour créer des machines macOS virtuelles ARM.

2. Configuration de VirtualBox

Tout comme pour l’analyse de malwares sous Windows, nous utiliserons l’hyperviseur gratuit VirtualBox librement téléchargeable à l’adresse suivante :...

1. Analyse statique avec Ghidra

Ghidra est un outil d’analyse statique libre qui a été décrit dans le chapitre Reverse engineering. Il est téléchargeable à l’adresse suivante : https://ghidra-sre.org/. Nous ne reviendrons pas sur son utilisation, mais sur les spécificités liées à macOS.

À l’ouverture d’un binaire universel, Ghidra affiche que plusieurs fichiers sont présents dans le fichier à analyser et propose de l’analyser comme un simple fichier ou en mode Batch.

Lorsque nous choisissons le mode Batch, nous pouvons voir les architectures présentes dans le binaire (ARM et Intel) :

Nous pouvons analyser les deux architectures ou seulement une. Il est préférable de choisir l’architecture avec laquelle nous sommes le plus à l’aise. Si le binaire n’est pas un binaire universel, il ne contient qu’une seule architecture et nous n’aurons malheureusement pas le choix.

2. Langage C et C++

Le développeur peut faire le choix de développer son malware en C ou C++. Dans ce cas-là, l’analyse est proche d’une analyse d’un binaire Windows. L’API est identique à l’API C utilisée par Windows ou même Linux. Les outils d’analyse tels que Ghidra n’ont pas de difficulté à analyser ces binaires et à générer du pseudo-code.

3. Langage Swift

Le langage Swift est le plus récent langage de développement proposé par Apple. Voici un exemple de code :

// déclaration d'une fonction 
func greet() { 
  print("Hello World!") 
} 
// appelle de la fonction 
greet() 

L’analyse de malwares développés en Swift est particulièrement compliquée. Pour illustrer ce propos, nous avons analysé un malware compilé à partir d’un projet libre : SwiftBelt. Le code source est disponible sur GitHub : https://github.com/cedowens/SwiftBelt/blob/master/Sources/SwiftBelt/main.swift. Voici le hash du binaire compilé : 71198a8e8b846d61c37954eb5577420f.

En ouvrant le fichier dans Ghidra nous pouvons voir que les symboles sont plus ou moins conservés comme nous pouvons le voir dans cette image :...

1. Introduction

Le malware CloudMensis est utilisé par le groupe d’attaquants APT37. Ce groupe est actif depuis 2012 et semble lié à la Corée du Nord. Ce malware cible le système d’exploitation macOS. C’est un binaire universel compilé pour les architectures Intel et ARM. Pour faciliter la lecture de ce chapitre, nous analyserons la version Intel. CloudMensis est un malware qui permet à l’attaquant d’administrer les machines compromises à distance. Il a la spécificité d’utiliser des fournisseurs de cloud comme serveurs de contrôles.

2. Persistance

Le malware est divisé en deux binaires, le premier met en place en place la persistance et télécharge le second binaire. Le second binaire est le malware CloudMensis. Voici le hash MD5 du premier malware : 01c0b7c5bf605ed267b2be3d024eb90f.

Ce binaire n’a que deux classes : AppDelegate et pCloud :

Le point d’entrée du binaire charge la classe AppDelegate (ligne 10) et exécute la méthode start (ligne 13).

Le but de la méthode start est de mettre en place une persistance pour démarrer le malware. Un agent est défini en créant le fichier /Library/LaunchDaemons/.com.apple.WindowServer.plist. Le but de ce fichier est d’exécuter le fichier /Library/WebServer/share/httpd/manual/WindowServer préalablement téléchargé. Il est intéressant de noter que le fichier .plist commence par un point. Ce sont les fichiers cachés sous UNIX. Ils ne sont pas affichés par défaut avec la commande ls, l’option -a doit être ajoutée pour lister les fichiers cachés.

L’image suivante montre la création du fichier .com.apple.WindowServer.plist (ligne 49) avec l’utilisation de l’API writeToFile. Dans les lignes précédentes, nous voyons la création du contenu XML du fichier avec les champs RunAtLoad (ligne 46), SessionCreate (ligne 42), ProgramArguments (ligne 48) ainsi que le chemin du binaire à exécuter (ligne 29) :

La seconde étape consiste à télécharger CloudMensis. Le malware va alors instancier une classe appelée pCloud (ligne 51), puis exécuter...