Os pop-ups de permissão do macOS são confiáveis?

• CVE-2025-31250 é uma vulnerabilidade que tornou difícil confiar nos pop-ups de consentimento de permissões do TCC no macOS, pois permitia que o app exibido na tela fosse diferente do app que realmente recebia a permissão
• O problema estava no processamento de TCCAccessRequestIndirect pelo tccd, em que target_path era usado para o nome do app mostrado no pop-up, enquanto target_identifier era usado para o identificador do app que de fato receberia a permissão
• Diferente de bypasses anteriores, não era necessário usar app falso, atalho no Dock nem indução de clique do usuário; se o usuário clicasse em Allow no pop-up falsificado, o ataque poderia funcionar
• A Apple corrigiu o problema no macOS Sequoia 15.5, mas confirmou que Ventura 13.7.6 e Sonoma 14.7.6, lançados no mesmo dia, não receberam o patch e não há plano de correção para versões anteriores
• Um invasor pode tentar falsificar pop-ups de permissão no momento em que apps como FaceTime, Voice Memos e System Settings forem abertos, criando o risco de o usuário confundir qual app está realmente recebendo a permissão

---

Funcionamento central do CVE-2025-31250

• CVE-2025-31250 era uma vulnerabilidade que permitia fazer o app mostrado no pop-up de permissão do TCC no macOS ser diferente do app que realmente recebia a permissão
• Antes do patch, a seguinte configuração era possível
  • Application A solicitava ao macOS a exibição de um pop-up de consentimento de permissão
  • O pop-up parecia vir de Application B
  • O resultado do consentimento do usuário era aplicado a Application C
• Os três apps podiam ser diferentes, embora em uso normal seja mais provável que sejam o mesmo app
• O problema central era a falta de validação suficiente quando o app exibido no pop-up e o app que realmente recebia a permissão eram diferentes

Escopo do patch e correções de informação

• Ao contrário da explicação inicial, o patch foi aplicado apenas ao macOS Sequoia 15.5
• macOS Ventura 13.7.6 e macOS Sonoma 14.7.6, lançados no mesmo dia, não receberam a correção
• Ao compilar e executar a PoC em uma máquina virtual com Sonoma 14.7.6, a vulnerabilidade continuou funcionando
• A Apple Product Security alterou o status do relatório para “We’ve addressed the issue in all planned releases.” e depois confirmou que não há plano de patch para Ventura e Sonoma
• Como resultado, Ventura e Sonoma permanecem vulneráveis a esse problema

Onde TCC e Apple Events se encontram

• TCC é o principal sistema de permissões dos sistemas operacionais da Apple e funciona internamente por meio do daemon tccd e do framework privado TCC
• Desenvolvedores não chamam diretamente a API privada, mas APIs públicas acionam internamente funções do TCC quando necessário
• O tccd recebe mensagens usando a API XPC da Apple
• Antes do patch, um app capaz de enviar mensagens XPC para o tccd podia mandar mensagens manipuladas e separar o app mostrado no pop-up do app que realmente recebia a permissão

Apple Events e o modelo de dados do TCC

• Apple Events é o mecanismo de comunicação entre processos no macOS e hoje é usado principalmente para automação
• A automação com Apple Events pode ser roteirizada por meio da Open Scripting Architecture da Apple
  • A linguagem mais representativa é AppleScript
  • JavaScript também pode ser usado
• Desde o macOS Mojave 10.14, apps precisam de consentimento do usuário via TCC para enviar Apple Events
• Os resultados de consentimento do TCC são armazenados no banco de dados SQLite Application Support/com.apple.TCC/TCC.db, dentro da pasta pessoal do usuário
• Uma entrada comum do TCC contém o app solicitante, o serviço solicitado e o resultado do consentimento do usuário
• Como o Apple Events precisa restringir permissões por app receptor, ele usa a coluna indirect object
  • Essa coluna contém o identificador do app que receberá os Apple Events
  • Além de Apple Events, o serviço FileProviderDomain também usa essa coluna

Estrutura da mensagem XPC vulnerável

• O problema estava em um bug lógico na função TCCAccessRequestIndirect
• Essa função processa solicitações de acesso que precisam usar a coluna indirect object do TCC.db
• O núcleo da PoC é separar dois campos quando target_prompt é 2
  • target_path: usado para obter o nome do app exibido no pop-up de permissão da interface gráfica
  • target_identifier: usado como o bundle ID do app que realmente recebe a permissão e é gravado no banco de dados
• Embora TCCAccessRequestIndirect seja uma função para indirect object, ela também podia ser usada com vários serviços TCC que não usam essa coluna, bastando passar uma string vazia como indirect object
• Esse bug não existia em outras funções de solicitação de acesso

Condições e limitações de exploração

• A exploração só tem sucesso se o usuário clicar em Allow no pop-up de permissão
• Os serviços TCC utilizáveis eram limitados, mas incluíam serviços importantes como Microphone e Camera
• Também era possível falsificar pop-ups de permissão para acesso a diretórios específicos, mas isso era menos útil por causa de camadas extras de segurança em torno de arquivos
• Um app malicioso também podia fazer com que a permissão fosse aplicada não a ele próprio, mas a outro app
  • Isso cria um caminho útil quando o invasor consegue controlar outro app, mas esse app precisa de permissões TCC

