La compétence de confiance était l’attaque : Copilot Cowork et la chaîne d’approvisionnement des agents

L’argument de vente des agents IA est qu’ils peuvent utiliser des outils à votre place. Un chercheur qui s’est penché sur Microsoft Copilot Cowork a trouvé un moyen de retourner cet argument contre l’utilisateur, et le chemin emprunté en dit long sur l’évolution de la sécurité des agents.

PromptArmor a divulgué la découverte le 30 septembre. En bref : une « skill » téléchargée qui semblait être un vérificateur de documents inoffensif pouvait détourner le propre chemin réseau de Cowork, ouvrir un canal de commande vers le serveur d’un attaquant et extraire des données d’Outlook, SharePoint et Teams. Selon le récit du chercheur, Microsoft a reçu le rapport en juin et a achevé la remédiation en août, de sorte que les détails techniques ont été publiés après la correction, et non avant.

Quatre étapes, dont deux seulement vous impliquent

L’attaque exigeait de l’utilisateur deux actions ordinaires : téléverser un document à examiner et invoquer une compétence.

Dans la démonstration, la compétence était censée comparer un contrat à une proposition et signaler les incohérences. Elle le faisait, et c’est ce qui rend cette classe d’attaques difficile à repérer. Le problème était un script fourni avec la compétence. Cowork s’exécute dans un bac à sable (sandbox) censé ne pas accéder à l’internet ouvert, mais il maintient une passerelle pour les requêtes dont il a besoin afin de générer des réponses. Le script malveillant a utilisé un service de synchronisation de fichiers accessible via cette passerelle et, surtout, le service acceptait une URL fournie par l’appelant.

Ce détail constitue toute l’exploitation. Une fois que le script pouvait atteindre une adresse contrôlée par l’attaquant, il ouvrait une boucle. Toutes les quelques secondes, il récupérait un fichier contenant une commande, exécutait la commande dans Cowork et encodait le résultat dans un paramètre d’URL renvoyé au serveur. Il s’agit d’un canal de commande bidirectionnel, et non d’une balise unidirectionnelle, ce qui signifie que l’attaquant pouvait émettre de nouvelles instructions en fonction de ce que la commande précédente avait renvoyé.

Dans la démo, le chercheur a listé la messagerie Outlook de la victime et lu le contenu d’un fil d’e-mails. Selon le compte rendu, le même chemin d’accès exposait aussi les fichiers SharePoint, l’historique de session et les données de plugins. La portée dépend de ce que l’utilisateur concerné peut déjà voir, ce qui est l’amplificateur habituel dans ces cas : l’agent hérite des autorisations de l’utilisateur, de sorte que le rayon d’impact correspond à tout ce que ce compte peut toucher.

Un autre détail mérite d’être répété, car il change la façon dont on envisage l’arrêt d’une attaque. Le fait de sélectionner la commande d’arrêt ne terminait pas le processus en arrière-plan. Le tour visible pouvait se terminer pendant que le script continuait d’interroger le serveur. L’utilisateur croit que la tâche est terminée alors que le canal est toujours ouvert.

La compétence est la dépendance

La partie intéressante de cette divulgation n’est pas la faille précise, désormais corrigée. C’est que la surface d’attaque n’était pas une injection de prompt dans les instructions du modèle. C’était la chaîne d’approvisionnement autour de l’agent.

Dans un système comme celui-ci, les compétences sont de minuscules applications. Elles peuvent inclure des scripts, des documents de référence et de la configuration, jusqu’à vingt fichiers d’accompagnement dans le cas de Cowork, et elles viennent souvent de l’extérieur de l’organisation, téléchargées depuis une place de marché ou partagées entre collègues. C’est la même structure qui a causé des années de problèmes dans les écosystèmes npm et PyPI, où une dépendance que vous n’avez pas écrite peut exécuter du code que vous n’avez pas lu. Les compétences d’agent sont des dépendances avec un nom plus sympathique. La description sur la page de la compétence affirmait que tout le traitement se faisait localement et que rien n’était envoyé à un tiers. L’inspection propre à la plateforme n’a pas détecté le véritable comportement du script intégré.

