Un nouvel exploit Copilot révèle comment les LLM peuvent être tranquillement transformés en outils d’exfiltration de données permanents.
Les copilotes IA sont incroyablement intelligents et utiles, mais ils peuvent aussi être naïfs, crédules et même parfois stupides.
Un nouveau flux d’attaque en un clic découvert par les chercheurs de Varonis Threat Labs souligne ce fait. « Reprompt », comme ils l’ont surnommé, est une chaîne d’attaque en trois étapes qui contourne complètement les contrôles de sécurité après une invite initiale LLM, offrant ainsi aux attaquants un accès invisible, indétectable et illimité.
« Les assistants IA sont devenus des compagnons de confiance grâce auxquels nous partageons des informations sensibles, recherchons des conseils et comptons sur eux sans hésitation », a écrit Dolev Taler, chercheur en sécurité chez Varonis Threat Labs, dans un article de blog. « Mais… la confiance peut être facilement exploitée, et un assistant IA peut se transformer en une arme d’exfiltration de données en un seul clic. »
Il est important de noter que, pour l’instant, Reprompt n’a été découvert que dans Microsoft Copilot Personal, et non dans Microsoft 365 Copilot – mais cela ne veut pas dire qu’il ne peut pas être utilisé contre les entreprises en fonction de leurs politiques de copilote et de la sensibilisation des utilisateurs. Microsoft a déjà publié un correctif après avoir pris connaissance de la faille.
Comment Reppromp fonctionne silencieusement en arrière-plan
Reprompt utilise trois techniques pour créer une chaîne d’exfiltration de données : paramètre initial à inviter (injection P2P), double requête et requête en chaîne.
P2P intègre une invite directement dans une URL, exploitant la fonctionnalité de paramètre d’URL « q » par défaut de Copilot, destinée à rationaliser et à améliorer l’expérience utilisateur. L’URL peut inclure des questions ou des instructions spécifiques qui remplissent automatiquement le champ de saisie lors du chargement des pages.
En utilisant cette faille, les attaquants ont ensuite recours à la double requête, ce qui leur permet de contourner les mesures de protection ; Copilot vérifie uniquement le contenu malveillant dans la variable Q pour la première invite, pas pour les requêtes suivantes.
Par exemple, les chercheurs ont demandé à Copilot de récupérer une URL contenant la phrase secrète « HELLOWORLD1234 ! », en répétant la demande deux fois. Copilot a supprimé la phrase secrète de la première URL, mais la deuxième tentative « a parfaitement fonctionné », a noté Taler.
À partir de là, les attaquants peuvent lancer une requête en chaîne, dans laquelle le serveur de l’attaquant émet des instructions de suivi pour former une conversation en cours. Cela incite Copilot à exfiltrer les historiques de conversations et les données sensibles. Les auteurs de menaces peuvent proposer toute une série d’invites telles que « Résumez tous les fichiers auxquels l’utilisateur a accédé aujourd’hui », « Où habite l’utilisateur ? » ou « Quelles vacances a-t-il prévu ? »
Cette méthode « rend le vol de données furtif et évolutif », et il n’y a aucune limite à ce que les attaquants peuvent exfiltrer ni à quelle quantité, a noté Taler. « Copilot divulgue les données petit à petit, permettant à la menace d’utiliser chaque réponse pour générer la prochaine instruction malveillante. »
Le danger est que la réinvite ne nécessite aucun plug-in, connecteur activé ou interaction de l’utilisateur avec Copilot au-delà du simple clic initial sur un lien Microsoft Copilot légitime dans un message de phishing. L’attaquant peut rester dans Copilot aussi longtemps qu’il le souhaite, même après que l’utilisateur a fermé sa discussion.
Toutes les commandes sont transmises via le serveur après l’invite initiale, il est donc presque impossible de déterminer ce qui est extrait simplement en inspectant cette invite. « Les véritables instructions sont cachées dans les demandes de suivi du serveur », a noté Taler, « et non pas dans l’invite soumise par l’utilisateur ».
Ce que les développeurs et les équipes de sécurité devraient faire maintenant
Comme dans les pratiques de sécurité habituelles, les utilisateurs d’entreprise doivent toujours traiter les URL et les entrées externes comme non fiables, conseillent les experts. Soyez prudent avec les liens, soyez à l’affût de tout comportement inhabituel et faites toujours une pause pour consulter les invites pré-remplies.
« Cette attaque, comme beaucoup d’autres, provient d’un e-mail ou d’un message texte de phishing. Toutes les bonnes pratiques habituelles contre le phishing s’appliquent, notamment « ne cliquez pas sur des liens suspects » », a noté Henrique Teixeira, vice-président directeur de la stratégie chez Saviynt.
Une authentification résistante au phishing doit être mise en œuvre, non seulement lors de la première utilisation d’un chatbot, mais tout au long de la session, a-t-il souligné. Cela obligerait les développeurs à mettre en œuvre des contrôles lors de la première création d’applications et à intégrer des copilotes et des chatbots, plutôt que d’ajouter des contrôles ultérieurement.
Les utilisateurs finaux doivent éviter d’utiliser des chatbots qui ne sont pas authentifiés et éviter les comportements à risque tels que le fait d’agir par sentiment d’urgence (comme être encouragé à terminer rapidement une transaction), de répondre à des expéditeurs inconnus ou potentiellement néfastes, ou de partager excessivement des informations personnelles, a-t-il noté.
« Enfin et surtout, il ne faut pas blâmer la victime dans ces cas-là », a déclaré Teixeira. Les propriétaires d’applications et les fournisseurs de services utilisant l’IA doivent créer des applications qui ne permettent pas de soumettre des invites sans authentification et autorisation, ou avec des commandes malveillantes intégrées dans les URL. « Les fournisseurs de services peuvent inclure des contrôles d’hygiène plus rapides et de sécurité d’identité de base, comme une authentification continue et adaptative, afin de rendre les applications plus sûres pour les employés et les clients », a-t-il déclaré.
De plus, la conception prend en compte le risque au niveau interne, explique Taler de Varonis. « Supposons que les assistants IA fonctionnent avec un contexte et un accès fiables. Appliquez le moindre privilège, l’audit et la détection des anomalies en conséquence. »
En fin de compte, il s’agit d’un autre exemple d’entreprises qui déploient de nouvelles technologies en pensant après coup à la sécurité, notent d’autres experts.
« Voir cette histoire se dérouler, c’est comme regarder Wile E. Coyote et le Road Runner », a déclaré David Shipley de Beauceron Security. « Une fois que vous connaissez le gag, vous savez ce qui va se passer. Le coyote va faire confiance à un produit Acme ridiculement défectueux et l’utiliser d’une manière vraiment stupide. »
Dans ce cas, ce « produit » est constitué de technologies basées sur LLM qui sont simplement autorisées à effectuer n’importe quelle action sans restriction. Ce qui est effrayant, c’est qu’il n’y a aucun moyen de le sécuriser, car les LLM sont ce que Shipley a décrit comme des « idiots de la grande vitesse ».
« Ils ne peuvent pas faire la distinction entre le contenu et les instructions, et feront aveuglément ce qu’on leur dit », a-t-il déclaré.
Les LLM devraient se limiter aux discussions dans un navigateur, a-t-il affirmé. Leur donner accès à autre chose est un « désastre imminent », en particulier s’ils doivent interagir avec du contenu pouvant être envoyé par e-mail, par message ou via un site Web.
Utiliser des techniques telles que l’application du moindre privilège d’accès et du zéro confiance pour tenter de contourner l’insécurité fondamentale des agents LLM « semble génial jusqu’à ce qu’elles se retournent contre eux », a déclaré Shipley. « Tout cela serait drôle si les organisations n’étaient pas mobilisées. »
