macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
As restrições de lançamento no macOS foram introduzidas para aumentar a segurança, regulando como, quem e de onde um processo pode ser iniciado. Iniciadas no macOS Ventura, elas fornecem uma estrutura que categoriza cada binário do sistema em distintas categorias de restrição, que são definidas dentro do cache de confiança, uma lista contendo binários do sistema e seus respectivos hashes. Essas restrições se estendem a cada binário executável dentro do sistema, implicando um conjunto de regras que delineiam os requisitos para lançar um binário específico. As regras abrangem restrições próprias que um binário deve satisfazer, restrições de pai que devem ser atendidas pelo seu processo pai, e restrições responsáveis que devem ser seguidas por outras entidades relevantes.
O mecanismo se estende a aplicativos de terceiros através de Restrições de Ambiente, a partir do macOS Sonoma, permitindo que os desenvolvedores protejam seus aplicativos especificando um conjunto de chaves e valores para restrições de ambiente.
Você define restrições de ambiente de lançamento e de biblioteca em dicionários de restrição que você salva em arquivos de lista de propriedades launchd, ou em arquivos de lista de propriedades separados que você usa na assinatura de código.
Existem 4 tipos de restrições:
Restrições Próprias: Restrições aplicadas ao binário em execução.
Processo Pai: Restrições aplicadas ao pai do processo (por exemplo, launchd executando um serviço XP)
Restrições Responsáveis: Restrições aplicadas ao processo que chama o serviço em uma comunicação XPC
Restrições de carregamento de biblioteca: Use restrições de carregamento de biblioteca para descrever seletivamente o código que pode ser carregado
Assim, quando um processo tenta lançar outro processo — chamando execve(_:_:_:) ou posix_spawn(_:_:_:_:_:_:) — o sistema operacional verifica se o arquivo executável satisfaz sua própria restrição própria. Ele também verifica se o executável do processo pai satisfaz a restrição de pai do executável, e se o executável do processo responsável satisfaz a restrição de processo responsável do executável. Se qualquer uma dessas restrições de lançamento não for satisfeita, o sistema operacional não executa o programa.
Se ao carregar uma biblioteca qualquer parte da restrição da biblioteca não for verdadeira, seu processo não carrega a biblioteca.
Um LC é composto por fatos e operações lógicas (e, ou..) que combinam fatos.
Os fatos que um LC pode usar estão documentados. Por exemplo:
is-init-proc: Um valor booleano que indica se o executável deve ser o processo de inicialização do sistema operacional (launchd).
is-sip-protected: Um valor booleano que indica se o executável deve ser um arquivo protegido pela Proteção de Integridade do Sistema (SIP).
on-authorized-authapfs-volume: Um valor booleano que indica se o sistema operacional carregou o executável de um volume APFS autorizado e autenticado.
on-authorized-authapfs-volume: Um valor booleano que indica se o sistema operacional carregou o executável de um volume APFS autorizado e autenticado.
Volume de Cryptexes
on-system-volume: Um valor booleano que indica se o sistema operacional carregou o executável do volume de sistema atualmente inicializado.
Dentro de /System...
...
Quando um binário da Apple é assinado, ele o atribui a uma categoria LC dentro do cache de confiança.
As categorias LC do iOS 16 foram revertidas e documentadas aqui.
As categorias LC atuais (macOS 14 - Sonoma) foram revertidas e suas descrições podem ser encontradas aqui.
Por exemplo, a Categoria 1 é:
(on-authorized-authapfs-volume || on-system-volume): Deve estar no volume do Sistema ou Cryptexes.
launch-type == 1: Deve ser um serviço do sistema (plist em LaunchDaemons).
validation-category == 1: Um executável do sistema operacional.
is-init-proc: Launchd
Você tem mais informações sobre isso aqui, mas basicamente, elas são definidas no AMFI (AppleMobileFileIntegrity), então você precisa baixar o Kernel Development Kit para obter o KEXT. Os símbolos que começam com kConstraintCategory são os interessantes. Extraindo-os, você obterá um fluxo codificado DER (ASN.1) que precisará decodificar com ASN.1 Decoder ou a biblioteca python-asn1 e seu script dump.py, andrivet/python-asn1, que lhe dará uma string mais compreensível.
Estas são as Restrições de Lançamento configuradas em aplicações de terceiros. O desenvolvedor pode selecionar os fatos e operadores lógicos a serem usados em sua aplicação para restringir o acesso a si mesmo.
É possível enumerar as Restrições de Ambiente de uma aplicação com:
Em macOS, existem alguns caches de confiança:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
E no iOS parece que está em /usr/standalone/firmware/FUD/StaticTrustCache.img4.
No macOS rodando em dispositivos Apple Silicon, se um binário assinado pela Apple não estiver no cache de confiança, o AMFI se recusará a carregá-lo.
Os arquivos de cache de confiança anteriores estão no formato IMG4 e IM4P, sendo IM4P a seção de payload de um formato IMG4.
Você pode usar pyimg4 para extrair o payload de bancos de dados:
(Outra opção poderia ser usar a ferramenta img4tool, que funcionará mesmo no M1, mesmo que o lançamento seja antigo, e para x86_64 se você a instalar nos locais apropriados).
Agora você pode usar a ferramenta trustcache para obter as informações em um formato legível:
O cache de confiança segue a seguinte estrutura, então a categoria LC é a 4ª coluna
Então, você poderia usar um script como este para extrair dados.
Com esses dados, você pode verificar os Apps com um valor de restrições de lançamento de 0, que são aqueles que não estão restritos (verifique aqui para o que cada valor significa).
As Restrições de Lançamento teriam mitigado vários ataques antigos ao garantir que o processo não seja executado em condições inesperadas: Por exemplo, a partir de locais inesperados ou sendo invocado por um processo pai inesperado (se apenas o launchd deve estar lançando).
Além disso, as Restrições de Lançamento também mitigam ataques de downgrade.
No entanto, elas não mitigam abusos comuns de XPC, injeções de código Electron ou injeções de dylib sem validação de biblioteca (a menos que os IDs de equipe que podem carregar bibliotecas sejam conhecidos).
Na versão Sonoma, um ponto notável é a configuração de responsabilidade do serviço daemon XPC. O serviço XPC é responsável por si mesmo, ao contrário do cliente conectado ser responsável. Isso está documentado no relatório de feedback FB13206884. Essa configuração pode parecer falha, pois permite certas interações com o serviço XPC:
Lançando o Serviço XPC: Se considerado um bug, essa configuração não permite iniciar o serviço XPC através do código do atacante.
Conectando a um Serviço Ativo: Se o serviço XPC já estiver em execução (possivelmente ativado por seu aplicativo original), não há barreiras para se conectar a ele.
Embora implementar restrições no serviço XPC possa ser benéfico ao reduzir a janela para ataques potenciais, isso não aborda a preocupação principal. Garantir a segurança do serviço XPC requer fundamentalmente validar efetivamente o cliente conectado. Este permanece o único método para fortalecer a segurança do serviço. Além disso, vale a pena notar que a configuração de responsabilidade mencionada está atualmente operacional, o que pode não estar alinhado com o design pretendido.
Mesmo que seja necessário que o aplicativo seja aberto pelo LaunchService (nas restrições dos pais). Isso pode ser alcançado usando open (que pode definir variáveis de ambiente) ou usando a API de Serviços de Lançamento (onde variáveis de ambiente podem ser indicadas).
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