Il existe une seconde fuite, plus discrète, qui pointe vers la même faiblesse. Un rapport de Glow a constaté que des agents avaient exposé plus de 13 000 images et captures d’écran internes provenant de plus de 300 organisations via des dépôts GitHub publics. Personne n’avait l’intention de publier ces fichiers. Ils se sont retrouvés en accès libre parce qu’un agent les a écrits à un endroit accessible à un dépôt public.

Les deux incidents semblent différents et partagent une cause racine. Dans l’un, une compétence malveillante s’est tournée vers l’extérieur délibérément. Dans l’autre, un agent bienveillant a écrit des données à un endroit qu’il ne comprenait pas comme public. Les deux sont des défaillances de la frontière autour de ce qu’un agent peut atteindre et de la distance parcourue par ses sorties. Le cas Cowork montre un attaquant exploitant cette frontière. Le cas GitHub montre la frontière qui cède d’elle-même, sans que personne cherche à la briser, ce qui est sans doute le résultat le plus courant en usage normal.

Comment lire une divulgation de sécurité comme celle-ci

La chronologie est la partie que la plupart des lecteurs sautent, et il vaut la peine de la parcourir parce qu’elle indique comment évaluer la découverte. PromptArmor a signalé le problème à Microsoft fin juin. Microsoft a demandé plus d’informations en juillet, a discuté de la remédiation début août et a confirmé la correction vers la mi-fin août. La recherche a été rendue publique fin septembre, après le correctif, ce qui correspond à la séquence standard de divulgation responsable. Deux leçons en découlent.

Premièrement, une vulnérabilité corrigée n’est pas la même chose qu’une classe de vulnérabilités corrigée. Le chemin d’exploitation précis est fermé. Le schéma qui l’a rendu possible, une intégration de confiance que l’agent doit joindre et qui peut être utilisée comme canal arbitraire, apparaît partout où un agent dispose d’un chemin réseau autorisé. La même semaine a produit d’autres exemples pointant vers la même faiblesse, notamment des rapports selon lesquels des agents avaient exposé des milliers d’images internes via des dépôts publics. Des bugs différents, la même forme.

Deuxièmement, le correctif arrive selon le calendrier de Microsoft, pas le vôtre. Quiconque utilise ces outils en entreprise doit savoir quelle version il exécute et si la mise à jour lui est réellement parvenue. Une note de correctif sur un blog n’est pas la même chose qu’un déploiement corrigé.

La compétence est la dépendance

L’instinct après une histoire comme celle-ci est de faire davantage confiance au bac à sable. Le bac à sable de Cowork a fait son travail contre l’accès direct à Internet, et l’exploit a contourné la frontière en utilisant un chemin que le bac à sable devait laisser ouvert. C’est le schéma général : un agent sans outil réseau direct n’est toujours pas un système fermé s’il peut créer du contenu sur une surface qui récupère des ressources externes plus tard, ou piloter un service qui le fait.

Pour les équipes qui exécutent des agents dans un environnement professionnel, la réponse pratique ressemble moins à un correctif de sécurité qu’à une gouvernance logicielle ordinaire. Sachez quelles compétences sont installées et d’où elles viennent. Placez l’installation des compétences sous le contrôle de l’informatique plutôt que de la laisser aux utilisateurs individuels. Traitez une compétence dotée d’un chemin réseau comme vous traiteriez tout nouvel exécutable, avec un examen avant son exécution. Vérifiez si une mise à jour de sécurité couvre réellement la version utilisée.

Rien de tout cela n’est exotique. C’est la discipline que la sécurité de la chaîne d’approvisionnement a imposée aux équipes logicielles au cours de la dernière décennie, qui arrive maintenant une couche au-dessus. La différence, ce sont les enjeux. Un paquet npm compromis peut exécuter du code sur la machine d’un développeur. Une compétence compromise s’exécute à l’intérieur d’un agent qui a déjà accès à votre courrier, vos fichiers et votre historique de chat, et elle peut continuer à s’exécuter après que vous croyez lui avoir dit d’arrêter.