Local Privilege Escalation até à raiz através dos sistemas de ficheiros Apple macOS

Contos do CVE-2023-42931

Introdução

Como pentester que quase nunca pôs as mãos num Mac desde o Apple Mac OS X na década de 2000...

Estava numa situação em que tinha de encontrar um Local Privilege Escalation (LPE) num macOS 13 Ventura.

Como diz o ditado, o Apple macOS é basicamente um Linux “chique”, por isso, naturalmente, procurei técnicas que estou habituado a procurar em sistemas Linux, incluindo questões relacionadas com setuid e opções de montagem.

Conclusões

Aprendi rapidamente que no sistema macOS todos os utilizadores locais (incluindo o “convidado”) podem montar sistemas de ficheiros utilizando o utilitário de linha de comandos “diskutil”.

Este comando aceita opções de montagem através dos argumentos “-mountOptions”. Olhando para a página do manual, duas opções de montagem podem ser interessantes para desencadear uma privilege escalation:

1. owners/noowners: ativa/desativa o suporte para a propriedade dos utilizadores, por isso, no modo “noowners” age como se todos os ficheiros pertencessem ao utilizador atual (UID=99), enquanto no modo “owners” preserva a propriedade original de cada ficheiro. Esta opção não afeta as permissões que são preservadas entre os dois modos; os novos ficheiros criados no modo “noowners” serão propriedade do seu criador, mas os ficheiros modificados no modo “noowners” preservarão a sua propriedade original enquanto montados novamente no modo “owners”;
2. suid/nosuid: ativa/desativa o suporte para os bits setuid/setgid.

Por isso, devo ser capaz de escalar para a raiz se conseguir:

1. Montar um sistema de ficheiros com “noowners”;
2. Modificar um ficheiro pertencente à raiz para um binário arbitrário;
3. Adicionar o bit setuid a esse ficheiro, remontando-o depois no modo “owners”.

No entanto, a hierarquia moderna do disco/sistema de ficheiros macOS é bastante estranha. Além disso, estou a fazer a minha pesquisa dentro de uma máquina virtual QEMU a correr macOS a partir do meu Linux, e isso também não ajuda…

De qualquer forma, meu sistema de ficheiros raiz ("/") vem de /dev/disk3s4s1, que é um snapshot de /dev/disk3s4, que não é montado por padrão.

A boa notícia é que posso montar /dev/disk3s4 com a flag “noowners”:

A má notícia é que muitos ficheiros/pastas continuam a pertencer à raiz, em vez de pertencerem ao meu utilizador atual “test”, apesar de a opção “noowners” estar definida…

Mas, afinal, só preciso de um ficheiro, por isso vamos modificar um que é considerado propriedade própria (self-owned) no modo “noowners”:

WTF não consigo escrever um ficheiro que é meu!?!

Acontece que existe uma coisa chamada SIP (System Integrity Protection - Proteção da Integridade do Sistema), que impede a modificação de ficheiros e pastas sensíveis do sistema ao nível do kernel, de modo a que nem o utilizador raiz os possa modificar.

Por isso, preciso de encontrar um ficheiro que seja:

Depois de correr toneladas de "ls" (para verificar a propriedade) e “touch” (para testar a proteção SIP), tentando algumas fórmulas estranhas de “find -exec” para automatizar o processo, encontrei o que devia ter visto rapidamente: há um ficheiro de reserva “.file” no sistema de ficheiros raiz ("/") que preenche os três requisitos.

Como executar o exploit

1. Preparar um payload

Vamos então escrever um payload setuid shell simples e compilá-lo com o Xcode num binário suidshell.

2. Executar o exploit

1. Montar o sistema de ficheiros visado com a flag “noowners”:

2. Tornar o “.file” editável (por defeito, nem o seu proprietário pode escrevê-lo):

3. Copiar o binário do suidshell para “.file”:

4. Definir as permissões de “.file” incluindo execução para todos e bit setuid:

5. Remontar o sistema de ficheiros em modo “owners” e “suid” (que é o padrão aqui):

6. Executar o suidshell e voilà!

Ativos afetados

MacOS Sonoma antes da versão 14.2

MacOS Ventura antes da versão 13.6.3

MacOS Monterey antes da versão 12.7.2

Nota: Não testei pessoalmente esta situação no macOS 12, mas a Apple considerou-a vulnerável e corrigiu-a, pelo que presumo que o macOS 12 (e provavelmente os anteriores que já não são suportados pela Apple) era vulnerável.

No Ventura (e provavelmente antes), este exploit pode ser conseguido a partir de qualquer utilizador (incluindo o “guest”).

No Sonoma, se tentares explorar a partir de um utilizador que não pertença ao grupo “admin”, ser-te-á pedida uma palavra-passe de administrador, pelo que não poderás elevar os teus privilégios. No entanto, esta vulnerabilidade ainda é relevante no Sonoma, pois permite que um utilizador “admin” se torne raiz sem digitar a sua palavra-passe (ao passo que, quando um utilizador do grupo “admin” tenta efetuar uma ação que requer privilégios de raiz, como executar o sudo, a sua palavra-passe é solicitada).

Cronologia

• 24/10/2023: Constatação inicial
  

• 26/10/2023: Vulnerabilidade reportada à Apple
  

• 31/10/2023: A Apple marcou-a como “Reproduzida”
  

• 04/12/2023: A Apple associou o CVE-2023-42931 à vulnerabilidade
  

• 11/12/2023: Vulnerabilidade corrigida nas versões 14.2, 13.6.3 e 12.7.2 do macOS
  

• 23/03/2024: Entrada adicionada nos avisos de segurança do macOS

Fonte: https://support.apple.com/en-us/HT214036

Correção

A Apple corrigiu esta vulnerabilidade ao ignorar a opção de montagem “noowners” durante a montagem do armazenamento interno com o diskutil (mesmo quando iniciado como raiz, utilizando “sudo”).

Conclusão

Esta vulnerabilidade não requer quaisquer conhecimentos de engenharia inversa para ser encontrada, compreendida ou explorada. Trata-se de um Local Privilege Escalation com um exploit fácil, estável e fiável.

O seu impacto é que qualquer pessoa com acesso a uma conta local (incluindo o “convidado”) pode elevar o seu privilégio para raiz. Mesmo que só funcione a partir de uma conta de utilizador “admin” no macOS 14 Sonoma, pode causar muitos danos, por exemplo, se o exploit for executado silenciosamente por uma aplicação maliciosa não incluída na sandbox. Pode ser ainda mais impactante quando associado a uma fuga da sandbox, permitindo que uma aplicação na sandbox escape para a raiz. Por isso, corrige o teu macOS o mais rapidamente possível!