- O sistema de permissões TCC do macOS podia exibir pop-ups de solicitação de permissão enganosos para o usuário devido a uma falha
- Essa vulnerabilidade foi registrada como CVE-2025-31250 e o problema faz com que o consentimento do usuário se aplique a outro app
- Existe a possibilidade de um ataque de spoofing em que um app malicioso exibe a janela de solicitação de permissão com o nome de um app confiável para induzir o consentimento do usuário
- Foi corrigida no macOS Sequoia 15.5 da Apple, mas em outras versões ela ainda continua sem correção
- Além da dificuldade de verificar e revogar o histórico de permissões concedidas, há a possibilidade de vulnerabilidades semelhantes surgirem no futuro
Correção importante
- Essa vulnerabilidade foi corrigida no macOS Sequoia 15.5, mas ainda não recebeu correção no macOS Ventura 13.7.6 e no macOS Sonoma 14.7.6
- Foi confirmado que o autor do reporte não é mencionado nas notas de lançamento de segurança da Apple
- Foi feito um teste direto em máquina virtual com o macOS Sonoma 14.7.6 e verificado que a vulnerabilidade ainda pode ser explorada
- Presume-se que o Ventura 13.7.6 esteja na mesma situação
- Aguarda-se uma resposta oficial da Apple
Introdução
- A vulnerabilidade CVE-2025-31250 permite que um aplicativo exiba pop-ups falsos de solicitação de permissão no macOS
- Quando o "Application A" exibe o pop-up, ele aparece como "Application B", e no fim o consentimento de permissão do usuário é aplicado ao "Application C"
- Normalmente, os três aplicativos seriam o mesmo, mas essa falha permitia definir apps diferentes
- Isso gera um grande problema para a confiabilidade da janela de solicitação de permissões
- Métodos parecidos de "spoofing" já haviam sido apresentados antes em lugares como o HackTricks, mas esta vulnerabilidade usa uma abordagem mais simples
TCC
- O TCC é o sistema central de gerenciamento de permissões embutido nos sistemas operacionais da Apple
- As permissões são gerenciadas enviando mensagens ao daemon "tccd", e a API pública chama funções privadas do framework TCC
- O daemon se comunica por mensagens usando a API XPC da Apple
- Antes da correção desta vulnerabilidade, ao enviar mensagens arbitrárias era possível definir de forma diferente o app exibido no pop-up de solicitação de permissão e o app que realmente recebia a permissão
- Para entender por que essa falha existia, é preciso olhar para os Apple Events
Apple Events
O que são Apple Events
- Apple Events são um mecanismo de comunicação entre processos de apps no macOS
- É um protocolo que existe desde a era dos livros clássicos publicados em 1993
- Mesmo após a introdução do macOS X, ele foi redesenhado para se adequar à nova arquitetura e continuou em uso
- Hoje, é usado principalmente para automação (Automation), com scripts em AppleScript e JavaScript
- É semelhante ao Script Host do Windows e já foi explorado como vetor de malware
Apple Events e TCC
- Desde o macOS Mojave 10.14, é obrigatório o consentimento do usuário para enviar Apple Events
- No banco de dados de permissões do TCC (TCC.db), ficam registrados o app solicitante, o serviço e a resposta de consentimento
- Como os Apple Events precisam ter permissões gerenciadas separadamente para cada app receptor, é usada a coluna indirect object do TCC.db
- A função TCCAccessRequestIndirect do daemon TCC processa mensagens que utilizam essa coluna
- Havia um bug lógico nessa função, permitindo definir de forma diferente o app mostrado ao usuário e o app que realmente recebia a permissão
Prova de conceito (Proof-of-Concept)
- O exemplo de código em Swift manipula a mensagem de solicitação de permissão da seguinte forma
- Expõe ao usuário, no pop-up de consentimento, o nome do app no caminho "spoofedBundle"
- Define o bundle ID de "actualBundle" como o verdadeiro destinatário da permissão
- Como resultado, o usuário vê como se um app confiável estivesse pedindo a permissão, mas a permissão real vai para o app malicioso
- Mesmo deixando o valor de "indirect_object" vazio, ainda era possível atacar vários serviços TCC
- Isso provoca um colapso da confiabilidade do consentimento de permissões do usuário
- O atacante pode enganar o usuário e induzir a concessão de permissão a um app arbitrário
Exploração da vulnerabilidade
Limitações e particularidades
- Apenas certos serviços do TCC são vulneráveis ao ataque, mas serviços importantes como Microphone e Camera estão entre os alvos
- No caso de permissões de arquivos e pastas, o efeito é menor por causa de proteções adicionais
- O app malicioso pode ser usado junto com técnicas de engenharia social para fazer o usuário consentir no lugar de outro app que realmente precisaria da permissão
A importância do timing
- O momento de exibir o pop-up é importante
- Um app malicioso pode detectar apps em execução e qual app está em primeiro plano, exibindo o pop-up no momento adequado para confundir o usuário
- Por exemplo, ao abrir o FaceTime, exibir um pop-up de permissão da Camera pode levar o usuário a confundi-lo com uma solicitação legítima
- Também é possível um cenário de spoofing de solicitação de permissão do Microphone ao abrir o Voice Memos
- Se o ataque explorar um momento coerente com o contexto, a taxa de sucesso tende a ser maior
Relembrando vulnerabilidades passadas
- Já existiram vulnerabilidades que exploravam o fato de o caminho do TCC.db ser determinado de acordo com a pasta home do usuário
- Até 2020, bastava mudar a variável de ambiente
HOME para usar um TCC.db falso ($HOMERun)
- Mesmo após a correção, ainda são necessários privilégios de root e consentimento do usuário, mas, combinando isso com spoofing por engenharia social, ainda é possível contornar permissões
- Um app malicioso pode induzir o consentimento do usuário e depois alterar a pasta home e adicionar um banco de dados registrado para contornar o sistema com um TCC.db falso
- Foi confirmado em testes reais que esse método podia afetar o funcionamento do TCC
Linha do tempo
1.
- 2024-05-02 : Reporte inicial enviado ao Apple Product Security, junto com mensagens adicionais
2.
- 2024-05-03 : Apple Product Security pediu explicações adicionais e recebeu resposta
- No mesmo dia, foi descoberta a possibilidade de contornar todo o TCC e isso foi reportado novamente à Apple
3.
- 2024-05-04 : Continuação dos testes de PoC e envio de mais atualizações
4.
- 2024-05-06 : Apple Product Security agradeceu pelas informações fornecidas
5.
- Depois disso, continuaram consultas frequentes sobre o status da correção e verificações de situação; entre 2024-06 e 2025-02 houve comunicação contínua com a Apple, mas a falha ficou sem correção por muito tempo
6.
- 2025-05-12 : Foi lançada a correção para esse bug
Conclusão
Outros pontos
- O TCC aparece no app System Settings, em Privacy & Security (antigo Security & Privacy), e também na respectiva seção de automação
- Porém, como os registros de consentimento relacionados a Apple Events não aparecem na interface gráfica, é difícil para o usuário revogá-los manualmente
- É possível revogar usando a ferramenta de linha de comando
tccutil, mas isso é pouco conhecido
- Recentemente, o framework Apple Endpoint Security ganhou um recurso de monitoramento de alterações no banco de dados do TCC
- Se funcionar corretamente, isso pode ajudar a evitar abusos ao informar ao usuário qual app realmente recebeu a permissão
Correção da Apple
- O conteúdo real da correção é complexo, mas o
tccd foi alterado para ignorar silenciosamente mensagens externas nas quais o indirect object tenha sido definido arbitrariamente
- A verificação do comportamento mostrou que o spoofing não é mais possível
- Se a correção for incompleta, atualizações futuras poderão exigir medidas adicionais
Considerações finais
- Foi dado a esta vulnerabilidade o nome "TCC, Who?"
- Do ponto de vista de um pesquisador de segurança, ela reforça novamente a importância da confiabilidade dos sistemas de permissões
- Também sugere que falhas semelhantes ainda poderão ser encontradas no futuro
- A implicação é que os usuários não devem confiar cegamente nos pop-ups de permissão do macOS
1 comentários
Comentários no Hacker News
Apostando na pequena chance de alguém da Apple ver isto, vou repetir algo que sempre quis pedir: gostaria que a Apple parasse de exibir aleatoriamente diálogos de “digite agora sua senha de (administrador local)” sempre que der vontade ao computador de atualizar ou instalar alguma coisa. Com conhecimentos básicos, é fácil criar na web um popup falso quase idêntico, e a maioria dos usuários, exceto talvez os 20% mais técnicos, nem cogita perceber se aquilo é real ou uma falsificação feita dentro do navegador. Para bloquear esse tipo de problema pela raiz, é preciso acostumar o usuário à ideia de que software legítimo não mostra de repente, sem aviso, um diálogo pedindo senha no meio do trabalho; mas a UI de segurança atual do macOS faz exatamente o oposto. Isso deveria mudar para algo como mostrar um ícone colorido e chamativo na barra de menus, ou exibir brevemente uma tela de segurança como o Windows faz. O design atual da UI é realmente problemático
O que mais odeio nesses popups é que eu não faço ideia de por que isso está sendo pedido, o que acontece se eu recusar, nem o que teria de fazer depois se quisesse mudar essa configuração. Quando o app orienta “abra o painel de ajustes e conceda a permissão XXX”, você consegue ver claramente qual app, qual permissão e qual alternância estão envolvidos, mas o popup de senha não oferece essa UX. Foi por isso que passei a gostar menos da ideia de “capabilities”: a UX é tão ruim que quase não tem solução. Vai acabar aparecendo algo como “para usar completamente o app, permita <root my computer>”, porque se o fornecedor define a mensagem, sempre vira algo assim. É uma UX que não ajuda em nada
Acho que isso seria um pouco menos frequente se o macOS ainda mostrasse janelas modais anexadas à janela do app. Não resolveria totalmente, mas seria melhor. Quando a modal fica sobre a barra de ferramentas como agora, a sensação imediata é de que ela faz parte do app. O próprio Steve Jobs, quando apresentou o Aqua, enfatizou que essas modais soltas prejudicavam a usabilidade, mas agora isso virou assim por causa de uma estranha obsessão da Apple em querer usar UI de celular em todas as telas
Meus familiares sem conhecimento técnico não conseguem distinguir a senha local do dispositivo da senha do iCloud/Apple ID, então acabam digitando qualquer uma até alguma funcionar — e isso acontece porque a UI é pouco clara e inconsistente. A Apple costumava zombar do UAC do Vista, mas agora eles mesmos criaram um monte de alertas repentinos e UI malfeita
Migrei recentemente do Linux para o Mac, e esses popups aleatórios pedindo senha de root me deixaram realmente confuso. Não havia nenhuma explicação sobre qual app ou comando estava pedindo privilégios de root, nem por que precisava disso, então depois de permitir algumas vezes, passei a simplesmente recusar. Desde então, os popups não apareceram mais. Mas continuo sem saber para que eles apareciam, nem por que pararam
Queria recomendar mais uma vez este texto clássico: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
O popup de Passkey é um erro particularmente grave de segurança, porque não se distingue em nada de um popup em JavaScript
Nessas situações, sou muito grato ao leitor de digitais integrado. Normalmente deixo a tela do notebook fechada e uso só monitor externo, mas quando preciso de autenticação do sistema, eu a abro de propósito e autentico com a digital
Reviravolta: na verdade, esse diálogo nunca existiu! Você já caiu no golpe
Quero aproveitar o comentário mais popular no momento para avisar: este artigo recebeu uma atualização importante: https://news.ycombinator.com/item?id=43969087
Fico curioso sobre qual é o modelo de ameaça ao clicar num popup falso. Se não for realmente o sistema, isso não seria apenas uma interação sem efeito?
Ao entrar no iCloud, aparece um popup pedindo a senha local do computador, e ao digitá-la, essa senha é enviada para os servidores do iCloud
Recentemente descobri que apps do mac deveriam ser instalados em Applications dentro do meu diretório home, e não em Applications do sistema (~/Applications), claro que isso só faz sentido num computador usado por uma única pessoa. Se eu me coloco como usuário não administrador e instalo os apps em Applications do diretório home, aquelas solicitações irritantes de permissão para atualizar deixam de aparecer. A maioria dos apps se atualiza sozinha mesmo sem privilégios de administrador. Exceções como o Tailscale, que precisam de integração com o SO, ainda exigem permissões separadas. Aliás, essa foi uma recomendação do app Pareto Security
Infelizmente, quase nenhum desenvolvedor de apps conhece essa abordagem, e muitos apps exigem ser instalados especificamente em /Applications e nem funcionam em outro lugar
Instalar apps em ~/Applications permite atualização automática sem root, mas em compensação também facilita que código suspeito seja sobrescrito sem root
Estou usando o macOS 15.4.1 e a própria pasta ~/Applications não existe
Achei interessante! Eu preciso de uma conta admin no dia a dia, então esse método é difícil para mim, mas para quem se encaixa no caso parece realmente útil
Este artigo precisa de uma correção importante. Antes eu disse que o CVE tinha sido corrigido no macOS Sequoia 15.5, mas na verdade o patch não foi aplicado no macOS Ventura 13.7.6 nem no macOS Sonoma 14.7.6, que saíram no mesmo dia. Eu escrevi isso assumindo que a Apple obviamente teria colocado o patch em todas as versões, mas depois de verificar as notas de lançamento de segurança e ver que meu nome não aparecia nas outras duas versões, entrei em contato diretamente com a Apple. Ainda não recebi resposta. Para testar por conta própria, subi uma VM, apliquei o patch no macOS Sonoma 14.7.6 e executei meu PoC — a vulnerabilidade continua funcionando. Imagino que o mesmo aconteça no Ventura 13.7.6. Não entendo por que a Apple não incluiu o patch. Vou atualizar o texto novamente se houver mais informações
O sistema TCC do macOS tem fama de ser um mecanismo robusto de privacidade, mas é amargo lembrar que, na prática, ele pode ser contornado facilmente com uma única entrada no banco de dados. O popup de consentimento do usuário tem pouco significado diante da manipulação real do banco, especialmente em ambientes de desenvolvimento com o SIP desativado. No fim, isso é uma questão de confiança. Fica a dúvida se o consentimento na camada de UX ainda representa uma fronteira de segurança real. Estamos dependendo cada vez mais de popups de permissão no nível do SO, e se essa fronteira na prática é uma ilusão — ou apenas encenação — então talvez seja hora de repensar a confiança em permissões não como algo que se “mostra”, mas como algo que se mantém de verdade
Lembro de como aqueles anúncios “I'm a Mac and I'm a PC” zombavam desse tipo de coisa no Vista. E agora meu Mac está pior do que o Vista. É realmente irritante
O trade-off entre segurança e extensibilidade parece inevitável. Ainda assim, o ponto de referência também mudou desde aquela época. Pelo menos o macOS não está cheio de processos maliciosos como o Windows de antigamente. Ou talvez eu só tenha tido sorte e sido cuidadoso
Perguntando por curiosidade: o que especificamente te irritou tanto?
O sistema TCC foi mal concebido desde o início. Ele só atrapalha desenvolvedores legítimos e bombardeia usuários com popups de solicitação de permissão, enquanto apps maliciosos continuam contornando esse “teatro de segurança” por vários caminhos, como pesquisadores seguem mostrando. Não sou pesquisador de segurança, mas como desenvolvedor Mac eu também já encontrei várias formas de burlar isso. Às vezes eu me pergunto se os próprios engenheiros da Apple realmente entendem a tecnologia que usam. Fico curioso para saber quantos desenvolvedores Mac tradicionais ainda restam
Uso um Mac da empresa e periodicamente aparece um alerta dizendo “o Slack está tentando instalar uma nova helper tool”. Não faço ideia do que seja isso nem por que aparece. Perguntei ao time de TI e eles também não sabiam como verificar. Penso com frequência que isso poderia ser explorado de forma maliciosa, porque continua pedindo senha, e mesmo quando eu clico em cancelar, volta a aparecer
Esse diálogo vem do framework System Management. É o processo de instalar uma helper tool com privilégios elevados para que o Slack consiga se atualizar sozinho independentemente de onde foi instalado ou de qual usuário o instalou
Sempre que esse popup aparece, não há como saber em que informação eu deveria me basear para decidir entre permitir ou recusar, então acabo sempre clicando em cancelar
Eu uso o Slack como web app — mas em janela separada, não dentro do navegador — https://support.apple.com/en-us/104996 O Discord também pode ser usado assim. Na prática, acho muito mais agradável do que apps Electron. Para a maioria dos apps Electron, esse formato é melhor
Nunca vi pessoalmente um popup de “helper tool”, mas não entendo por que um app simples de mensagens como o Slack precisaria desse tipo de privilégio. Vale perguntar ao suporte do Slack — e torcer para receber uma resposta de verdade
Assim como qualquer app que precisa de senha — por exemplo, binários que no Linux rodam apenas como root — certamente existe potencial de abuso. No fim, tudo depende de você confiar no desenvolvedor e em o app ser realmente aquele que diz ser. No dia em que a Apple impedir completamente que apps externos recebam privilégios de root, o Mac terá virado um ecossistema totalmente fechado, e este lugar aqui no HN vai encher de comentários reclamando. Em resumo, é importante manter uma “boa desconfiança” e não dar root a apps como o Slack quando não há uma necessidade clara
Ele rouba o foco de entrada à força, e o texto que eu estava digitando numa mensagem de repente começa a ser inserido no campo da senha. É uma experiência extremamente irritante
Esses popups vão se acumulando com atraso. Depois do fim de semana, quando ligo o computador, eles aparecem repetidamente, então acabo fechando o Slack. Isso acontece há um ano. Não sei como revogar essa permissão do lado do Slack, e isso parece meio malicioso
Ferramentas de bloqueio de “segurança” desse tipo são realmente estúpidas. Na prática, elas treinam as pessoas para serem mais burras. Hoje pode ser de verdade, amanhã pode não ser. Eu vivo recebendo ligações de bancos pedindo meus dados pessoais em nome de “proteger minha identidade”, e esse tipo de mecanismo só ensina as pessoas a entregar informações pessoais para desconhecidos
Não sou desenvolvedor de macOS, mas sempre tive curiosidade se qualquer app — inclusive malicioso — poderia imitar o estilo de popup do sistema e roubar a senha do usuário
O VSCode também mostra o mesmo popup no Mac fornecido pela empresa. Há anos eu simplesmente ignoro
Isso acontece com todos os apps baseados em Electron quando você usa várias contas de usuário do SO
O nordVPN apresenta o mesmo comportamento
A Apple levou exatamente 1 ano para lançar um patch. Parece bastante tempo. <i>2024-05-04 deixei várias mensagens de atualização, continuei testando o PoC</i> <i>2025-05-12 o patch foi lançado</i>
O Adobe Creative Cloud continua executando vários processos em segundo plano mesmo quando a execução em segundo plano é explicitamente desativada nos ajustes do sistema
Gosto muito da pesquisa dessa pessoa, e ela também apresenta muito bem