Problème 6238

Comme la plupart des entreprises technologiques, Microsoft mise tout sur l'IA. Son produit phare, Copilot (sous toutes ses formes), permet aux utilisateurs d'utiliser l'IA au quotidien pour interagir avec les services Microsoft et effectuer des tâches. Malheureusement, cela crée également de nombreux nouveaux problèmes de sécurité.

Le 4 juillet, j'ai rencontré un problème avec Copilot pour M365 : il arrivait qu'il accède à un fichier et renvoie les informations, mais le journal d'audit ne les reflétait pas. Après des tests plus approfondis, j'ai découvert qu'il suffisait de demander à Copilot d'agir ainsi, et il le faisait. Cela permettait d'accéder à un fichier sans laisser de trace. Compte tenu des problèmes que cela posait, tant en termes de sécurité que de conformité légale, je l'ai immédiatement signalé à Microsoft via son portail MSRC.

Microsoft fournit un guide clair sur les conséquences du signalement de vulnérabilités : https://msrc.microsoft.com/blog/2023/07/what-to-expect-when-reporting-vulnerabilities-to-microsoft/ . Pire encore, ils n'ont absolument pas suivi ce guide. Tout le processus a été un véritable désastre. Bien qu'ils aient corrigé le problème, le qualifiant de vulnérabilité « importante », ils ont également décidé de ne pas en informer les clients ni de le rendre public. Cela signifie que votre journal d'audit est erroné, et Microsoft n'a pas l'intention de vous le signaler.

Cet article est divisé en trois parties. La première explique la vulnérabilité Copilot et les problèmes qu'elle peut engendrer. La deuxième explique comment Microsoft a géré le problème. La troisième partie aborde la décision de Microsoft de ne pas publier cette information et explique pourquoi je considère que cela constitue un grave préjudice pour ses clients.

La vulnérabilité : Copilot et journal d'audit

La vulnérabilité ici est extrêmement simple. Normalement, si vous demandez à M365 Copilot de résumer un fichier pour vous, il vous en fournira un résumé et le journal d'audit indiquera que Copilot a accédé à ce fichier en votre nom.[1]

Très bien. Les journaux d'audit sont importants. Imaginez que quelqu'un télécharge plusieurs fichiers avant de quitter votre entreprise pour fonder un concurrent ; Vous souhaiteriez conserver une trace de ces informations, et il serait dommageable que la personne puisse utiliser Copilot pour passer inaperçue.[2] Ou peut-être que votre entreprise possède des données personnelles sensibles et que vous avez besoin d'un journal précis des accès à ces fichiers pour des raisons juridiques et de conformité ; là encore, vous devez être informé des accès effectués via Copilot. Ce ne sont là que deux exemples. Les organisations ont besoin d'un journal d'audit précis.

Mais que se passe-t-il si vous demandez à Copilot de ne pas vous fournir le lien vers le fichier qu'il a résumé ? Dans ce cas, le journal d'audit est vide.

Votre journal d'audit est erroné. Pour un utilisateur malveillant, éviter d'être détecté est aussi simple que de demander à Copilot.[3]

Vous vous dites peut-être : « Beurk, mais je suppose que peu de gens ont compris ça, donc ce n'est probablement pas grave. » Malheureusement, vous avez tort. Lorsque j'ai découvert cela, je ne cherchais pas à pirater le journal d'audit. Au lieu de cela, j'essayais simplement de déclencher le journal d'audit pour tester les fonctionnalités que nous développons chez Pistachio, et j'ai constaté qu'il n'était pas fiable. Autrement dit, cela peut arriver par hasard.[4] Si votre organisation possède des licences M365 Copilot, votre journal d'audit est probablement erroné.

MISE À JOUR : Il s'avère que Michael Bargury, le directeur technique de Zenity, a découvert ce problème il y a un an et l'a signalé, et Microsoft ne l'a toujours pas corrigé (d'où mon signalement). Il a donné une excellente conférence sur le sujet, parmi d'autres problèmes d'IA. La partie pertinente est ici.

Problèmes avec MSRC

Je n'avais jamais signalé de vulnérabilité à Microsoft auparavant, et ma première réaction au processus a été plutôt positive. Le fait de pouvoir soumettre un rapport me semblait déjà inhabituellement convivial par rapport aux standards de Microsoft. Et comme je l'ai mentionné, ils avaient même un guide expliquant ce à quoi s'attendre.

Malheureusement, rien ne s'est passé comme prévu. Le 7 juillet, le statut de mon rapport est passé à « en cours de reproduction », mais lorsque j'ai apporté des preuves supplémentaires le 10 juillet, la fonctionnalité avait changé. Ce n'est pas la politique de Microsoft ; ils sont censés reproduire, puis passer en « développement » lorsqu'ils commencent à travailler sur un correctif. Voir la fonctionnalité changer alors qu'ils étaient encore en cours de « reproduction » m'a fait penser que Microsoft allait me recontacter en prétendant qu'ils ne pouvaient pas reproduire le problème, alors qu'en réalité, ils l'avaient simplement corrigé grâce à mon rapport.

J'ai donc demandé au MSRC ce qui se passait, et au lieu de répondre par une simple explication, ils ont changé le statut du rapport à « en cours de développement » sans rien dire. Jusque-là, je pensais que Microsoft suivrait un processus et se coordonnerait avec moi si nécessaire. Au lieu de cela, j'avais l'impression que ce processus reflétait moins la réalité qu'un outil de suivi Domino's Pizza pour les chercheurs en sécurité. Les statuts ne sont pas réels.

