* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Mensagens Mach via Portas
O Mach usa **tarefas** como a **unidade menor** para compartilhar recursos, e cada tarefa pode conter **várias threads**. Essas **tarefas e threads são mapeadas 1:1 para processos e threads POSIX**.
A comunicação entre tarefas ocorre via Comunicação Interprocesso (IPC) do Mach, utilizando canais de comunicação unidirecionais. **As mensagens são transferidas entre portas**, que atuam como **filas de mensagens** gerenciadas pelo kernel.
Os direitos de porta, que definem quais operações uma tarefa pode executar, são fundamentais para essa comunicação. Os possíveis **direitos de porta** são:
* **Direito de recebimento**, que permite receber mensagens enviadas para a porta. As portas Mach são filas MPSC (múltiplos produtores, um único consumidor), o que significa que pode haver apenas **um direito de recebimento para cada porta** em todo o sistema (ao contrário dos pipes, onde vários processos podem ter descritores de arquivo para a extremidade de leitura de um pipe).
* Uma **tarefa com o direito de recebimento** pode receber mensagens e **criar direitos de envio**, permitindo que ela envie mensagens. Originalmente, apenas a **própria tarefa tem o direito de recebimento sobre sua porta**.
* **Direito de conjunto de porta**, que denota um _conjunto de porta_ em vez de uma única porta. Desenfileirar uma mensagem de um conjunto de portas desenfileira uma mensagem de uma das portas que ele contém. Os conjuntos de portas podem ser usados para ouvir várias portas simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
* **Nome morto**, que não é um direito de porta real, mas apenas um espaço reservado. Quando uma porta é destruída, todos os direitos de porta existentes para a porta se transformam em nomes mortos.
**As tarefas podem transferir direitos de ENVIO para outros**, permitindo que eles enviem mensagens de volta. **Os direitos de ENVIO também podem ser clonados, para que uma tarefa possa duplicar e dar o direito a uma terceira tarefa**. Isso, combinado com um processo intermediário conhecido como **servidor de inicialização**, permite uma comunicação eficaz entre tarefas.
1. A tarefa **A** inicia uma **nova porta**, obtendo um **direito de RECEBIMENTO** no processo.
2. A tarefa **A**, sendo a detentora do direito de RECEBIMENTO, **gera um direito de ENVIO para a porta**.
3. A tarefa **A** estabelece uma **conexão** com o **servidor de inicialização**, fornecendo o **nome do serviço da porta** e o **direito de ENVIO** por meio de um procedimento conhecido como registro de inicialização.
4. A tarefa **B** interage com o **servidor de inicialização** para executar uma **busca de inicialização para o serviço**. Se bem-sucedido, o **servidor duplica o direito de ENVIO** recebido da Tarefa A e **o transmite para a Tarefa B**.
5. Ao adquirir um direito de ENVIO, a tarefa **B** é capaz de **formular** uma **mensagem** e enviá-la **para a tarefa A**.
O servidor de inicialização **não pode autenticar** o nome do serviço reivindicado por uma tarefa. Isso significa que uma **tarefa** poderia potencialmente **se passar por qualquer tarefa do sistema**, como falsamente **reivindicar um nome de serviço de autorização** e, em seguida, aprovar todas as solicitações.
Então, a Apple armazena os **nomes dos serviços fornecidos pelo sistema** em arquivos de configuração seguros, localizados em diretórios protegidos pelo SIP: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Ao lado de cada nome de serviço, o **binário associado também é armazenado**. O servidor de inicialização criará e manterá um **direito de RECEBIMENTO para cada um desses nomes de serviço**.
Para esses serviços predefinidos, o **processo de busca difere ligeiramente**. Quando um nome de serviço está sendo procurado, o launchd inicia o serviço dinamicamente. O novo fluxo de trabalho é o seguinte:
* A tarefa **A** (o serviço) realiza um **check-in de inicialização**. Aqui, o **servidor de inicialização cria um direito de ENVIO, o retém e transfere o direito de RECEBIMENTO para a tarefa A**.
* launchd duplica o **direito de ENVIO e o envia para a tarefa B**.
No entanto, esse processo se aplica apenas a tarefas predefinidas do sistema. As tarefas não do sistema ainda operam como descrito originalmente, o que poderia permitir a falsificação.
Observe como o **remetente****aloca** uma porta, cria um **direito de envio** para o nome `org.darlinghq.example` e o envia para o **servidor de inicialização** enquanto o remetente solicitou o **direito de envio** desse nome e o usou para **enviar uma mensagem**.
O arquivo `sender.c` é um exemplo de um processo que envia mensagens IPC para outro processo. Ele usa a função `msgsnd()` para enviar uma mensagem para a fila de mensagens IPC. A mensagem é composta por uma estrutura `msgbuf` que contém um tipo de mensagem e um corpo de mensagem. O tipo de mensagem é usado pelo receptor para identificar o tipo de mensagem que está recebendo. O corpo da mensagem pode conter qualquer dado que o remetente deseje enviar.
O processo remetente deve primeiro obter a chave da fila de mensagens IPC usando a função `ftok()`. Em seguida, ele deve criar a fila de mensagens IPC usando a função `msgget()`. Depois disso, ele pode enviar mensagens para a fila usando a função `msgsnd()`.
O código a seguir mostra como enviar uma mensagem IPC usando a função `msgsnd()`:
Este código cria uma mensagem IPC com um tipo de mensagem de 1 e um corpo de mensagem especificado pelo segundo argumento da linha de comando. Ele envia a mensagem para a fila de mensagens IPC identificada pela chave especificada pelo primeiro argumento da linha de comando.
Port stealing is a technique that allows a process to take control of another process's task port. This can be used to elevate privileges or to bypass sandbox restrictions.
The basic idea is to create a new task with `fork()` and then perform the ["port swap dance"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) to replace the new task's task port with the target process's task port. Once this is done, the new task can control the target process.
O arquivo `entitlements.plist` é um arquivo de propriedades que contém informações sobre as permissões e recursos que um aplicativo tem acesso. Ele é usado pelo macOS para verificar se um aplicativo tem permissão para acessar determinados recursos do sistema, como a câmera, o microfone ou a localização do usuário.
Os desenvolvedores podem especificar as permissões necessárias para seus aplicativos no arquivo `entitlements.plist`. Essas permissões são verificadas pelo sistema operacional quando o aplicativo é executado e, se o aplicativo não tiver as permissões necessárias, ele não poderá acessar os recursos correspondentes.
Os arquivos `entitlements.plist` são assinados digitalmente pelo desenvolvedor do aplicativo e verificados pelo sistema operacional durante a instalação do aplicativo. Isso garante que o arquivo não tenha sido modificado por terceiros e que as permissões especificadas sejam confiáveis.
Os arquivos `entitlements.plist` podem ser usados por atacantes para identificar quais permissões um aplicativo tem e quais recursos ele pode acessar. Isso pode ser útil para um atacante que está tentando explorar uma vulnerabilidade no aplicativo ou no sistema operacional.
Os arquivos `entitlements.plist` podem ser encontrados em vários locais no sistema de arquivos do macOS, incluindo dentro de pacotes de aplicativos e frameworks. Eles podem ser visualizados e editados usando o Xcode ou um editor de texto simples.
**Compile** o programa anterior e adicione as **permissões** para poder injetar código com o mesmo usuário (caso contrário, você precisará usar o **sudo**).
No macOS, as **threads** podem ser manipuladas via **Mach** ou usando a **API posix `pthread`**. A thread gerada na injeção anterior foi gerada usando a API Mach, portanto, **não é compatível com posix**.
Foi possível **injetar um shellcode simples** para executar um comando porque ele **não precisava trabalhar com APIs compatíveis com posix**, apenas com Mach. **Injeções mais complexas** precisariam que a **thread** também fosse **compatível com posix**.
Portanto, para **melhorar o shellcode**, ele deve chamar **`pthread_create_from_mach_thread`**, que irá **criar um pthread válido**. Em seguida, este novo pthread pode **chamar dlopen** para **carregar nossa dylib** do sistema.
XPC, que significa Comunicação Interprocessos XNU (o kernel usado pelo macOS), é um framework para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método assíncronas seguras entre diferentes processos** no sistema. É uma parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos separados por privilégios** onde cada **componente** é executado com **apenas as permissões necessárias** para fazer seu trabalho, limitando assim o potencial de danos de um processo comprometido.
O XPC usa uma forma de Comunicação Interprocessos (IPC), que é um conjunto de métodos para diferentes programas em execução no mesmo sistema para enviar dados de ida e volta.
1.**Segurança**: Ao separar o trabalho em diferentes processos, cada processo pode receber apenas as permissões necessárias. Isso significa que mesmo que um processo seja comprometido, ele tem capacidade limitada de causar danos.
2.**Estabilidade**: O XPC ajuda a isolar falhas no componente onde elas ocorrem. Se um processo falhar, ele pode ser reiniciado sem afetar o restante do sistema.
3.**Desempenho**: O XPC permite fácil concorrência, pois diferentes tarefas podem ser executadas simultaneamente em diferentes processos.
A única **desvantagem** é que **separar um aplicativo em vários processos** fazendo com que eles se comuniquem via XPC é **menos eficiente**. Mas nos sistemas de hoje isso é quase imperceptível e os benefícios são muito melhores.
Um exemplo pode ser visto no QuickTime Player, onde um componente que usa XPC é responsável pela decodificação de vídeo. O componente é especificamente projetado para realizar tarefas computacionais, portanto, no caso de uma violação, ele não forneceria nenhum ganho útil ao atacante, como acesso a arquivos ou à rede.
Os componentes XPC de um aplicativo estão **dentro do próprio aplicativo**. Por exemplo, no Safari, você pode encontrá-los em **`/Applications/Safari.app/Contents/XPCServices`**. Eles têm a extensão **`.xpc`** (como **`com.apple.Safari.SandboxBroker.xpc`**) e também são **bundles** com o binário principal dentro dele: `/Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/MacOS/com.apple.Safari.SandboxBroker`
Como você pode estar pensando, um **componente XPC terá diferentes direitos e privilégios** do que os outros componentes XPC ou o binário principal do aplicativo. EXCETO se um serviço XPC for configurado com [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information\_property\_list/xpcservice/joinexistingsession) definido como "True" em seu arquivo **Info.plist**. Nesse caso, o serviço XPC será executado na mesma sessão de segurança do aplicativo que o chamou.
Os serviços XPC são **iniciados** pelo **launchd** quando necessário e **encerrados** assim que todas as tarefas são **concluídas** para liberar recursos do sistema. **Os componentes XPC específicos do aplicativo só podem ser utilizados pelo aplicativo**, reduzindo assim o risco associado a possíveis vulnerabilidades.
Os serviços XPC em todo o sistema são acessíveis a todos os usuários. Esses serviços, seja launchd ou do tipo Mach, precisam ser **definidos em arquivos plist** localizados em diretórios especificados, como **`/System/Library/LaunchDaemons`**, **`/Library/LaunchDaemons`**, **`/System/Library/LaunchAgents`** ou **`/Library/LaunchAgents`**.
Os que estão em **`LaunchDameons`** são executados pelo root. Portanto, se um processo não privilegiado puder se comunicar com um deles, ele poderá ser capaz de escalar privilégios.
Os aplicativos podem **se inscrever** em diferentes **mensagens de evento**, permitindo que sejam **iniciados sob demanda** quando esses eventos ocorrem. A **configuração** desses serviços é feita em arquivos **plist do launchd**, localizados nos **mesmos diretórios que os anteriores** e contendo uma chave extra **`LaunchEvent`**.
Quando um processo tenta chamar um método via uma conexão XPC, o **serviço XPC deve verificar se esse processo tem permissão para se conectar**. Aqui estão as maneiras comuns de verificar isso e as armadilhas comuns:
A Apple também permite que os aplicativos **configurem alguns direitos e como obtê-los** para que, se o processo de chamada os tiver, ele possa ser **autorizado a chamar um método** do serviço XPC:
Você pode encontrar o arquivo original em inglês abaixo:
{% tab title="README.md" %}
# Comunicação Interprocesso (IPC) no macOS
O macOS fornece vários mecanismos de IPC para permitir que os processos se comuniquem entre si. Esses mecanismos incluem:
* **Mach Messages**: um mecanismo de IPC de baixo nível que permite que os processos se comuniquem diretamente com o kernel do macOS.
* **XPC**: um mecanismo de IPC de nível superior que permite que os processos se comuniquem com outros processos em um ambiente sandboxed.
* **Distributed Objects (DO)**: um mecanismo de IPC de nível superior que permite que os processos se comuniquem com outros processos em diferentes máquinas.
## Mach Messages
O Mach Messages é um mecanismo de IPC de baixo nível que permite que os processos se comuniquem diretamente com o kernel do macOS. O Mach Messages é usado por muitos componentes do macOS, incluindo o launchd, que é o processo pai de todos os processos do usuário no macOS.
Os processos podem enviar mensagens para outros processos usando o Mach Messages. As mensagens podem conter dados e podem ser enviadas de forma síncrona ou assíncrona. As mensagens também podem ser enviadas para portas Mach, que são objetos que representam canais de comunicação entre processos.
Os processos podem criar portas Mach e compartilhá-las com outros processos. Isso permite que os processos se comuniquem diretamente uns com os outros sem a necessidade de intermediários.
Os processos também podem usar as notificações Mach para serem notificados quando ocorrem eventos específicos, como a chegada de uma nova mensagem.
## XPC
O XPC é um mecanismo de IPC de nível superior que permite que os processos se comuniquem com outros processos em um ambiente sandboxed. O XPC é usado por muitos componentes do macOS, incluindo o launchd.
Os processos podem enviar mensagens XPC para outros processos. As mensagens XPC podem conter dados e podem ser enviadas de forma síncrona ou assíncrona. As mensagens XPC também podem ser enviadas para conexões XPC, que são objetos que representam canais de comunicação entre processos.
Os processos podem criar conexões XPC e compartilhá-las com outros processos. Isso permite que os processos se comuniquem diretamente uns com os outros sem a necessidade de intermediários.
## Distributed Objects (DO)
O DO é um mecanismo de IPC de nível superior que permite que os processos se comuniquem com outros processos em diferentes máquinas. O DO é usado por muitos componentes do macOS, incluindo o Bonjour e o Remote Apple Events.
Os processos podem enviar mensagens DO para outros processos. As mensagens DO podem conter dados e podem ser enviadas de forma síncrona ou assíncrona. As mensagens DO também podem ser enviadas para proxies DO, que são objetos que representam canais de comunicação entre processos.
Os processos podem criar proxies DO e compartilhá-los com outros processos. Isso permite que os processos se comuniquem diretamente uns com os outros em diferentes máquinas sem a necessidade de intermediários.
Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other and share data. macOS provides several IPC mechanisms, including:
Mach ports are a low-level IPC mechanism that is used extensively by macOS. Mach ports are used to implement many of the higher-level IPC mechanisms, including Distributed Objects and XPC services.
Mach ports are identified by a port name, which is a 32-bit integer. Ports can be created, destroyed, and passed between processes. Ports can also be used to send and receive messages.
UNIX domain sockets are a type of IPC mechanism that is commonly used on UNIX-based systems. UNIX domain sockets are similar to network sockets, but they are used for communication between processes on the same system.
UNIX domain sockets are well-suited to implementing client/server architectures, where a server process listens on a socket and multiple client processes connect to it.
Distributed Objects is a high-level IPC mechanism that is built on top of Mach ports. Distributed Objects allows objects to be passed between processes, and it provides a transparent mechanism for remote method invocation.
XPC Services is a high-level IPC mechanism that is built on top of Mach ports. XPC Services allows processes to launch and communicate with other processes in a secure and controlled manner.
IPC is a fundamental mechanism for building complex systems on macOS. By understanding the strengths and weaknesses of each IPC mechanism, you can choose the right mechanism for your use case and build robust and secure systems.
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).