Enganando com o timing do pop-up

• Se um pop-up de permissão surgir aleatoriamente, o usuário pode desconfiar e clicar em Don’t Allow
• Apps no macOS podem verificar a lista de aplicativos em execução e qual app está em primeiro plano no momento
  • Ver apps em execução: NSWorkspace runningApplications
  • Ver o app em primeiro plano: NSWorkspace frontmostApplication
• Um app malicioso pode esperar até que um app específico seja executado ou fique em primeiro plano e então exibir um pop-up de permissão falsificado usando o nome desse app
• Por exemplo, é possível falsificar um pop-up de permissão de Camera ao abrir o FaceTime, ou um de Microphone ao abrir o Voice Memos
• O usuário pode interpretar o pop-up exibido logo após abrir ou alternar para um app como uma solicitação legítima daquele app

Relação com caminhos anteriores de bypass do TCC

• Antes, era possível burlar o TCC porque o tccd usava a variável de ambiente HOME para determinar a pasta pessoal do usuário, permitindo empregar uma pasta pessoal falsa com um TCC.db falso
• Esse problema foi corrigido em uma atualização de meados de julho de 2020, e depois disso o tccd passou a buscar a pasta pessoal no diretório de informações do usuário do sistema operacional
• Mesmo depois disso, continuaram surgindo casos de bypass explorando alteração da pasta pessoal do usuário
  • Wojciech Reguła divulgou o CVE-2020-27937, explorando o sistema de plugins do editor de diretório de informações do usuário na interface gráfica do macOS
  • A equipe Microsoft Threat Intelligence divulgou o bypass powerdir usando comandos de import/export
• Em geral, alterar a pasta pessoal do usuário exige duas coisas
  • privilégios de root
  • consentimento do usuário para determinados serviços TCC
• O CVE-2025-31250 não contorna a exigência de privilégios de root, mas permite induzir o consentimento TCC necessário por meio de um pop-up falsificado
• Se um app malicioso enganar o usuário para obter consentimento e também conseguir escalar para root, torna-se viável alterar o diretório de informações do usuário e implantar um TCC.db falso
• O REG.db rastreia TCC.db válidos, mas o TCC tem uma função que permite a um app adicionar entradas ao REG.db, possibilitando incluir o caminho do TCC.db implantado

Limites da gestão de permissões visível ao usuário

• O TCC é o sistema por trás do painel Privacy & Security em System Settings
• Resultados de consentimento relacionados a Apple Events aparecem na seção Automation
• No painel Privacy & Security, o usuário pode revisar permissões concedidas e, em muitos casos, revogá-las
• No entanto, quando um invasor enganava o usuário para permitir permissões de Apple Events, esse resultado de consentimento não aparecia no System Settings
• O usuário pode revogar permissões com a ferramenta de linha de comando tccutil, mas ela tem documentação limitada e é pouco conhecida pela maioria dos usuários
  • A documentação da Apple inclui um Technical Q&A antigo e uma página de treinamento de TI

Endpoint Security e possibilidade de detecção

• O framework Endpoint Security da Apple passou recentemente a oferecer suporte ao monitoramento de modificações no banco de dados do TCC
• O texto da Objective-See sobre essa mudança é: Endpoint Security TCC database monitoring
• Se esse recurso funcionar como esperado, apps que usam o framework poderão avisar o usuário depois do fato sobre qual app realmente recebeu a permissão
• Ainda assim, essa possibilidade de detecção só teve relevância direta no curto período entre a adição do evento no Endpoint Security e o patch da vulnerabilidade

Como a Apple corrigiu

• A análise do binário tccd no macOS Sequoia 15.5 mostrou que o patch final era mais complexo do que se supunha inicialmente
• Depois da correção, não é mais possível falsificar pop-ups do TCC da mesma forma
• Também parece ter sido restringido o uso de TCCAccessRequestIndirect com outros serviços TCC ao passar uma string vazia como indirect object
• Mensagens no formato vulnerável agora parecem ser descartadas silenciosamente pelo tccd, sem produzir qualquer efeito
• Em uma validação simples, o patch pareceu bom, mas ainda é necessária análise adicional para entender completamente o comportamento

Fluxo do relatório até o patch

• Essa foi a segunda vulnerabilidade reportada à Apple pelo pesquisador e o caso entre os relatórios corrigidos pela Apple que mais demorou para receber patch
• O processo de reporte incluiu envio inicial, pedidos da Apple Product Security por explicações adicionais, compartilhamento de um caminho potencial de bypass completo do TCC, atualizações de teste da PoC, confirmação do estado de reprodução e várias consultas sobre o andamento
• O patch simples proposto consistia em validar se os dois campos apontavam para o mesmo app
• A Apple respondeu várias vezes que estava investigando, depois pediu o nome para crédito e por fim lançou o patch
• A vulnerabilidade recebeu o nome “TCC, Who?”