- A Apple corrigiu o CVE-2024-54471 no macOS Sequoia 15.1, Sonoma 14.7.1 e Ventura 13.7.1, distribuídos em 28 de outubro de 2024; em ambientes sem a atualização, credenciais armazenadas podiam ser expostas por meio do NetAuthAgent
- O núcleo do problema era que o servidor MIG do NetAuthAgent deixava abertas rotinas de consulta, criação e sobrescrita parcial de credenciais de servidor de arquivos sem verificar o remetente da mensagem
- Um invasor podia enviar mensagens ao serviço Mach
com.apple.netauth.user.guipara fazer consultas substitutas de itensinternet passworddo Keychain e receber nome de usuário e senha - O impacto não se limitava às credenciais de FTP, Samba, WebDAV e servidores de impressão salvas pelo “Connect to Server” do Finder; por uma cadeia separada, também podia levar à exposição de informações da conta iCloud e tokens de API
- Após o patch, o NetAuthAgent verifica os entitlements do processo remetente pelo audit token da mensagem Mach e não responde se
com.apple.private.netauth.useragent.allow=truenão estiver presente
Escopo do patch do CVE-2024-54471
- CVE-2024-54471 é uma vulnerabilidade do macOS corrigida nas atualizações de segurança da Apple
- As versões com o patch foram lançadas em 28 de outubro de 2024
- macOS Sequoia 15.1
- macOS Sonoma 14.7.1
- macOS Ventura 13.7.1
- Dispositivos macOS que ainda não foram atualizados para essas versões devem ser atualizados imediatamente
IPC do macOS e a arquitetura baseada em Mach
- O kernel do macOS e da maioria dos sistemas da Apple é o XNU, um kernel híbrido que inclui elementos da família BSD e uma variante fortemente modificada do kernel Mach
- O Mach, mesmo no macOS moderno, baseia-se em quatro abstrações
- task: ambiente de execução em que as threads rodam e unidade básica de alocação de recursos
- thread: unidade básica de uso de CPU
- port: canal de comunicação correspondente a uma fila de mensagens protegida pelo kernel
- message: conjunto de objetos de dados tipados usados na comunicação entre threads
- As portas do Mach não são filas expostas diretamente ao espaço do usuário, mas tratadas como port rights dentro do namespace de nomes de portas de cada task
- Há dois privilégios principais
- send right: pode ser possuído por várias tasks para a mesma porta
- receive right: pode ser possuído por apenas uma task
- Essa estrutura forma um modelo cliente-servidor em que uma task servidora recebe mensagens de várias tasks clientes
- O bootstrap server do macOS entrega uma porta para a qual todas as tasks têm send right, permitindo que clientes peçam o send right de um serviço Mach registrado por nome de string
Falha de autenticação no servidor MIG
- MIG é uma ferramenta que encapsula envio e recebimento de mensagens Mach em uma interface funcional
- O MIG é composto por uma pseudo-C IDL e um compilador, e a partir do arquivo IDL gera
- código-fonte C para o cliente
- código-fonte C para o servidor
- header C usado por ambos os lados
- Cada função é chamada de routine, e o conjunto delas é chamado de subsystem; o número do subsystem e o índice da routine são refletidos no ID da mensagem
- Na comunicação em espaço do usuário do macOS, o MIG em grande parte perdeu espaço para a API XPC, mas o XPC também é construído sobre mensagens Mach
- O próprio servidor MIG não possui um mecanismo obrigatório de autenticação; portanto, se o servidor não validar o remetente, qualquer task com send right pode chamar rotinas remotas
- Para explorar servidores MIG, a CLI ipsw do blacktop é útil, usando a busca por binários que importam o símbolo
NDR_record- Esse método encontra não só servidores MIG, mas também clientes MIG
- Código de servidor e cliente pode ser distinguido com relativa facilidade em disassemblers ou decompiladores
Credenciais tratadas pelo NetAuthAgent
- O NetAuthAgent é um agente de usuário do macOS que lida com credenciais de servidores de arquivos como FTP, Samba e WebDAV
- A caixa de autenticação exibida ao conectar-se a um servidor de arquivos via “Go → Connect To Server” no Finder é fornecida pelo NetAuthAgent ou por um processo relacionado
- Se o usuário marcar a opção de salvar a senha, as credenciais são armazenadas no Keychain do macOS
- O NetAuthAgent não armazena diretamente as senhas; ele usa o Keychain como um repositório central de segredos
- Itens do Keychain possuem sua própria lista de controle de acesso, o que normalmente impede que aplicações acessem segredos aos quais não deveriam ter acesso
- Porém, se um processo expõe um mecanismo para consultar o Keychain em nome de outro processo, todo o modelo de segurança pode enfraquecer
O serviço MIG vulnerável do NetAuthAgent
- O NetAuthAgent expunha um servidor MIG acessível pelo bootstrap server
- O nome do serviço é
com.apple.netauth.user.gui - Esse servidor fornecia rotinas para ler, criar e, em alguns casos, sobrescrever credenciais de servidores de arquivos
- Antes do patch, essas rotinas não validavam o remetente da mensagem
- A Routine 19, ID de mensagem 40219, podia atuar como proxy da consulta a itens da classe
internet passworddo Keychain - Essa routine recebia um dicionário de opções serializado como descritor de dados out-of-line e retornava o nome de usuário e a senha como dois descritores de dados out-of-line
Fluxo do ataque e construção do PoC
- O PoC foi escrito em Swift e usou a ferramenta de pesquisa de segurança Kass para lidar com mensagens Mach e clientes MIG
- O cliente do NetAuthAgent foi definido com os seguintes valores
- nome do serviço:
com.apple.netauth.user.gui - ID de routine baseado no subsystem: 40200
- nome do serviço:
- As opções de consulta são serializadas em formato Property List e podem incluir campos como
Scheme,Host,AlternatePortePath - A API de Keychain do macOS,
SecItemCopyMatching, quando não solicita o valor secreto, pode ser usada até por processos sem permissão para obter metadados de itens do Keychain - A lista de controle de acesso também é acessível como metadado, permitindo verificar se
/System/Library/CoreServices/NetAuthAgent.appestava incluído na lista de aplicações confiáveis do item - O código de ataque podia percorrer itens
internet passwordacessíveis ao NetAuthAgent e extrair as seguintes informações- nome de exibição
- protocolo
- host
- porta
- caminho
- nome de usuário
- senha
Impacto do vazamento de credenciais de servidor de arquivos
- Antes do patch, um processo malicioso que obtivesse send right para o NetAuthAgent podia exfiltrar todas as credenciais de servidores de arquivos
- Em ambientes corporativos, essas credenciais podiam ser credenciais de SSO, abrindo a possibilidade de acesso a vários recursos dos sistemas da empresa
- Não se sabe a escala de uso do Connect to Server do Finder, mas vários documentos de ajuda de universidades e instituições de ensino orientavam estudantes e funcionários a usar esse recurso, e alguns recomendavam marcar a opção de salvar no Keychain
- Também foram encontradas instruções de fornecedores de servidores de impressão, e o NetAuthAgent também lida com credenciais de servidores de impressão
- Pelo menos um documento recomendava não marcar a opção de salvar porque atualizar senhas armazenadas pelo app Keychain Access seria difícil para usuários comuns
- Se, em dispositivos gerenciados, as mesmas credenciais também fossem usadas como credenciais de superusuário, poderia haver escalonamento de privilégio, mas isso não foi confirmado por falta de testes em dispositivos gerenciados
- Mesmo usuários domésticos que acessavam um NAS pelo Finder e salvavam as credenciais podiam ter essas credenciais expostas a um invasor
- Se as mesmas credenciais fossem reutilizadas em outras contas na internet, essas contas também poderiam ser comprometidas
- Como FTP, Samba e WebDAV têm interfaces bem definidas, após o vazamento de credenciais seria fácil automatizar a exploração e a exfiltração de arquivos do servidor
Exploração adicional usando o Keychain
- Como o NetAuthAgent também expunha rotinas para criar itens no Keychain, um processo malicioso podia esconder dados arbitrários no campo
password - Esse método podia servir como meio de ocultação de dados para driblar software de segurança, pois evita gravações diretas em disco
- Não há conhecimento de software de segurança que inspecione explicitamente itens suspeitos no Keychain
- Um processo malicioso também podia salvar credenciais legítimas no Keychain
- Isoladamente, esse comportamento pode ter efeito limitado, mas pode ser usado em ataques compostos, por exemplo salvando credenciais de um servidor de arquivos controlado pelo invasor e depois conduzindo o usuário por engenharia social
Cadeia de exploit que chega até tokens de API do iCloud
- Mesmo usuários que não usam o Connect to Server não estavam livres do impacto dessa vulnerabilidade
- Na maioria dos dispositivos macOS, existem itens do Keychain com ACL ampla o suficiente para que o NetAuthAgent possa acessá-los
- Esse item do Keychain contém uma chave de descriptografia usada para descriptografar um arquivo específico no disco
- Esse arquivo contém informações da conta iCloud e tokens de API do usuário
- Com o item do Keychain e o arquivo em localização conhecida, um invasor podia obter as seguintes informações
- nome e sobrenome
- endereço de e-mail
- alias de e-mail
- recursos habilitados e endpoint
- vários tokens de API de longa duração
O que é possível fazer com os tokens do iCloud
- Pesquisa anterior de Wojciech Reguła mostrou que os mesmos tokens de API, encontrados por outro método, podiam vazar os seguintes dados
- Contacts
- Calendars
- Reminders
- localização do usuário via Find My
- Entre esses resultados, todos exceto Reminders foram reproduzidos
- Em contas novas e contas migradas, o Reminders passou para o CloudKit, mais seguro, e ficou acessível apenas em forma criptografada
- Outras ações possíveis incluíam
- vazamento de fotos de contatos
- consultas ao CloudKit, embora sem descriptografia
- vazamento de dados do iCloud key-value store
- vazamento de metadados de backup do iCloud, incluindo número de série do dispositivo
- vazamento da localização de outros dispositivos do usuário via Find My
- vazamento da localização dos amigos do usuário via Find My
- execução de ações de bloqueio, apagamento e reprodução de som via Find My
- A descriptografia de dados do CloudKit foi investigada, mas não concluída
- Não se pode descartar que empresas comerciais de perícia usem esses tokens de API, junto com o PIN de um dispositivo iOS quando necessário, para descriptografar dados do CloudKit ou dados de CloudKit presentes em backups do iCloud
Como a Apple corrigiu o problema
- Após o patch, o NetAuthAgent verifica primeiro o entitlement do remetente ao receber uma mensagem
- Entitlement é um par chave-valor anexado ao binário durante a assinatura de código
- Em macOS com configuração de segurança padrão, o Apple Mobile File Integrity verifica entitlements restritos na execução do processo e encerra o processo se não houver provisioning profile adequado
- Como o provisioning profile precisa ser assinado pela Apple, essa verificação é projetada para ser difícil de contornar
- O entitlement exigido pelo NetAuthAgent é o seguinte
- chave:
com.apple.private.netauth.useragent.allow - valor: boolean
true
- chave:
- O NetAuthAgent não responde a remetentes sem esse entitlement
- O trailer anexado pelo kernel ao receber uma mensagem Mach inclui um audit token
- A task receptora pode usar o audit token para identificar a task remetente, pedir ao kernel o dicionário de entitlements dessa task e então verificar o valor
O elo fraco da arquitetura de segurança
- Mesmo que credenciais de servidor de arquivos sejam armazenadas de forma que só uma aplicação específica possa acessá-las, se essa aplicação aceita comandos de consulta vindos de outras aplicações, ela se torna o elo fraco
- Mesmo que tokens de API do iCloud estejam guardados em um arquivo criptografado no disco, se a chave de descriptografia estiver em um item do Keychain com ACL ampla, essa ACL se torna o elo fraco
- O macOS possui mecanismos de segurança que dificultam injeção em processos, e sua infraestrutura geral de segurança é considerada forte
- No entanto, como mostra essa vulnerabilidade, uma simples ausência de validação do remetente pode levar à exposição de credenciais de servidores de arquivos e de tokens de API do iCloud
Recomendações para usuários
- Se ainda for possível, recomenda-se ativar a Advanced Data Protection
- Se você não usa o iCloud no navegador, outra opção é desativar o acesso web aos dados do iCloud
- O site do iCloud às vezes usa endpoints de API diferentes dos apps iCloud da Apple
- Embora esta vulnerabilidade não permita mais acessar os tokens, eles já podem ter sido expostos por falhas anteriores e podem voltar a ser expostos por outras falhas no futuro
- Não há evidência de que esse exploit tenha sido usado ou descoberto por agentes maliciosos
- Ainda assim, se o abuso de credenciais for uma preocupação especial, as senhas devem ser alteradas
- Dispositivos que não foram atualizados desde outubro de 2024 devem ser atualizados imediatamente
1 comentários
Comentários do Hacker News
O texto está bem escrito e me lembrou o zero-day em que tentar senha vazia duas vezes permitia contornar o login de root, que a Apple aparentemente tentou abafar até certo ponto. Foi por volta de 2017, talvez 2018
Em qualquer caixa de login de root, se você colocasse um nome de usuário administrador e deixasse a senha em branco, na primeira tentativa aparecia que a senha estava errada, mas ao fechar o alerta e clicar pela segunda vez, entrava como aquele usuário
Era 100% reproduzível no mesmo dia e foi corrigido logo depois de se espalhar nas redes sociais, mas ainda assim pareceu uma falha enorme. Parece que ainda há muito resquício antigo em torno do mecanismo de autenticação do Mac, e também foi interessante a menção ao sistema de ports do kernel Mach
Quando o buffer do nome de usuário chegou a 256 caracteres aleatórios, o XDM travou e abriu um shell root. Mas isso foi no começo dos anos 90, quando todo mundo era muito mais ingênuo em relação à segurança
grep, e funcionava 100% das vezes“ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf
O artigo recebeu uma pequena correção: a verificação de entitlement não fica na camada Mach do kernel
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
Foi uma alteração de uma palavra para corrigir um erro factual na parte que explicava o funcionamento do XNU
A parte que diz que “expor um mecanismo pelo qual um processo faz com que outro processo, na prática, faça proxy de consultas ao keychain pode enfraquecer a segurança do sistema inteiro” parece um caso de problema do deputado confuso: https://en.wikipedia.org/wiki/Confused_deputy_problem
Um design baseado em capabilities deveria conseguir evitar esse tipo de problema de forma sistemática
Fiquei curioso para saber onde o autor disponibilizou de fato o código PoC. Queria testar algumas mitigação, mas vejo código de exemplo que parece incompleto
Qual é o nível de risco realista?
Em termos de risco, um app que consiga obter send rights para o NetAuthAgent — na prática, quase qualquer app sem sandbox — pode pedir silenciosamente ao NetAuthAgent credenciais salvas de unidades de arquivo como FTP, WebDAV e Samba. Isso também pode levar ao vazamento completo de contatos e calendários do iCloud, além de outros dados relacionados ao iCloud
O sandbox torna isso mais difícil, mas não impossível. Se estiver atualizado, o risco é zero, e o patch entrou em outubro do ano passado, então, sinceramente, seu sistema já deveria estar atualizado. Se você não atualizou e também não pretende atualizar, o risco é muito maior, a menos que consiga verificar sem exceção todos os processos em execução no dispositivo
É um texto muito detalhado, e gostei de como cobre até a história de vários kernels. Ainda assim, para um texto sobre um problema sério de segurança, seria bom ter logo no começo uma explicação bem curta sobre escopo do impacto, condições do ataque e se é falha lógica ou corrupção de memória
Bastaria algo simples, só o suficiente para decidir se vale a pena ler o restante
Texto realmente interessante. Eu não fazia ideia de que havia tantos bastidores no processo de criação do kernel Mach e do Darwin
A essa altura, Mach já parece uma fonte estável de bugs no macOS. Sei que a Apple vem fechando tudo com força, mas existe algum caminho para sair completamente do Mach?
Se o daemon não verificar entitlements, ele não é seguro. Em vez de culpar o mecanismo de mensagens, é melhor culpar a forma como ele é usado
Na verdade, qualquer sistema de mensagens fechado precisa de algo além de simples passagem de mensagens, como verificação do remetente, por exemplo. Isso não é algo que se obtenha automaticamente de um protocolo de comunicação de baixo nível como o Mach. A menos que a Apple reformule o compilador MIG para adicionar verificação de entitlement, continua assim
O Mach é excelente quando usado com verificação de entitlement
Tecnicamente, isso pode até aumentar a superfície potencial de ataque, já que mais componentes diferentes passam a coexistir. Mas superfícies mais especializadas podem simplificar o controle e, no fim, permitir proteger melhor essas superfícies