* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Mach utilise des **tâches** comme **unité la plus petite** pour partager des ressources, et chaque tâche peut contenir **plusieurs threads**. Ces **tâches et threads sont mappés 1:1 sur les processus et threads POSIX**.
La communication entre les tâches se fait via la communication inter-processus (IPC) de Mach, en utilisant des canaux de communication unidirectionnels. **Les messages sont transférés entre les ports**, qui agissent comme des **files d'attente de messages** gérées par le noyau.
Les droits de port, qui définissent les opérations qu'une tâche peut effectuer, sont essentiels à cette communication. Les **droits de port** possibles sont :
* **Droit de réception**, qui permet de recevoir des messages envoyés au port. Les ports Mach sont des files d'attente MPSC (multiple-producteur, unique-consommateur), ce qui signifie qu'il ne peut y avoir qu'un seul droit de réception pour chaque port dans tout le système (contrairement aux pipes, où plusieurs processus peuvent tous détenir des descripteurs de fichier pour l'extrémité de lecture d'un pipe).
* Une **tâche avec le droit de réception** peut recevoir des messages et **créer des droits d'envoi**, lui permettant d'envoyer des messages. À l'origine, seule la **propre tâche a le droit de réception sur son port**.
* **Droit d'envoi**, qui permet d'envoyer des messages au port.
* **Droit d'envoi unique**, qui permet d'envoyer un message au port puis de disparaître.
* **Droit d'ensemble de ports**, qui indique un _ensemble de ports_ plutôt qu'un seul port. Le défilement d'un message à partir d'un ensemble de ports défile un message à partir de l'un des ports qu'il contient. Les ensembles de ports peuvent être utilisés pour écouter plusieurs ports simultanément, un peu comme `select`/`poll`/`epoll`/`kqueue` dans Unix.
* **Nom mort**, qui n'est pas un droit de port réel, mais simplement un espace réservé. Lorsqu'un port est détruit, tous les droits de port existants sur le port deviennent des noms morts.
**Les tâches peuvent transférer des droits d'ENVOI à d'autres**, leur permettant d'envoyer des messages en retour. **Les droits d'ENVOI peuvent également être clonés, de sorte qu'une tâche peut dupliquer et donner le droit à une troisième tâche**. Cela, combiné à un processus intermédiaire connu sous le nom de **serveur d'amorçage**, permet une communication efficace entre les tâches.
1. La tâche **A** initie un **nouveau port**, obtenant un **droit de réception** dans le processus.
2. La tâche **A**, étant le détenteur du droit de réception, **génère un droit d'envoi pour le port**.
3. La tâche **A** établit une **connexion** avec le **serveur d'amorçage**, fournissant le **nom de service du port** et le **droit d'envoi** via une procédure connue sous le nom d'enregistrement d'amorçage.
4. La tâche **B** interagit avec le **serveur d'amorçage** pour exécuter une **recherche d'amorçage pour le service**. Si elle réussit, le **serveur duplique le droit d'envoi** reçu de la tâche A et **le transmet à la tâche B**.
5. Après avoir acquis un droit d'envoi, la tâche **B** est capable de **formuler** un **message** et de l'envoyer **à la tâche A**.
Le serveur d'amorçage ne peut pas authentifier le nom de service revendiqué par une tâche. Cela signifie qu'une **tâche** pourrait potentiellement **usurper n'importe quelle tâche système**, en revendiquant faussement un nom de service d'autorisation, puis en approuvant chaque demande.
Ensuite, Apple stocke les **noms des services fournis par le système** dans des fichiers de configuration sécurisés, situés dans des répertoires protégés par SIP : `/System/Library/LaunchDaemons` et `/System/Library/LaunchAgents`. À côté de chaque nom de service, le **binaire associé est également stocké**. Le serveur d'amorçage créera et conservera un **droit de réception pour chacun de ces noms de service**.
Pour ces services prédéfinis, le **processus de recherche diffère légèrement**. Lorsqu'un nom de service est recherché, launchd démarre le service de manière dynamique. Le nouveau flux de travail est le suivant :
* La tâche **B** initie une **recherche d'amorçage** pour un nom de service.
* **launchd** vérifie si la tâche est en cours d'exécution et si ce n'est pas le cas, **la démarre**.
* La tâche **A** (le service) effectue un **enregistrement de vérification d'amorçage**. Ici, le **serveur d'amorçage crée un droit d'envoi, le retient et transfère le droit de réception à la tâche A**.
* launchd duplique le **droit d'envoi et l'envoie à la tâche B**.
Cependant, ce processus ne s'applique qu'aux tâches système prédéfinies. Les tâches non système fonctionnent toujours comme décrit initialement, ce qui pourrait potentiellement permettre l'usurpation.
Notez comment l'**expéditeur** **alloue** un port, crée un **droit d'envoi** pour le nom `org.darlinghq.example` et l'envoie au **serveur d'amorçage** tandis que l'expéditeur a demandé le **droit d'envoi** de ce nom et l'a utilisé pour **envoyer un message**.
* **Port hôte**: Si un processus a le privilège **Envoyer** sur ce port, il peut obtenir des **informations** sur le **système** (par exemple, `host_processor_info`).
* **Port privilégié hôte**: Un processus avec le droit **Envoyer** sur ce port peut effectuer des actions **privilégiées** comme charger une extension de noyau. Le **processus doit être root** pour obtenir cette permission.
* De plus, pour appeler l'API **`kext_request`**, il est nécessaire d'avoir l'entitlement **`com.apple.private.kext`**, qui n'est donné qu'aux binaires Apple.
* **Port de nom de tâche**: Une version non privilégiée du _port de tâche_. Il fait référence à la tâche, mais ne permet pas de la contrôler. La seule chose qui semble être disponible à travers elle est `task_info()`.
* **Port de tâche** (alias port de noyau)**:** Avec la permission Envoyer sur ce port, il est possible de contrôler la tâche (lire/écrire la mémoire, créer des threads...).
* Appelez `mach_task_self()` pour **obtenir le nom** de ce port pour la tâche appelante. Ce port n'est **hérité** qu'à travers **`exec()`**; une nouvelle tâche créée avec `fork()` obtient un nouveau port de tâche (dans un cas particulier, une tâche obtient également un nouveau port de tâche après avoir exécuté un binaire suid). La seule façon de lancer une tâche et d'obtenir son port est d'effectuer la ["danse d'échange de port"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) tout en faisant un `fork()`.
* Voici les restrictions d'accès au port (à partir de `macos_task_policy` du binaire `AppleMobileFileIntegrity`):
* Si l'application a l'entitlement **`com.apple.security.get-task-allow`**, les processus de l'**utilisateur peuvent accéder au port de tâche** (communément ajouté par Xcode pour le débogage). Le processus de **notarisation** ne le permettra pas pour les versions de production.
* Les applications ayant l'entitlement **`com.apple.system-task-ports`** peuvent obtenir le **port de tâche pour n'importe quel** processus, sauf le noyau. Dans les versions plus anciennes, il était appelé **`task_for_pid-allow`**. Cela n'est accordé qu'aux applications Apple.
* **Root peut accéder aux ports de tâche** des applications **non** compilées avec un **runtime renforcé** (et non pas d'Apple).
Le fichier `entitlements.plist` est un fichier de configuration qui spécifie les autorisations et les privilèges accordés à une application macOS. Il est utilisé pour définir les capacités de l'application, telles que l'accès aux fichiers, aux services système et aux ressources réseau. Les développeurs peuvent inclure ce fichier dans leur application pour spécifier les autorisations nécessaires pour que l'application fonctionne correctement.
Les autorisations spécifiées dans le fichier `entitlements.plist` sont vérifiées par le système d'exploitation lors de l'exécution de l'application. Si l'application tente d'accéder à une ressource pour laquelle elle n'a pas les autorisations nécessaires, elle sera bloquée.
Les développeurs peuvent également utiliser le fichier `entitlements.plist` pour activer des fonctionnalités spéciales, telles que l'accès à des fonctionnalités de débogage ou la possibilité d'exécuter des scripts shell. Cependant, l'utilisation de ces fonctionnalités peut également introduire des vulnérabilités de sécurité dans l'application.
Il est important de noter que le fichier `entitlements.plist` peut également être utilisé pour restreindre les autorisations d'une application, ce qui peut aider à renforcer la sécurité de l'application et à réduire les risques de fuite de données ou d'escalade de privilèges.
**Compilez** le programme précédent et ajoutez les **droits** nécessaires pour pouvoir injecter du code avec le même utilisateur (sinon vous devrez utiliser **sudo**).
Dans macOS, les **threads** peuvent être manipulés via **Mach** ou en utilisant l'API **posix `pthread`**. Le thread que nous avons généré dans l'injection précédente a été généré en utilisant l'API Mach, donc **il n'est pas conforme à posix**.
Il était possible d'**injecter un simple shellcode** pour exécuter une commande car il **n'avait pas besoin de travailler avec des API conformes à posix**, seulement avec Mach. Des injections **plus complexes** nécessiteraient que le **thread** soit également **conforme à posix**.
 Par conséquent, pour **améliorer le shellcode**, il devrait appeler **`pthread_create_from_mach_thread`** qui va **créer un pthread valide**. Ensuite, ce nouveau pthread pourrait **appeler dlopen** pour **charger notre dylib** à partir du système.
XPC, qui signifie Communication inter-processus XNU (le noyau utilisé par macOS), est un framework pour la **communication entre processus** sur macOS et iOS. XPC fournit un mécanisme pour effectuer des **appels de méthode asynchrones et sûrs entre différents processus** sur le système. C'est une partie du paradigme de sécurité d'Apple, permettant la **création d'applications à privilèges séparés** où chaque **composant** s'exécute avec **seulement les autorisations dont il a besoin** pour faire son travail, limitant ainsi les dommages potentiels d'un processus compromis.
XPC utilise une forme de communication inter-processus (IPC), qui est un ensemble de méthodes pour que différents programmes s'exécutant sur le même système puissent s'envoyer des données.
1.**Sécurité** : En séparant le travail en différents processus, chaque processus peut se voir accorder uniquement les autorisations dont il a besoin. Cela signifie que même si un processus est compromis, il a une capacité limitée à causer des dommages.
2.**Stabilité** : XPC aide à isoler les plantages dans le composant où ils se produisent. Si un processus plante, il peut être redémarré sans affecter le reste du système.
3.**Performance** : XPC permet une concurrence facile, car différentes tâches peuvent être exécutées simultanément dans différents processus.
Le seul **inconvénient** est que **séparer une application en plusieurs processus** les faisant communiquer via XPC est **moins efficace**. Mais dans les systèmes d'aujourd'hui, cela n'est presque pas perceptible et les avantages sont bien meilleurs.
Un exemple peut être vu dans QuickTime Player, où un composant utilisant XPC est responsable du décodage vidéo. Le composant est spécifiquement conçu pour effectuer des tâches de calcul, ainsi, en cas de violation, il ne fournirait pas de gains utiles à l'attaquant, tels que l'accès aux fichiers ou au réseau.
Les composants XPC d'une application sont **à l'intérieur de l'application elle-même**. Par exemple, dans Safari, vous pouvez les trouver dans **`/Applications/Safari.app/Contents/XPCServices`**. Ils ont l'extension **`.xpc`** (comme **`com.apple.Safari.SandboxBroker.xpc`**) et sont **également des bundles** avec le binaire principal à l'intérieur : `/Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/MacOS/com.apple.Safari.SandboxBroker`
Comme vous pouvez le penser, un **composant XPC aura des autorisations et des privilèges différents** des autres composants XPC ou du binaire principal de l'application. SAUF si un service XPC est configuré avec [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information\_property\_list/xpcservice/joinexistingsession) défini sur "True" dans son fichier **Info.plist**. Dans ce cas, le service XPC s'exécutera dans la même session de sécurité que l'application qui l'a appelé.
Les services XPC sont **démarrés** par **launchd** lorsque cela est nécessaire et **arrêtés** une fois que toutes les tâches sont **terminées** pour libérer les ressources système. **Les composants XPC spécifiques à l'application ne peuvent être utilisés que par l'application**, réduisant ainsi le risque associé aux vulnérabilités potentielles.
Les **services XPC à l'échelle du système** sont accessibles à tous les utilisateurs. Ces services, soit launchd soit de type Mach, doivent être **définis dans des fichiers plist** situés dans des répertoires spécifiés tels que **`/System/Library/LaunchDaemons`**, **`/Library/LaunchDaemons`**, **`/System/Library/LaunchAgents`** ou **`/Library/LaunchAgents`**.
Ces fichiers plist auront une clé appelée **`MachServices`** avec le nom du service, et une clé appelée **`Program`** avec le chemin d'accès au binaire :
Ceux dans **`LaunchDameons`** sont exécutés par root. Donc, si un processus non privilégié peut communiquer avec l'un d'entre eux, il pourrait être capable d'escalader les privilèges.
Les applications peuvent **s'abonner** à différents **messages d'événements**, leur permettant d'être **initiées à la demande** lorsque de tels événements se produisent. La **configuration** de ces services est effectuée dans des fichiers **plist de launchd**, situés dans les **mêmes répertoires que les précédents** et contenant une clé supplémentaire **`LaunchEvent`**.
Lorsqu'un processus essaie d'appeler une méthode via une connexion XPC, le **service XPC doit vérifier si ce processus est autorisé à se connecter**. Voici les moyens courants de vérifier cela et les pièges courants :
Apple permet également aux applications de **configurer certains droits et la manière de les obtenir** afin que si le processus appelant les possède, il serait **autorisé à appeler une méthode** du service XPC :
macOS utilise plusieurs mécanismes pour permettre la communication inter-processus (IPC) entre les processus. Les deux principaux mécanismes sont les sockets de domaine Unix et les connexions XPC.
## XPC
XPC est un framework d'Apple qui permet la communication inter-processus. Il est utilisé par de nombreux processus système et applications tierces. Les connexions XPC sont établies entre un client et un démon. Le client envoie des messages au démon et le démon répond avec des messages.
### XPC Endpoint
Un point de terminaison XPC est un objet qui représente un processus qui peut recevoir des messages XPC. Un point de terminaison XPC est créé en appelant la fonction `xpc_endpoint_create()`.
```c
xpc_endpoint_t xpc_endpoint_create(void);
```
### XPC Connection
Une connexion XPC est un objet qui représente une connexion entre un client et un démon. Une connexion XPC est créée en appelant la fonction `xpc_connection_create()`.
Le paramètre `name` est le nom du démon avec lequel la connexion doit être établie. Le paramètre `targetq` est la file d'attente sur laquelle les messages reçus doivent être traités.
### XPC Message
Un message XPC est un objet qui représente un message envoyé entre un client et un démon. Un message XPC est créé en appelant la fonction `xpc_dictionary_create()`.
Le paramètre `keys` est un tableau de chaînes de caractères représentant les clés du dictionnaire. Le paramètre `values` est un tableau d'objets XPC représentant les valeurs du dictionnaire. Le paramètre `count` est le nombre d'éléments dans les tableaux `keys` et `values`.
### Envoyer un message XPC
Pour envoyer un message XPC, vous devez d'abord créer une connexion XPC en appelant `xpc_connection_create()`. Ensuite, vous devez configurer la connexion en appelant `xpc_connection_set_event_handler()` pour spécifier la fonction de rappel qui sera appelée lorsque des messages seront reçus.
Le paramètre `message` est l'objet XPC représentant le message à envoyer.
### Recevoir un message XPC
Pour recevoir des messages XPC, vous devez configurer la connexion XPC en appelant `xpc_connection_set_event_handler()` pour spécifier la fonction de rappel qui sera appelée lorsque des messages seront reçus.
Dans cet exemple, nous créons une connexion XPC avec le démon `com.example.demo`. Nous configurons la connexion pour appeler la fonction de rappel `handler()` lorsque des messages sont reçus. Nous envoyons ensuite un message XPC au démon en spécifiant la commande `hello`. La réponse du démon est affichée dans la fonction de rappel `handler()`.
Le fichier `xyz.hacktricks.service.plist` est un fichier de configuration de service qui peut être utilisé pour lancer un service personnalisé sur macOS. Il est généralement placé dans `/Library/LaunchDaemons/` ou `/Library/LaunchAgents/` et est lu par le démon `launchd` lors du démarrage du système ou lorsqu'un utilisateur se connecte.
Le fichier plist contient des informations sur le service, telles que son nom, son chemin d'accès, ses arguments de ligne de commande, son utilisateur et son groupe, ainsi que des informations sur la façon dont le service doit être géré par `launchd`.
Pour créer un service personnalisé, vous pouvez créer un fichier plist avec les informations nécessaires, le placer dans le répertoire approprié et charger le service avec la commande `launchctl load`.
Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other and synchronize their actions. macOS provides several IPC mechanisms that can be used by processes to communicate with each other. In this section, we will discuss some of the most commonly used IPC mechanisms in macOS.
## Mach Ports
Mach ports are a type of IPC mechanism that is used by macOS to implement inter-process communication. Mach ports are endpoints that can be used by processes to send and receive messages. Each Mach port has a unique identifier that is used to identify the port. Processes can create Mach ports and use them to communicate with other processes.
Mach ports can be used for various purposes, such as:
- Sending messages between processes
- Sharing memory between processes
- Synchronizing actions between processes
Mach ports can be created using the `mach_port_allocate()` function. Once a Mach port is created, it can be used to send and receive messages using the `mach_msg()` function.
## XPC
XPC is a high-level IPC mechanism that is used by macOS to implement inter-process communication. XPC provides a simple and secure way for processes to communicate with each other. XPC is based on a client-server model, where the client sends requests to the server and the server responds to the requests.
XPC provides several benefits over other IPC mechanisms, such as:
- Automatic serialization and deserialization of messages
- Automatic memory management
- Automatic error handling
- Sandboxing support
XPC can be used for various purposes, such as:
- Launching and managing daemons
- Sharing data between processes
- Synchronizing actions between processes
XPC can be used in both Objective-C and Swift applications. XPC APIs are available in the `xpc` framework.
## Distributed Objects
Distributed Objects is an IPC mechanism that is used by macOS to implement inter-process communication. Distributed Objects allows objects to be shared between processes. Distributed Objects is based on the Remote Procedure Call (RPC) model, where a client sends a message to a server and the server responds to the message.
Distributed Objects provides several benefits over other IPC mechanisms, such as:
- Automatic serialization and deserialization of messages
- Automatic memory management
- Support for distributed garbage collection
- Support for distributed notifications
Distributed Objects can be used for various purposes, such as:
- Sharing objects between processes
- Synchronizing actions between processes
- Implementing distributed applications
Distributed Objects can be used in both Objective-C and Swift applications. Distributed Objects APIs are available in the `Foundation` framework.
## Conclusion
In this section, we discussed some of the most commonly used IPC mechanisms in macOS. Mach ports, XPC, and Distributed Objects are all powerful IPC mechanisms that can be used by processes to communicate with each other and synchronize their actions. When choosing an IPC mechanism, it is important to consider the specific requirements of the application and choose the mechanism that best meets those requirements.
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
