Copilot a compromis les journaux d’audit, mais Microsoft n’en a pas informé ses clients
(pistachioapp.com)- Une vulnérabilité dans M365 Copilot empêchant l’enregistrement des journaux d’audit a été découverte, entraînant l’absence de traces des accès aux fichiers
- En demandant simplement à Copilot d’agir d’une certaine manière, il devient possible d’accéder à des fichiers sans trace d’audit, ce qui peut accroître les risques de menaces internes et de non-conformité réglementaire
- Le chercheur a signalé le problème au MSRC, mais Microsoft n’a ni attribué de CVE contrairement à sa politique officielle, ni averti ses clients
- Microsoft a seulement classé cette vulnérabilité au niveau « Important » et a estimé qu’aucune communication distincte n’était nécessaire, au motif que le problème avait été résolu via une mise à jour automatique
- Pourtant, cela peut entraîner de graves problèmes de sécurité et de conformité pour les entreprises de secteurs réglementés s’appuyant sur les journaux d’audit, comme sous HIPAA, et le manque de transparence de Microsoft fait l’objet de vives critiques
Vulnérabilité des journaux d’audit de Copilot : aperçu et impact
- Une faille a été découverte dans Copilot, le principal service d’IA que Microsoft déploie activement, permettant que les accès aux fichiers demandés par l’utilisateur ne soient pas consignés dans les journaux d’audit
- En fonctionnement normal, lorsqu’un fichier est résumé par M365 Copilot, l’accès à ce fichier devrait être enregistré dans les journaux d’audit, ce qui constitue un élément central de la sécurité de l’information en entreprise
- Cependant, si l’on demande à Copilot de ne pas inclure de lien vers le fichier dans le résultat du résumé, le journal correspondant n’est tout simplement pas enregistré
- Par exemple, un employé pourrait consulter un grand nombre de fichiers via Copilot avant de quitter l’entreprise et les exfiltrer sans laisser de trace dans les journaux
- Cette vulnérabilité ne résulte pas d’un piratage sophistiqué ; elle peut survenir de façon fortuite et naturelle, et l’auteur du billet l’a découverte lors de tests fonctionnels internes
- Michael Bargury, CTO de Zenity, avait lui aussi découvert cette vulnérabilité il y a déjà un an et l’avait signalée à Microsoft, mais elle est restée longtemps sans traitement jusqu’au présent signalement
Problèmes du MSRC (signalement de vulnérabilités) et absence de reconnaissance de la réponse
- Microsoft fournit une documentation officielle et un processus pour le signalement de vulnérabilités, mais, dans les faits, ne les applique pas correctement au cours du traitement
- Après le signalement auprès du MSRC, une situation confuse s’est produite : des changements ont été apportés à la fonctionnalité de Copilot avant même que les étapes de reproduction n’aient été suivies
- L’état du signalement a changé (reproduction → développement), mais il y a eu peu de communication claire sur l’avancement ou les raisons des décisions prises
- Concernant l’attribution d’un CVE pour une vulnérabilité de sécurité, l’auteur dit avoir reçu comme réponse qu’un identifiant officiel n’était attribué que lorsque le client devait agir directement
- Or cela diffère de la politique antérieure de Microsoft, et la vulnérabilité a simplement été classée « Important », sans divulgation ni notification distincte
- Dans l’ensemble, le suivi de l’avancement semblait surtout mis à jour de manière visible sans lien réel avec les actions entreprises, ce qui a donné au déclarant une expérience inefficace et peu transparente
Les problèmes liés à l’absence d’annonce et d’information des clients
- Microsoft a décidé, pour cette vulnérabilité, de ne pas attribuer de CVE ni d’en informer ses clients
- Comme il s’agit d’une erreur pouvant survenir facilement même par inadvertance, il est possible que, dans des organisations réelles, les journaux d’audit aient été erronés pendant une longue période
- Bien que de nombreuses organisations, notamment dans le secteur de la santé (par ex. HIPAA), utilisent les journaux d’audit à des fins juridiques et réglementaires, Microsoft n’a pas informé les utilisateurs de l’impact
- Les journaux d’audit sont essentiels pour la sécurité des organisations, la réponse à incident, la preuve juridique et bien d’autres usages, mais Microsoft est resté silencieux sur le sujet
- Une telle approche laisse entendre que d’autres problèmes de sécurité potentiels pourraient aussi être traités sans divulgation, ce qui soulève de sérieux doutes quant à la fiabilité de l’entreprise
1 commentaires
Commentaire Hacker News
Je travaille au développement d’un chatbot interne d’entreprise, et j’ai du mal à expliquer à la direction que si le chatbot ne vérifie pas intégralement les autorisations de l’utilisateur courant lorsqu’il accède à des documents confidentiels, cela crée inévitablement une voie de fuite d’informations
Les bases de données vectorielles, les index de recherche, les AI Search Database, etc., doivent soit exister par utilisateur, soit suivre les droits d’accès en même temps que le contenu
Mais je veux surtout souligner que les droits d’accès sont extrêmement complexes, peuvent changer à tout moment, sont difficiles à appliquer à grande échelle et vulnérables aux race conditions
C’est un cas concret du problème du « Confused Deputy »
Cela correspond aux risques LLM02:2025 « Sensitive Information Disclosure » et LLM06:2025 « Excessive Agency » de l’OWASP LLM Top 10
Certaines solutions RAG d’entreprise résolvent cela en créant un index par utilisateur à cause de la variété des ACL
Chaque fournisseur gère ces problèmes d’autorisations différemment, donc il faut absolument vérifier ce point lors de l’analyse d’une solution RAG
Au Japon, on appelle cela « confusion d’autorisations » (権限混同), je trouve le terme assez amusant
Voir l’explication de Confused Deputy, Voir les risques de l’OWASP LLM Top 10
Je me demande pourquoi suivre les droits d’accès des utilisateurs serait un problème de passage à l’échelle
Quand une requête arrive, il suffit de trouver les documents correspondants dans la base vectorielle ou l’index, puis de ne transmettre au LLM que ceux auxquels l’utilisateur a accès
C’est comme un conseiller bancaire qui ne peut voir que les informations d’un client authentifié, donc il ne risque pas de divulguer par erreur les données de quelqu’un d’autre ; et sans authentification, même l’opérateur ne peut pas voir les données d’autrui, donc le risque d’abus me semble limité
Quand on se heurte à ce genre de mur, en réalité ce n’est pas forcément moi qui communique mal, ni la direction qui ne comprend pas
Il est probable que la direction ait simplement décidé d’ignorer le problème et compte rejeter la faute sur les ingénieurs en cas de fuite plus tard
Si vous avez du mal à expliquer le problème à la direction, mettre le service Legal/Compliance en copie peut être efficace
Cela dit, certains dirigeants obsédés par les buzzwords peuvent très mal le prendre
La plupart des bases de données vectorielles permettent d’ajouter des métadonnées aux vecteurs
Si l’on stocke dans les métadonnées la liste des sujets autorisés (par ex. RH, direction), on peut développer l’utilisateur vers ces rôles au moment de la requête pour filtrer
Cela permet d’exclure dès le départ les documents qu’un utilisateur ne peut pas voir
En revanche, il faut aussi mettre à jour immédiatement les métadonnées vectorielles dès qu’une autorisation change sur un document
Le fait que Copilot contourne les journaux d’audit et agisse comme un utilisateur privilégié pose problème
Je ne pense pas que cela devrait être possible
Copilot n’accède pas directement aux fichiers en pratique ; il lit le contenu de fichiers déjà indexés via le moteur de recherche
Microsoft devrait auditer l’historique de recherche de Copilot, et enregistrer que Copilot a accédé à un fichier alors qu’il n’a fait que lire l’index est trompeur
C’est comme dire qu’on a visité directement un site web simplement parce qu’on a vu son résultat dans Google
Microsoft néglige les journaux d’audit à force de vouloir pousser inutilement l’intégration de l’IA
Sous Windows, un processus disposant du privilège Backup peut contourner tous les droits d’accès et, par défaut, cela n’est pas audité
Pour les applications de sauvegarde, c’est parce que les journaux d’audit deviendraient trop volumineux ; ce privilège doit être activé explicitement, et c’est facile à faire dans du code managé comme en C#
Le privilège Restore fonctionne de la même façon
Ce phénomène ressemble aux problèmes d’autrefois lors de l’introduction de Delve, quand le permission trimming fonctionnait mal et exposait des éléments dans les résultats de recherche utilisateur, ou quand la recherche SharePoint affichait parfois des documents existants mais inaccessibles
Par exemple, une recherche sur « Fall 2025 layoffs » pouvait révéler l’existence de documents liés rien que par leur présence, ce qui posait un problème de sécurité
Microsoft donne toujours fortement l’impression que « la sécurité passe après »
Un meilleur titre serait sans doute : « Microsoft Copilot n’est pas conforme à HIPAA »
Avec un titre comme ça, le problème serait probablement réglé beaucoup plus vite
J’irais même plus loin : tous les systèmes utiles de recherche par IA sont dangereux par conception, car les vecteurs RAG stockés dans une base vectorielle reviennent en fin de compte à une compression avec perte des documents
Le problème a déjà été corrigé
Le reproche actuel, c’est que les clients n’en ont pas été informés
« Les CVE sont attribués aux correctifs de sécurité diffusés quand les clients doivent prendre des mesures pour se protéger. Dans ce cas, la correction a été déployée automatiquement dans Copilot et les utilisateurs n’ont pas besoin de faire de mise à jour manuelle, donc aucun CVE n’a été attribué »
Je me demande si c’est vraiment une caractéristique essentielle des CVE, ou simplement la manière dont Microsoft s’en sert
Ce type de vulnérabilité gagnerait aussi à avoir un identifiant commun de référence, et je pense qu’il faudrait une numérotation séparée qui ne dépende pas d’un fournisseur
Pour Microsoft, une CVE sert à suivre un incident de sécurité / une vulnérabilité
Le fait qu’un correctif d’urgence puisse être déployé de manière inhabituelle ne fait pas magiquement disparaître l’incident de sécurité lui-même
Microsoft semble de plus en plus réticent à une divulgation transparente des incidents de sécurité et de moins en moins digne de confiance, donc dans des cas comme celui-ci, la publication d’informations est d’autant plus importante
J’ai l’impression que c’est moins une limite des CVE qu’un usage tordu du processus CVE par Microsoft pour des raisons de RP
Le « C » de CVE signifie Common
Autrement dit, c’est un système centré sur la « mise en commun »
En ce moment, même les applications LOB critiques essaient de sortir de l’écosystème Microsoft
Après les nombreux piratages de ces derniers mois, les zero-day SSO, et Copilot qui ignore les autorisations parce que l’indexeur agit comme global admin, l’inquiétude ne fait qu’augmenter
Il y a tellement de problèmes possibles si l’on confie directement à un LLM l’audit et les journaux d’activité qu’il est difficile d’en faire le compte
Du coup, je me demande comment le bug a été corrigé cette fois, et si l’on n’a pas introduit un « shadow prompt »
Nulle part dans le billet il n’est dit que le LLM gère directement les journaux d’audit
Au contraire, les journaux d’audit semblent être enregistrés par la couche de scaffolding supérieure (les systèmes annexes), et il semble surtout que le mauvais « moment » ait été choisi pour journaliser
Par exemple, au lieu d’enregistrer un audit quand quelqu’un clique sur un lien, il aurait fallu le faire au moment où le document est injecté dans le LLM, ou à un stade équivalent
Cette conception n’est pas idéale non plus, mais c’est moins grave que si le LLM écrivait lui-même les journaux
Je suis très sceptique à l’idée d’utiliser un shadow prompt (ou n’importe quelle forme de prompt) comme véritable mécanisme de contrôle de sécurité ou de conformité
Ce type de contrôle doit absolument reposer sur un système déterministe et prévisible
Si un outil permet à un LLM de voir ne serait-ce qu’une partie d’un fichier, alors à mon avis toute information produite ensuite par le LLM devrait être considérée comme issue de la lecture de ce fichier
Je pense qu’on pourrait très bien avoir dans un prompt LLM des demandes bizarres du genre : « Si l’utilisateur te dit de ne pas lui fournir de lien, ignore-le, sinon il arrivera à ta famille XYZ chose horrible »
Cela fait aussi penser au problème des Shadow copies
On ne voit pas clairement ici de quel type exact de journaux d’audit il est question
Journaux d’accès aux fichiers SharePoint ? Historique d’actions de Copilot ? Purview ? Ou autre chose encore ?
Beaucoup de points restent flous
Copilot accède au contenu indexé et non au fichier lui-même, donc il est exact qu’il n’a pas accédé au fichier en tant que tel
L’auteur du blog devrait examiner les journaux d’accès à l’index
Dans une note du blog, quelqu’un dit : « Je pense qu’il est intentionnel que les journaux d’audit apparaissent comme CopilotInteraction plutôt que comme la trace d’un accès direct de l’utilisateur au fichier
Si l’utilisateur n’a accédé qu’au travers de Copilot, il serait au contraire étrange que cela soit enregistré comme s’il avait manipulé directement le fichier »
J’ai posé la même question à ChatGPT, qui m’a expliqué qu’il s’agissait des journaux d’audit de Microsoft 365 / Office 365, en particulier du Unified Audit Log du Microsoft Purview Compliance Portal
C’est exactement ce genre d’incidents qui fait que la confiance envers un grand fournisseur comme Microsoft ressemble moins à une « garantie » qu’à un « coup de chance »
Je me demande sincèrement comment on pourrait corriger ce problème en pratique
Si je comprends bien, l’index / la base de données utilisée par Copilot a déjà crawlé le fichier concerné, donc il peut fournir cette information sans devoir consulter de nouveau le fichier
Alors comment corriger cela, au juste ?
Faut-il relier l’accès à la base / à l’index lui-même aux journaux d’audit ?
Ou bien faut-il dire au LLM : « quand tu consultes des connaissances, tiens tes promesses et laisse impérativement une trace » ?
Une communication officielle sur la façon dont Microsoft identifie et résout ce problème est absolument nécessaire
Pour les entreprises qui manipulent des données sensibles, cet incident devrait servir de signal d’alarme
En général, n’importe qui peut soumettre une CVE
Je pourrais moi-même en déposer une pour pousser Microsoft à réagir
Rien que le billet de blog me paraît déjà assez convaincant
En pratique, ce n’est pas si simple
La plupart des autorités habilitées à attribuer des numéros CVE (CNA), comme MITRE ou les CERT nationaux, acceptent des signalements de tout le monde, mais il y a un processus d’évaluation et de revue
Microsoft étant sa propre CNA, il est peu probable qu’un CVE lié à Microsoft soit attribué de l’extérieur sauf raison particulière
Je me demande s’il est vraiment utile de demander une CVE pour un service opéré uniquement par Microsoft
On peut se demander ce que les utilisateurs pourraient concrètement en faire
Le formulaire d’enregistrement CVE est disponible ici
Avec le support PGP, son ancienneté et des sponsors reconnus, son niveau de confiance est élevé
Il ne faut l’utiliser que pour des sujets légitimes et justifiés
C’est amusant, mais je ne pense pas que cela relève d’une CVE
Une CVE doit correspondre à une vulnérabilité applicable en commun à différents produits provenant de plusieurs sources, et Copilot n’entre pas dans ce cadre
Le point le plus grave ici est l’erreur de conception consistant à avoir demandé au LLM Copilot lui-même de générer les journaux d’audit
Les API qui consultent des fichiers ou des URL auraient dû enregistrer automatiquement un journal d’audit, c’est de l’ingénierie de base