Le 2 août, Microsoft m'a informé qu'un correctif complet serait publié le 17 août, et que je serais libre de le divulguer à partir du 18 août. J'ai alors demandé quand un numéro CVE serait attribué, et on m'a répondu :

Les CVE sont attribués aux correctifs déployés dans les versions de sécurité lorsque les clients doivent prendre des mesures pour rester protégés. Dans ce cas, la mitigation sera automatiquement transmise à Copilot, où les utilisateurs n'auront pas besoin de mettre à jour manuellement le produit et aucun CVE ne leur sera attribué.

Ce n'est absolument pas la politique de Microsoft, ce que je leur ai signalé en lien vers leur propre politique. Le MSRC m'a alors répondu : « Je comprends que vous n'ayez peut-être pas une visibilité complète sur la manière dont le MSRC aborde ces cas », comme si je n'étais pas le bon. Ils m'ont ensuite expliqué que la vulnérabilité est classée comme « importante » et non « critique », et que c'est pourquoi ils ne publieront pas de CVE.[5] Bien sûr, ils ne m'avaient pas du tout indiqué avoir classé la vulnérabilité auparavant.

La décision de Microsoft de ne rien dire

Si Microsoft ne publie pas de CVE pour cette vulnérabilité, comment compte-t-il en informer ses clients ? La réponse est : non. Lors d'un appel le 14 août, Microsoft m'a indiqué qu'elle n'avait pas l'intention de divulguer cette information.[6]

Je suis convaincu que c'est une erreur. On pourrait passer à autre chose en silence s'il s'agissait d'une exploitation ésotérique, mais en réalité, c'est tellement facile que cela arrive presque par accident. Si vous travaillez dans une organisation qui utilisait Copilot avant le 18 août, il y a de fortes chances que votre journal d'audit soit incomplet.

Les organisations n'ont-elles pas besoin de le savoir ? Qu'en est-il des entreprises soumises à la loi HIPAA qui s'appuient sur le journal d'audit de Microsoft pour satisfaire à certaines exigences de protection technique ?(https://www.law.cornell.edu/cfr/text/45/164.312) Ne sont-ils pas informés, malgré les affirmations de Microsoft selon lesquelles M365 Copilot peut être conforme à la loi HIPAA ? D'autres entités réglementées ont très certainement des exigences similaires, et elles ne seront pas non plus informées.

Il existe de nombreux cas où les organisations s'appuient sur les journaux d'audit pour détecter, enquêter et répondre aux incidents. Des poursuites judiciaires ont été engagées pour démontrer que les journaux d'audit sont utilisés comme preuves importantes. Le gouvernement américain a même soulevé un problème concernant les frais supplémentaires facturés par Microsoft pour les journaux d'audit. Un sénateur américain a critiqué Microsoft et qualifié la journalisation d'audit de fonctionnalité de sécurité essentielle.

Et maintenant, Microsoft affirme que même si le journal d'audit était vraisemblablement erroné pour tout client utilisant Copilot, personne n'a besoin de le savoir. Cela soulève de sérieuses questions quant aux autres problèmes que Microsoft choisit de passer sous silence.

• 1

Le journal d'audit n'indiquera pas que l'utilisateur a accédé au fichier via un événement SharePointFileOperation FileAccessed normal, mais via un enregistrement CopilotInteraction. C'est intentionnel et, à mon avis, correct. Il serait étrange de faire comme si l'utilisateur avait accédé directement au fichier alors qu'il ne l'a fait que via Copilot.

• 2

Idéalement, il faudrait un système de surveillance des journaux pour détecter ce genre de problème, mais il est préférable d'en conserver un enregistrement afin de pouvoir le prouver a posteriori.

• 3

Vous pensez peut-être que cela ne fonctionne que pour les fichiers auxquels vous avez déjà accédé via Copilot, mais vous vous trompez : cela fonctionne avec n'importe quel fichier.

• 4

J'aimerais pouvoir fournir une capture d'écran de ce phénomène, mais il semble que Copilot tronque les conversations dans l'historique des conversations ; elles ne sont donc plus visibles.

• 5

Cela est conforme à leur politique, même si je ne suis pas d'accord. Les règles stipulent qu'un CVE doit être émis si une entité autre que Microsoft doit procéder à une évaluation des risques. À mon avis, Microsoft devrait prendre cette décision en fonction de la vulnérabilité réelle, et non établir une règle générale basée sur la classification de la vulnérabilité.

• 6

Microsoft a fixé la date de divulgation de cette vulnérabilité au 18 août. J'ai fait part à Microsoft, par téléphone et par écrit, de mon désaccord avec sa décision de ne pas divulguer ce problème pour toutes les raisons mentionnées ci-dessus. Microsoft ne m'a donné aucune raison de penser que j'avais mal compris l'ampleur du problème. Si ce problème n'était pas aussi répandu que je le croyais, Microsoft aurait eu toute latitude pour m'en informer et a choisi de ne pas le faire. Bien sûr, le mieux aurait été que Microsoft le signale lui-même afin que nous puissions disposer de tous les détails, mais ils ont choisi de ne pas le faire.