* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
O Mach usa **tarefas** como a **unidade mínima** para compartilhar recursos, e cada tarefa pode conter **várias threads**. Essas **tarefas e threads são mapeadas em um para um com processos e threads POSIX**.
A comunicação entre tarefas ocorre por meio da Comunicação Interprocessos (IPC) do Mach, utilizando canais de comunicação unidirecionais. **As mensagens são transferidas entre portas**, que funcionam 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, único consumidor), o que significa que pode haver apenas **um direito de recebimento para cada porta** em todo o sistema (ao contrário de 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 o envio de mensagens. Originalmente, apenas a **própria tarefa tem o direito de recebimento sobre sua porta**.
* **Direito de envio**, que permite enviar mensagens para a porta.
* O direito de envio pode ser **clonado**, para que uma tarefa que possui um direito de envio possa clonar o direito e **concedê-lo a uma terceira tarefa**.
* **Direito de envio único**, que permite enviar uma mensagem para a porta e depois desaparece.
* **Direito de conjunto de portas**, que denota um _conjunto de portas_ 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. Conjuntos de portas podem ser usados para escutar várias portas simultaneamente, de forma semelhante a `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 tornam 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 reivindicar falsamente um nome de serviço de autorização e, em seguida, aprovar todas as solicitações.
Em seguida, 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 um pouco**. Quando um nome de serviço está sendo procurado, o launchd inicia o serviço dinamicamente. O novo fluxo de trabalho é o seguinte:
* O **launchd** verifica se a tarefa está em execução e, se não estiver, a **inicia**.
* 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**.
* O launchd duplica o **direito de ENVIO e o envia para a Tarefa B**.
No entanto, esse processo se aplica apenas a tarefas do sistema predefinidas. Tarefas não pertencentes ao sistema ainda operam conforme descrito originalmente, o que poderia permitir a falsificação.
### Serviços Mach
Os nomes especificados nos aplicativos localizados nos diretórios protegidos pelo SIP mencionados anteriormente não podem ser registrados por outros processos.
Por exemplo, `/System/Library/LaunchAgents/com.apple.xpc.loginitemregisterd.plist` registra o nome `com.apple.xpc.loginitemregisterd`:
```json
plutil -p com.apple.xpc.loginitemregisterd.plist
{
"EnablePressuredExit" => 1
"Label" => "com.apple.xpc.loginitemregisterd"
"MachServices" => {
"com.apple.xpc.loginitemregisterd" => 1
}
"ProcessType" => "Adaptive"
"Program" => "/usr/libexec/loginitemregisterd"
}
```
Se você tentar registrá-lo com um código como o seguinte, você não conseguirá.
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**.
* **Porta do host**: Se um processo tem o privilégio de **enviar** sobre esta porta, ele pode obter **informações** sobre o **sistema** (por exemplo, `host_processor_info`).
* **Porta privilégiada do host**: Um processo com o direito de **enviar** sobre esta porta pode realizar **ações privilegiadas**, como carregar uma extensão do kernel. O **processo precisa ser root** para obter essa permissão.
* Além disso, para chamar a API **`kext_request`**, é necessário ter outras permissões **`com.apple.private.kext*`**, que são concedidas apenas a binários da Apple.
* **Porta do nome da tarefa**: Uma versão não privilegiada da _porta da tarefa_. Ela faz referência à tarefa, mas não permite controlá-la. A única coisa que parece estar disponível através dela é `task_info()`.
* **Porta da tarefa** (também conhecida como porta do kernel)**:** Com permissão de envio sobre esta porta, é possível controlar a tarefa (ler/escrever memória, criar threads...).
* Chame `mach_task_self()` para **obter o nome** desta porta para a tarefa chamadora. Esta porta é **herdada** apenas através do **`exec()`**; uma nova tarefa criada com `fork()` recebe uma nova porta de tarefa (como um caso especial, uma tarefa também recebe uma nova porta de tarefa após `exec()` em um binário suid). A única maneira de criar uma tarefa e obter sua porta é realizar a ["dança de troca de porta"](https://robert.sesek.com/2014/1/changes\_to\_xnu\_mach\_ipc.html) enquanto faz um `fork()`.
* Estas são as restrições para acessar a porta (de `macos_task_policy` do binário `AppleMobileFileIntegrity`):
* Se o aplicativo tiver a permissão **`com.apple.security.get-task-allow`**, processos do **mesmo usuário podem acessar a porta da tarefa** (comumente adicionado pelo Xcode para depuração). O processo de **notarização** não permitirá isso em lançamentos de produção.
* Aplicativos com a permissão **`com.apple.system-task-ports`** podem obter a **porta da tarefa para qualquer** processo, exceto o kernel. Em versões mais antigas, era chamada **`task_for_pid-allow`**. Isso é concedido apenas a aplicativos da Apple.
* **Root pode acessar portas de tarefas** de aplicativos **não** compilados com um tempo de execução **fortificado** (e não da Apple).
O arquivo `entitlements.plist` contém informações sobre as permissões e privilégios concedidos a um aplicativo no macOS. Essas permissões podem incluir acesso a recursos do sistema, como câmera, microfone, localização e muito mais. O arquivo `entitlements.plist` é usado para definir as capacidades e restrições de um aplicativo, garantindo que ele tenha acesso apenas aos recursos necessários e autorizados.
Para fortalecer a segurança do macOS, é importante revisar e ajustar as permissões definidas no arquivo `entitlements.plist`. Isso pode ser feito removendo permissões desnecessárias ou restritas, limitando o acesso a recursos sensíveis e garantindo que apenas os recursos necessários sejam concedidos ao aplicativo.
Ao analisar o arquivo `entitlements.plist`, é possível identificar possíveis vulnerabilidades de privilégio e escalonamento de privilégios. Por exemplo, se um aplicativo tiver permissões excessivas ou não autorizadas, um invasor pode explorar essas permissões para obter acesso não autorizado a recursos do sistema ou executar ações maliciosas.
Portanto, é fundamental entender e auditar regularmente as permissões definidas no arquivo `entitlements.plist` para garantir a segurança e a privacidade dos aplicativos no macOS.
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plistversion="1.0">
<dict>
<key>com.apple.security.get-task-allow</key>
<true/>
</dict>
</plist>
```
{% endtab %}
{% endtabs %}
**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 **sudo**).
No macOS, as **threads** podem ser manipuladas através do **Mach** ou usando a API **posix `pthread`**. A thread que geramos 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 não era necessário 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 a thread**, ela deve chamar **`pthread_create_from_mach_thread`**, que irá **criar um pthread válido**. Em seguida, esse novo pthread pode **chamar dlopen** para **carregar uma dylib** do sistema, então, em vez de escrever um novo shellcode para executar ações diferentes, é possível carregar bibliotecas personalizadas.
XPC, que significa Comunicação Interprocessos (IPC) do XNU (o kernel usado pelo macOS), é uma estrutura para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método seguras e assíncronas entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos com privilégios separados**, onde cada **componente** é executado com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim os danos potenciais de um processo comprometido.
O XPC usa uma forma de Comunicação Interprocessos (IPC), que é um conjunto de métodos para que programas diferentes em execução no mesmo sistema possam enviar dados de ida e volta.
Os principais benefícios do XPC incluem:
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 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** e fazê-los se comunicar via XPC é **menos eficiente**. Mas nos sistemas de hoje isso quase não é perceptí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 e, portanto, no caso de uma violação, 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** quando 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.
### Serviços XPC em Todo o Sistema
Os serviços XPC em todo o sistema são acessíveis a todos os usuários. Esses serviços, sejam do tipo launchd ou Mach, precisam ser **definidos em arquivos plist** localizados em diretórios especificados, como **`/System/Library/LaunchDaemons`**, **`/Library/LaunchDaemons`**, **`/System/Library/LaunchAgents`** ou **`/Library/LaunchAgents`**.
Esses arquivos plist terão uma chave chamada **`MachServices`** com o nome do serviço e uma chave chamada **`Program`** com o caminho para o binário:
Os presentes em **`LaunchDameons`** são executados pelo root. Portanto, se um processo não privilegiado puder se comunicar com um deles, ele poderá conseguir privilégios elevados.
As aplicações podem **se inscrever** em diferentes **mensagens de evento**, permitindo que sejam **iniciadas sob demanda** quando esses eventos ocorrerem. A **configuração** desses serviços é feita em arquivos **plist do launchd**, localizados nos **mesmos diretórios dos anteriores** e contendo uma chave adicional **`LaunchEvent`**.
Quando um processo tenta chamar um método por meio de 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:
O arquivo `xpc_client.c` é um exemplo de código em C que demonstra como usar a comunicação interprocesso (IPC) no macOS usando o framework XPC. O XPC é um mecanismo de IPC fornecido pelo macOS que permite que processos se comuniquem entre si de forma segura e eficiente.
O código começa incluindo os cabeçalhos necessários e definindo algumas constantes. Em seguida, ele define a função `main`, que é o ponto de entrada do programa.
Dentro da função `main`, o código cria uma conexão XPC usando a função `xpc_connection_create`, especificando o identificador da conexão e o nome do serviço. Em seguida, ele define um manipulador de eventos usando a função `xpc_connection_set_event_handler`, que será chamado sempre que um evento ocorrer na conexão.
O código também define um bloco de código para lidar com eventos de resposta. Quando uma resposta é recebida, o bloco de código é executado e exibe a resposta na saída padrão.
Este exemplo de código demonstra como usar a comunicação interprocesso no macOS usando o framework XPC. Ele pode ser usado como ponto de partida para desenvolver aplicativos que se comunicam com outros processos de forma segura e eficiente.
O arquivo `oc_xpc_client.m` contém um exemplo de código em Objective-C que demonstra como criar um cliente XPC (Inter-Process Communication) no macOS. O XPC é um mecanismo de comunicação entre processos que permite que aplicativos se comuniquem uns com os outros de forma segura e eficiente.
O código começa importando o framework `Foundation` e `xpc`, que são necessários para trabalhar com XPC no macOS. Em seguida, é definida uma função `main` que será o ponto de entrada do programa.
Dentro da função `main`, é criada uma conexão XPC usando a função `xpc_connection_create`. Em seguida, é definido um bloco de código que será executado quando a conexão for estabelecida com sucesso. Nesse bloco, é definida uma função `handler` que será chamada sempre que uma mensagem for recebida do servidor.
Dentro da função `handler`, é verificado o tipo da mensagem recebida usando a função `xpc_get_type`. Se a mensagem for do tipo `XPC_TYPE_DICTIONARY`, é extraído o valor da chave `message` usando a função `xpc_dictionary_get_string`. Em seguida, é exibida uma mensagem na saída padrão com o valor da chave `message`.
Por fim, é chamada a função `xpc_connection_resume` para iniciar a comunicação com o servidor e a função `dispatch_main` para iniciar o loop de eventos do programa.
Este exemplo de código demonstra como criar um cliente XPC básico no macOS. É importante ressaltar que o código fornecido é apenas um exemplo e pode ser necessário adaptá-lo para atender às necessidades específicas do seu aplicativo.
Inter-Process Communication (IPC) is a mechanism that allows different processes to communicate with each other and share data. In Mac OS, IPC is an essential part of the operating system architecture and is used by various system components and applications.
1.**Mach Ports**: Mach ports are the fundamental IPC mechanism in Mac OS. They are used for communication between processes and for accessing various system services.
2.**UNIX Domain Sockets**: UNIX domain sockets provide a communication channel between processes running on the same machine. They are widely used by system daemons and server applications.
3.**Distributed Objects**: Distributed objects provide a high-level IPC mechanism that allows objects to be accessed remotely. They are used by some system services and applications.
4.**XPC**: XPC (eXtensible Procedure Call) is a modern IPC mechanism introduced in Mac OS X 10.7. It provides a secure and efficient way for processes to communicate with each other.
## Security Considerations
IPC can introduce security risks if not properly implemented and configured. Here are some security considerations to keep in mind when working with IPC in Mac OS:
1.**Authentication and Authorization**: Ensure that only authorized processes can access IPC channels and services. Use appropriate authentication and authorization mechanisms to prevent unauthorized access.
2.**Secure Communication**: Protect the confidentiality and integrity of data exchanged through IPC channels. Use encryption and secure protocols to prevent eavesdropping and tampering.
4.**Sandboxing**: Consider using sandboxing techniques to restrict the privileges and capabilities of processes involved in IPC. This can help mitigate the impact of potential security breaches.
In some cases, insecure or misconfigured IPC channels can be exploited to escalate privileges and gain unauthorized access to system resources. This can be done by:
1.**Impersonating a Trusted Process**: By exploiting a vulnerability in an IPC channel, an attacker can impersonate a trusted process and gain elevated privileges.
2.**Abusing Privileged IPC Services**: If a privileged IPC service is not properly secured, an attacker can abuse it to execute arbitrary code with elevated privileges.
3.**Tampering with IPC Messages**: By tampering with IPC messages, an attacker can manipulate the behavior of the receiving process and potentially gain unauthorized access to sensitive information or resources.
Understanding IPC mechanisms and their security implications is crucial for building secure and robust applications on Mac OS. By following best practices and implementing appropriate security measures, you can minimize the risk of IPC-related vulnerabilities and protect your system from unauthorized access.
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique 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 Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
