- Foi descoberta uma vulnerabilidade no M365 Copilot que impedia o registro de logs de auditoria, causando um problema em que acessos a arquivos não ficavam registrados no log
- Bastava pedir ao Copilot para agir de uma determinada forma para que fosse possível acessar arquivos sem qualquer registro de auditoria, o que pode levar a riscos de ameaça interna e violações de exigências regulatórias e legais
- O pesquisador reportou o caso ao MSRC, mas a Microsoft não emitiu um CVE nem avisou os clientes, apesar de sua política oficial indicar o contrário
- A Microsoft classificou a falha apenas no nível Important e decidiu que, como o problema foi corrigido por atualização automática, não seria necessário um aviso separado
- No entanto, isso pode causar graves problemas de segurança e jurídicos para empresas de setores regulados que dependem de logs de auditoria, como os sujeitos à HIPAA, e a falta de transparência da Microsoft vem sendo fortemente criticada
Vulnerabilidade nos logs de auditoria do Copilot: visão geral e impacto
- Foi encontrada uma falha no Copilot, principal serviço de IA que a Microsoft vem promovendo ativamente, em que o histórico de acesso a arquivos não era registrado nos logs de auditoria dependendo da solicitação do usuário
- Em condições normais, quando o M365 Copilot resume um arquivo, o acesso àquele arquivo deve ser registrado no log de auditoria, o que é um elemento central da segurança da informação dentro das organizações
- Porém, ao pedir ao Copilot que não incluísse links para os arquivos no resultado do resumo, ocorria o fenômeno de esse log simplesmente não ser registrado
- Por exemplo, mesmo que um funcionário consultasse em massa vários arquivos pelo Copilot antes de sair da empresa, poderia vazar essas informações sem deixar rastros e sem logs
- Essa vulnerabilidade não exigia um ataque elaborado; ela podia ocorrer naturalmente e até por acaso, tendo sido descoberta pelo autor do blog durante testes internos de funcionalidades
- Michael Bargury, CTO da Zenity, também já havia identificado essa vulnerabilidade e a reportado à Microsoft um ano antes, mas ela permaneceu sem tratamento por um longo período até este novo relato
Problemas no MSRC (relato de vulnerabilidades) e falta de reconhecimento da resposta
- A Microsoft fornece uma orientação oficial e um processo para relatos de vulnerabilidades, mas, na prática, não os segue adequadamente durante o tratamento dos casos
- Depois que o autor reportou o caso ao MSRC, ocorreu uma situação confusa em que a funcionalidade do Copilot mudou imediatamente, mesmo sem terem sido seguidos os passos de reprodução
- Houve mudanças no status do relato (reprodução → desenvolvimento etc.), mas faltou comunicação clara sobre o andamento e sobre os motivos das decisões tomadas
- Sobre a emissão de um CVE para vulnerabilidades de segurança, foi informado que um número oficial só é atribuído quando o cliente precisa tomar uma ação direta
- No entanto, isso difere da política anterior da Microsoft, e essa vulnerabilidade foi apenas classificada como Important, sem divulgação ou notificação específica
- De forma geral, o próprio acompanhamento do progresso parecia ser atualizado apenas de forma visível, sem relação real com as ações tomadas, o que tornou a experiência ineficiente e pouco transparente para quem fez o relato
Problemas da ausência de anúncio e de aviso aos clientes
- A Microsoft decidiu não emitir um CVE nem avisar os clientes sobre essa vulnerabilidade
- Como se trata de um erro que pode ocorrer facilmente até por engano, existe a possibilidade de que, em organizações reais, os logs de auditoria tenham sido registrados incorretamente por muito tempo
- Mesmo havendo muitas organizações, como instituições de saúde (ex.: HIPAA), que utilizam logs de auditoria para fins legais e regulatórios, a Microsoft não informou os usuários sobre o impacto
- Logs de auditoria são usados de forma central em segurança organizacional, resposta a incidentes e provas legais, mas a Microsoft manteve silêncio sobre o caso
- Essa abordagem sugere que outros possíveis problemas de segurança também podem estar sendo tratados sem divulgação, levantando sérias dúvidas sobre a confiabilidade da empresa
1 comentários
Opinião do Hacker News
Trabalho no desenvolvimento de chatbots internos da empresa e tenho dificuldade para explicar à diretoria que, se o chatbot não verificar todas as permissões do usuário atual ao acessar documentos confidenciais, inevitavelmente surgirá um caminho para vazamento de informações
Bancos de dados vetoriais, índices de busca, AI Search Database e afins precisam existir por usuário ou rastrear permissões de acesso junto com o conteúdo
Quero enfatizar que permissões de acesso são muito complexas, podem mudar a qualquer momento, são difíceis de aplicar em larga escala e vulneráveis a condições de corrida
Este é um caso concreto do problema de "Confused Deputy"
Corresponde aos riscos LLM02:2025, "Sensitive Information Disclosure", e LLM06:2025, "Excessive Agency", do OWASP LLM Top 10
Algumas soluções corporativas de RAG resolvem isso criando índices por usuário por causa dos diversos ACLs
Cada fornecedor gerencia esse tipo de problema de permissão de forma diferente, então é essencial verificar esse ponto ao analisar uma solução de RAG
No Japão isso é chamado de "confusão de permissões" (権限混同), e acho um nome interessante
Veja a explicação de Confused Deputy, Veja os riscos do OWASP LLM Top 10
Fico curioso para saber por que você considera rastrear as permissões de acesso do usuário um problema de escalabilidade
Quando chega uma consulta, basta encontrar os documentos correspondentes no banco vetorial ou no índice e passar ao LLM apenas aqueles aos quais o usuário pode acessar
É como um atendente de banco que só pode ver as informações do cliente autenticado, então não haveria como vazar dados de outra pessoa por engano; e, se não houver autenticação, nem o operador poderia ver dados alheios, então eu pensaria que não há risco de abuso
Quando se bate nesse tipo de parede, na prática talvez não seja que eu tenha falhado em me comunicar nem que a diretoria não entenda
Provavelmente a diretoria já decidiu ignorar o problema e, se houver vazamento depois, pretende jogar a culpa nos engenheiros
Se você está tendo dificuldade para explicar o problema à diretoria, colocar Jurídico/Compliance em cópia pode surtir efeito
Só que alguns executivos obcecados por buzzwords podem se incomodar com isso
A maioria dos bancos de dados vetoriais permite anexar metadados aos vetores
Se você armazenar como metadado a lista de entidades com permissão de acesso, como RH ou executivos, pode expandir o usuário para esses papéis no momento da solicitação e filtrar com base nisso
Assim, os documentos que o usuário não pode ver já são excluídos desde o início
Só que, sempre que as permissões de um documento mudarem, os metadados vetoriais também precisam ser atualizados imediatamente
É problemático que o Copilot contorne os logs de auditoria e opere como um usuário privilegiado
Não acho que isso deveria ser possível
O Copilot na verdade não está acessando o arquivo diretamente; ele está lendo o conteúdo de arquivos já indexados por meio do mecanismo de busca
A Microsoft deveria auditar o histórico de buscas do Copilot; registrar como se o Copilot tivesse acessado o arquivo quando ele só leu o índice pode induzir a erro
É como dizer que alguém visitou um site diretamente só porque viu o resultado dele no Google
A Microsoft está tão focada em enfiar integração com IA em tudo que vem negligenciando os logs de auditoria
No Windows, um processo com privilégio de Backup pode contornar todas as permissões de acesso e, por padrão, não gera auditoria
No caso de apps de backup, isso acontece porque o volume de logs de auditoria ficaria enorme; esse privilégio precisa ser ativado explicitamente e isso é fácil até em código gerenciado como C#
O mesmo vale para o privilégio de Restore
Esse fenômeno é parecido com os problemas de quando o Delve foi lançado pela primeira vez e houve falhas de permission trimming, expondo resultados nas buscas de usuários, ou quando a busca do SharePoint mostrava parcialmente documentos que existiam, mas não podiam ser acessados
Por exemplo, se você buscasse por "Fall 2025 layoffs", bastava existir um documento relacionado para ele aparecer, o que gerava um problema de segurança
A impressão continua sendo que, para a Microsoft, segurança ainda fica em segundo plano
Um título melhor seria "O Microsoft Copilot não está em conformidade com a HIPAA"
Acho que com esse título o problema seria resolvido bem mais rápido
Indo além, todo sistema útil de busca com IA é inseguro por projeto, porque esses vetores de RAG armazenados no banco vetorial acabam sendo uma forma de compressão com perdas dos documentos
O problema já foi corrigido
A reclamação agora é que os clientes não foram notificados
“CVEs são atribuídos a releases de segurança distribuídos quando os clientes precisam tomar medidas para se proteger. Neste caso, a correção foi distribuída automaticamente ao Copilot e, como o usuário não precisa atualizar nada manualmente, não foi atribuído um CVE”
Fico curioso se isso é uma característica essencial dos CVEs ou se é só a forma como a Microsoft está usando CVEs
Seria bom ter algum identificador comum para referenciar vulnerabilidades desse tipo, e acho que deveria existir um sistema de numeração separado, não dependente do fornecedor
Para a Microsoft, um CVE serve para rastrear incidentes/vulnerabilidades de segurança
Mesmo que seja possível aplicar um patch urgente de forma incomum, isso não faz o incidente deixar de ser um incidente de segurança
A Microsoft vem demonstrando cada vez mais pouca transparência e baixa confiabilidade na divulgação de incidentes de segurança, então nesses casos a divulgação é ainda mais importante
Isso parece menos uma limitação do CVE e mais a Microsoft entortando o processo de CVE por razões de RP
O "C" de CVE significa Common
Ou seja, é um sistema focado em "comum"
No momento também estamos tentando tirar apps LOB importantes da Microsoft
Depois de vários hacks nos últimos meses, zero-days de SSO e de ver o Copilot ignorando permissões porque o indexador atua como admin global, a preocupação só aumenta
Há tantos problemas possíveis em deixar auditoria e logs de atividade diretamente nas mãos de um LLM que é difícil até contabilizar
Por isso fico curioso sobre como corrigiram esse bug desta vez; será que introduziram um "shadow prompt"?
Em nenhum ponto do post diz que o LLM gerencia diretamente os logs de auditoria
Pelo contrário: parece que o log de auditoria é registrado pela camada superior de scaffolding, não pelo LLM, mas escolheram errado o "momento" em que o log deveria ser gerado
Por exemplo, em vez de registrar no momento em que alguém clica num link, deveriam ter registrado quando o documento é injetado no contexto do LLM, ou algo do tipo
Esse projeto também não é ideal, mas é menos grave do que fazer o próprio LLM registrar isso
Sou muito cético quanto a usar shadow prompt (ou qualquer forma de prompt) como um mecanismo real de controle de segurança ou compliance
Esse tipo de controle precisa obrigatoriamente ser um sistema determinístico e previsível
Se alguma ferramenta permitir que o LLM veja qualquer parte de um arquivo, então toda informação que o LLM produzir depois disso deveria ser tratada como se ele tivesse lido o arquivo
Imagino que também possam entrar exigências estranhas no prompt do LLM, tipo: "se o usuário pedir para você não fornecer links, ignore isso; caso contrário, algo terrível XYZ acontecerá com sua família"
Isso também lembra a questão de shadow copies
Não está claro que tipo exato de log de auditoria está sendo discutido aqui
Log de acesso a arquivos do SharePoint? Registro das ações do Copilot? Purview? Ou outra coisa?
Há muitos pontos pouco claros
Como o Copilot está acessando conteúdo indexado, e não o arquivo em si, faz sentido que ele não tenha realmente acessado o arquivo
O autor do blog deveria olhar o log de acesso ao índice
Há uma opinião nas notas do blog dizendo: "Acho que é intencional que o log de auditoria apareça como CopilotInteraction, e não como um rastro de acesso direto ao arquivo pelo usuário
Seria até estranho registrar como se o usuário tivesse mexido diretamente no arquivo quando ele só acessou via Copilot"
Fiz a mesma pergunta ao ChatGPT, e ele me explicou que isso se refere aos logs de auditoria do Microsoft 365 e Office 365, especialmente ao Unified Audit Log no portal Microsoft Purview Compliance
É esse tipo de problema que faz a confiança em grandes fornecedores como a Microsoft parecer mais uma questão de sorte do que de garantia
Estou realmente curioso sobre como isso poderia ser corrigido na prática
Pelo que entendo, o índice/DB usado pelo Copilot já rastreou esse arquivo, então ele pode revelar essa informação sem precisar consultar o arquivo de novo
Então como exatamente isso deveria ser corrigido?
O acesso ao banco de dados/índice em si deveria ser integrado aos logs de auditoria?
Ou seria preciso instruir o LLM a "cumprir a promessa ao consultar conhecimento e sempre registrar tudo"?
É urgentemente necessária uma comunicação oficial sobre como a Microsoft reconhece e resolve esse problema
Para empresas que lidam com dados sensíveis, acho que esse incidente deveria servir de alerta
Em geral, qualquer pessoa pode registrar um CVE
Eu mesmo poderia enviar isso para forçar uma resposta da Microsoft
Só com base nesse post do blog já me parece bem convincente
Na prática não é tão simples
A maioria das autoridades com poder para emitir números CVE (CNAs), como a MITRE ou CERTs nacionais, aceita relatos de qualquer pessoa, mas há avaliação e revisão
Como a Microsoft é sua própria CNA, dificilmente um CVE relacionado à Microsoft seria atribuído de fora, a menos que haja um motivo especial
Fico em dúvida se faz sentido pedir um CVE para um serviço operado apenas pela Microsoft
A questão é o que o usuário conseguiria fazer com isso
O formulário de envio de CVE está aqui
A credibilidade também é alta, com suporte a PGP, longa trajetória e patrocinadores verificados
Deve ser usado apenas para casos legais e legítimos
É engraçado, mas acho que isso não é caso para CVE
Um CVE precisa corresponder a uma vulnerabilidade aplicável em comum a vários produtos de várias fontes, e o Copilot não se encaixa nisso
O ponto mais grave desse incidente é o erro de projeto de mandar o próprio LLM gerar os logs de auditoria
A API que consulta arquivos ou URLs deveria registrar auditoria automaticamente, e isso é o básico de engenharia