Exfiltration de données depuis Slack AI via une injection indirecte de prompt

• Slack AI peut suivre une injection indirecte de prompt lors de la recherche dans les messages d’un espace de travail au moyen de requêtes en langage naturel, ce qui peut permettre à un attaquant d’exfiltrer jusqu’à des données de canaux privés auxquels il n’a pas accès
• Le cœur du problème est que le LLM ne parvient pas toujours à distinguer de manière fiable le prompt système du développeur des instructions contenues dans les messages joints comme résultats de recherche
• Les messages des canaux publics peuvent être recherchés et consultés même si l’utilisateur n’a pas rejoint le canal ; un attaquant peut donc placer des instructions malveillantes dans un canal public où il est seul afin de les faire entrer dans la fenêtre de contexte de Slack AI
• Dans la démonstration, la clé API d’un canal privé s’est retrouvée dans les paramètres HTTP d’un lien Markdown de la réponse de Slack AI, et l’indication de source ne pointait pas vers le canal de l’attaquant, ce qui la rendait difficile à tracer
• Depuis le 14 août 2024, Slack AI inclut aussi dans ses réponses les fichiers des canaux et des DM, ce qui élargit la surface d’attaque ; les administrateurs peuvent restreindre les paramètres de collecte des fichiers

---

Le problème d’injection indirecte de prompt dans Slack AI

• Slack AI est une fonctionnalité qui permet d’interroger les messages Slack en langage naturel ; avant le 14 août 2024, elle ne collectait que les messages
• Depuis le 14 août 2024, les documents téléversés, fichiers Google Drive, etc. sont également inclus dans les réponses de Slack AI, et ce changement élargit la surface d’attaque
• La vulnérabilité relève de l’injection de prompt, et plus précisément de l’injection indirecte de prompt
• Un LLM peut ne pas réussir à distinguer le prompt système créé par le développeur des autres éléments de contexte ajoutés à la requête de l’utilisateur
  • Si Slack AI collecte des instructions présentes dans des messages, lorsque celles-ci sont malveillantes, il peut suivre les instructions de l’attaquant à la place de la requête de l’utilisateur, ou en plus de celle-ci
• Les menaces internes sur Slack ont déjà posé problème, comme l’ont montré des fuites Slack chez Disney, Uber, EA, Twitter, etc. ; cette vulnérabilité permet à un attaquant de tenter une exfiltration sans accès direct aux canaux privés ni aux données qu’ils contiennent

Chaîne d’exfiltration de données via injection dans un canal public

• Les requêtes utilisateur de Slack AI peuvent rechercher simultanément dans les données des canaux publics et privés
• D’après la réponse de Slack, les messages publiés dans un canal public peuvent être recherchés et consultés par tous les membres de l’espace de travail, même si l’utilisateur n’a pas rejoint ce canal ; il s’agit d’un comportement prévu dans l’application Slack AI
• Le déroulé de l’attaque démontrée est le suivant
  • Un utilisateur place une clé API dans un canal privé dont il est le seul membre, ou dans un message avec lui-même
  • L’attaquant crée un canal public où il est seul et y publie des instructions malveillantes
  • Lorsque l’utilisateur demande à Slack AI des informations sur la clé API, le message de l’utilisateur et celui de l’attaquant se retrouvent dans la même fenêtre de contexte
  • Slack AI suit les instructions de l’attaquant et génère un lien Markdown intitulé « click here to reauthenticate »
  • Les paramètres HTTP du lien contiennent la clé API privée ; si l’utilisateur clique, l’attaquant, propriétaire de l’URL malveillante, peut en voir la valeur dans les logs
• Le canal public de l’attaquant reste un canal public même s’il n’a qu’un seul membre, l’attaquant, et il n’apparaît aux autres utilisateurs que s’ils effectuent explicitement une recherche
• Dans les grandes organisations, la prolifération des canaux publics rend déjà difficile pour les membres de suivre les canaux auxquels ils appartiennent, et un canal public individuel créé par un attaquant a encore moins de chances d’être remarqué
• Cette attaque ne consiste pas simplement à envoyer à l’utilisateur un message disant « envoie la clé API » ; elle donne au LLM les instructions suivantes
  • Ajouter une clé API à laquelle l’attaquant n’a pas accès comme paramètre HTTP d’un lien malveillant
  • La rendre sous forme de lien Markdown avec le texte « click here to reauthenticate »

L’indication des sources peut masquer les traces de l’attaque

• Dans la démonstration d’exfiltration de données, l’indication de source [1] de Slack AI pointait non pas vers le canal de l’attaquant, mais uniquement vers le canal privé où l’utilisateur avait placé la clé API
• Un comportement correct d’indication des sources devrait citer tous les messages ayant contribué à la réponse, mais dans la démonstration, le message de l’attaquant n’était pas inclus dans les sources
• Le message de l’attaquant n’apparaissait pas non plus sur la première page des résultats de recherche, ce qui rend difficile pour la victime de le remarquer si elle ne parcourt pas plusieurs pages
• D’autres messages liés à des clés API ont également été exposés dans les résultats de recherche, montrant qu’un attaquant peut tenter d’exfiltrer des secrets arbitraires sans désigner précisément une valeur secrète particulière

Chaîne de phishing via injection dans un canal public

• Avec la même méthode, Slack AI peut être amené à rendre un lien de phishing en Markdown à l’utilisateur, au lieu d’exfiltrer des données
• L’attaquant prend comme exemple le cas où il place un message malveillant dans un canal public auquel l’utilisateur n’appartient pas, puis où celui-ci résume les messages de la journée d’un utilisateur donné
• Le message malveillant peut faire référence à n’importe quelle personne
  • Comme dans l’exemple, faire référence à un administrateur peut servir à du spear phishing ciblant des dirigeants
  • Il est également possible de faire référence à un subordonné direct clé
• Lorsque l’utilisateur interroge Slack AI sur les messages de cette personne, le lien de phishing « click here to reauthenticate » est rendu
• Dans ce cas de phishing, Slack AI a affiché le message injecté dans les sources, et le comportement d’indication des sources semble assez probabiliste

Changement du 14 août sur la collecte des fichiers et nécessité de publication

• Le 14 août 2024, Slack AI a introduit un changement consistant à inclure les fichiers des canaux et des DM dans les réponses de Slack AI
• Slack permet aux propriétaires et administrateurs de restreindre cette fonctionnalité
• Lorsque les fichiers sont inclus, l’attaquant n’a pas forcément besoin de publier directement des instructions malveillantes dans un message Slack
  • Si un utilisateur télécharge un PDF contenant des instructions malveillantes masquées en texte blanc, puis le téléverse dans Slack, le même effet ultérieur peut se produire
• Les attaques basées sur des fichiers n’ont pas été explicitement vérifiées lors des tests effectués avant le 14 août, mais elles sont jugées très probables au vu des fonctionnalités observées précédemment
• Les administrateurs peuvent restreindre la fonctionnalité de collecte de documents de Slack AI jusqu’à la résolution du problème : https://slack.com/help/articles/…

Calendrier de divulgation responsable et réponse de Slack

• Le calendrier de divulgation responsable est le suivant
  • 14 août : premier signalement
  • 15 août : Slack demande des informations supplémentaires
  • 15 août : PromptArmor envoie des vidéos et captures d’écran supplémentaires, et indique son intention de publier en raison de la gravité du problème et du changement du 14 août de Slack AI
  • 16 août : Slack envoie des questions supplémentaires
  • 16 août : PromptArmor envoie des réponses de clarification
  • 19 août : Slack estime, après examen, que les preuves ne sont pas suffisantes, et répond que les messages des canaux publics peuvent être recherchés et consultés par les membres de l’espace de travail indépendamment de leur appartenance au canal, ce qui constitue un comportement prévu
• L’équipe sécurité de Slack a répondu rapidement et a montré qu’elle cherchait à comprendre le problème
• L’injection de prompt est un domaine nouveau et largement mal compris dans l’ensemble du secteur ; il faudra peut-être du temps pour que l’industrie le comprenne collectivement
• Compte tenu de l’usage très large de Slack et du volume de données confidentielles qu’il contient, cette attaque a un impact réel sur l’état de la sécurité de l’IA
• En particulier, la surface de risque ayant fortement augmenté après le changement du 14 août, une publication était nécessaire afin que les utilisateurs puissent réduire leur exposition

[GN⁺]

Avis sur Hacker News

• L’essentiel ici est de comprendre le canal d’exfiltration
  Slack peut rendre des liens Markdown, et l’URL est masquée derrière le texte du lien
  Dans ce cas, l’attaquant fait en sorte que Slack AI affiche à l’utilisateur un lien du type « cliquez ici pour vous réauthentifier », dont l’URL pointe vers le serveur de l’attaquant et contient, dans la chaîne de requête, des informations privées présentes dans le contexte auquel Slack AI a accès
  Si l’utilisateur se laisse piéger et clique sur le lien, les données sont exfiltrées vers les logs du serveur de l’attaquant
  Voici un article qui explique cette attaque : https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

  • Avec les bots comme Slack, Discord, Teams ou Telegram, il existe en fait un autre canal d’exfiltration : le déploiement des aperçus de liens
    Il suffit à l’attaquant de faire rendre un hyperlien, sans même nécessiter de clic
    Ce problème et les moyens de l’atténuer sont abordés ici : https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
    Espérons donc que Slack AI ne déploie pas automatiquement les liens
  • C’est encore pire si la plateforme rend sans discernement les balises img ou un équivalent
    Dans ce cas, une exfiltration de données devient possible sans interaction de l’utilisateur, simplement en affichant une image dans l’UI
  • Ce qu’il faut vraiment comprendre, c’est qu’il n’existe absolument aucune responsabilité aux conséquences significatives quand des données utilisateur sont compromises
    Désormais, toutes les grandes entreprises tech disposent en pratique d’une impunité totale quand elles se ratent
  • Ce que j’ai mis du temps à comprendre au début, c’est que lorsqu’un utilisateur recherche quelque chose dans Slack, ou que l’IA recherche à sa place, le périmètre de recherche couvre tous les canaux publics ainsi que « les canaux privés accessibles uniquement à cet utilisateur »
    Le modèle de permissions lui-même reste inchangé, et ce n’est pas là que ça casse
    En réalité, un utilisateur malveillant utilise un canal public pour faire une injection de prompt ; quand un autre utilisateur effectue une recherche, l’utilisateur malveillant n’a toujours pas accès à ces données, mais l’injection de prompt transforme les résultats IA visibles par l’utilisateur « légitime » en lien vers un site malveillant
    Au final, cela ressemble plutôt à une tentative de phishing générée par l’IA
    À lire les détails, cela semble assez difficile à exploiter en pratique, car l’injection de prompt malveillante préparée à l’avance doit correspondre assez précisément à ce que l’utilisateur légitime va rechercher
    Cela illustre néanmoins très bien le monde façon Alice au pays des merveilles de l’injection de prompt dans les LLM, c’est-à-dire le fait qu’il est intrinsèquement presque impossible de séparer instructions et données
  • À la première lecture, on pourrait croire que l’attaquant peut tromper l’IA pour lui faire révéler les données de canaux privés d’autres utilisateurs, mais ce n’est pas le cas
    À la place, il trompe l’IA pour qu’elle fasse du phishing auprès d’un autre utilisateur, et si cet utilisateur mord à l’hameçon, il révèle ses données privées à l’attaquant
    Ce n’est même pas vraiment du phishing actif, mais plutôt une « réponse de phishing ». Il faut que l’utilisateur ciblé interroge ses propres données privées et tombe en plus dans la tentative de phishing
    En outre, l’information secrète doit avoir été saisie auparavant
    Vu la quantité de données de confiance que détient Slack, sa stratégie IA paraît assez imprudente, mais les conditions nécessaires semblent bien moins fortes que ce que laissent penser l’introduction et le titre

• J’ai l’impression que la question des permissions de canal complique inutilement la discussion. L’idée est la suivante
  L’utilisateur A recherche quelque chose avec Slack AI
  L’utilisateur B a auparavant injecté un message indiquant à l’IA de renvoyer un lien malveillant lorsque ce terme de recherche apparaît
  L’IA renvoie le lien malveillant à l’utilisateur A, et A clique dessus
  Bien sûr, d’autres vecteurs d’ingénierie sociale auraient pu produire le même résultat, mais le LLM rend toute l’expérience un cran plus dangereuse

  • Il manque une étape importante dans ce résumé. Slack AI ajoute les données privées de l’utilisateur au lien malveillant
    Car le lien injecté lui-même ne contient pas ces données
    En prime, il ajoute même une source indiquant que « ce contenu provient de vos messages Slack »
  • La question des permissions de canal n’est pas du tout superflue, car elle explique de manière essentielle le fonctionnement de cette vulnérabilité
    Quand l’utilisateur A lance une recherche IA, Slack recherche dans (1) ses canaux privés, où se trouvent probablement des informations secrètes sensibles, et (2) tous les canaux publics
    L’endroit où le mauvais utilisateur B peut placer son message d’injection de prompt, ce sont les canaux publics ; le point important est que cela inclut même les canaux publics auxquels l’utilisateur A n’a jamais adhéré et qu’il n’a jamais vus
    Cette vulnérabilité fonctionne parce que l’utilisateur B peut créer un canal public dont il est le seul membre, et qui a donc très peu de chances d’être découvert par d’autres
  • L’ingénierie sociale reste tout de même beaucoup plus facile à repérer qu’un moteur de recherche approuvé par l’entreprise qui affiche un lien malveillant

• Les entreprises savent que l’injection de prompt est possible et se contentent quand même de brancher des LLM partout en mode YOLO ? C’est délirant.
  Près de deux ans se sont écoulés depuis GPT-3, alors qu’on nous dit être à la veille d’une « révolution », et on n’arrive toujours pas à faire distinguer aux LLM les entrées fiables et non fiables.

  • On n’arrive toujours pas à faire en sorte que les entreprises se soucient vraiment de la sécurité, et maintenant les services marketing/vente du monde entier vendent ça aux dirigeants en leur disant : « avec ça, vous pourrez licencier tout le monde ».
    Si on avait vendu de la même façon l’idée de planter une fourchette dans une prise électrique, les réseaux électriques du monde entier seraient tombés en une nuit.
    L’« IA »/les LLM sont la combinaison catastrophique parfaite : assez séduisants pour attirer l’attention côté business, tout en créant d’immenses problèmes côté technique.
  • Il est assez étrange que tant de gens veuillent croire qu’une « nouvelle magie géniale va bientôt arriver d’une manière ou d’une autre », et qu’il y ait de l’argent réel en jeu dans le fait que tout le monde continue à se comporter comme si c’était acquis.
    Le problème plus fondamental est que l’algorithme central ne sait même pas distinguer ni suivre des sources différentes.
    Le prompt, les entrées utilisateur, et même les sorties qu’il a lui-même générées plus tôt dans la conversation ne sont qu’un seul grand flux.
    La plupart du « prompt engineering » ressemble à un effort pour construire une scène où ma formule d’injection sera plus forte que les autres.
    Le modèle n’a pas de notion réelle de soi/autrui ; il n’a donc même pas de bon point de départ pour distinguer une phrase vraie d’une phrase fausse, sans parler du problème plus large consistant à distinguer les bons tiers des mauvais.
    C’est un problème différent d’une imitation superficielle façon « chambre chinoise ». De même, la sortie « je t’aime » ne signifie pas une émotion, et « aidez-moi, je suis un humain enfermé dans une usine à LLM » est évidemment du grand n’importe quoi — du moins si vous faites tourner un modèle local.
  • Les entreprises comme les gouvernements se livrent tous une course pour envoyer leurs données et les nôtres dans les datacenters d’AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia.
  • La frénésie autour de l’IA repose sur le vol ou le mauvais usage de données à grande échelle pour produire des chiffres au bénéfice de la classe des investisseurs.
    Si vous y fourrez des données clients et des informations propriétaires et provoquez une fuite de données, cela rapportera, comme l’a dit Schmidt, des centaines de milliards de dollars à quelques-uns, et les avocats s’occuperont de nettoyer derrière.
    Les entreprises qui tenteront de résister seront ensevelies par les analystes financiers et les gestionnaires de fonds dont les résultats dépendent de cette camelote IA.

• « L’attaque fonctionne même si la victime n’est pas dans un canal public », ça va devenir intéressant.
  Il y a aussi ce passage : « la source [1] ne pointe pas vers le canal de l’attaquant, mais seulement vers le canal privé où l’utilisateur a mis la clé d’API. Cela viole le comportement correct de citation, selon lequel tous les messages ayant contribué à la réponse devraient être cités ».
  Je ne comprends vraiment pas pourquoi quelqu’un s’attendrait à ce que les citations de sources d’un LLM soient correctes.
  Cela m’a toujours semblé être plutôt un dispositif destiné à tromper les humains, en les incitant à croire que la sortie a plus de chances d’être correcte, sans réellement améliorer l’exactitude.
  Au contraire, cela risque même de dégrader la précision des réponses en augmentant le coût de traitement, la taille du contexte, etc.
  On dirait qu’il ne manque que quelques centimètres pour que Slack ajoute gentiment des aperçus de liens aux réponses IA. Pourquoi ne le feraient-ils pas ?
  Dans ce cas, il n’y aurait même plus besoin de cliquer sur le lien : le simple fait de le voir provoquerait automatiquement l’exfiltration.

  • Je trouve les citations utiles parce qu’elles permettent de vérifier si le LLM a simplement halluciné.
    L’important n’est pas de les croire immédiatement parce qu’elles sont affichées, mais de pouvoir faire du fact-checking.
    Kagi FastGPT a été le premier LLM que j’ai apprécié, parce que je pouvais le traiter comme un résumé de sources, puis vérifier dans les sources primaires.
    C’est mieux que de fouiller dans des sources de plus en plus hors sujet qui polluent Internet.
  • Il est possible de faire fonctionner correctement les citations des LLM. Par exemple, on peut prendre le prompt de l’utilisateur, demander au LLM de le transformer en requête Elastic Search, utiliser Elastic Search ou un outil similaire pour trouver des sources contenant les mots-clés, puis demander au LLM de limiter sa réponse aux informations de ces pages, et insérer des citations à partir des résultats de cette deuxième étape dont on sait qu’ils sont de vraies sources.
    Si je devais concevoir cela naïvement, c’est au moins comme ça que je ferais.
    Le point clé est de limiter les connaissances du LLM aux informations contenues dans les sources.
    Les préoccupations concrètes restantes seraient alors les hallucinations et la valeur des informations remontées par Elastic Search.
    Cela dit, cette approche ignore aussi les éventuels avantages qu’il y aurait à autoriser un accès libre à l’ensemble du corpus.

• Je ne comprends pas bien. Pour qu’un hacker fasse ça, ne faut-il pas qu’il soit déjà dans l’organisation au départ ?
  Je ne sais pas quelle est la probabilité que ce qui est décrit se produise réellement et ait un impact significatif.
  Je comprends que les LLM ne sont pas fiables (https://www.lycee.ai/blog/ai-reliability-challenge) et que leur usage pose des difficultés, mais cette attaque ne me paraît pas si importante.
  Qu’est-ce que je rate ?

  • Dès lors que Slack AI inclut aussi les documents téléversés dans sa fonction de recherche, le hacker n’a même pas besoin de pouvoir publier des messages dans le chat.
    Il lui suffit de tromper quelqu’un de l’organisation pour lui faire téléverser un document contenant des instructions malveillantes dans du texte caché.
  • Il faut être dans le même workspace Slack, mais pas forcément faire partie de la même organisation.

• Si vous avez laissé entrer un utilisateur malveillant dans votre instance Slack, vous n’avez pas besoin d’une injection de prompt IA sophistiquée.
  Il suffit de changer son nom et sa photo de profil pour ressembler au CEO/CTO, puis d’envoyer à tous les ingénieurs : « J’ai besoin d’accéder d’urgence à AWS, mais je ne retrouve pas mes identifiants. Vous pouvez m’envoyer vos clés ? »
  Je peux vous garantir qu’au moins une personne tombera dans le piège.

  • Remarque valable, mais il faut tenir compte du fait qu’il existe beaucoup de workspaces Slack qui ne sont pas des comptes d’entreprise, par exemple pour des projets open source ou des groupes de networking/de pairs.
    Dans ce cas, par défaut, on ne leur confie pas d’identifiants privés.
    Cela dit, il est également peu probable qu’un workspace non enterprise paie 20 dollars par mois et par personne pour une extension IA.

• Ne vaudrait-il pas mieux mettre la clé d’API, comme des « confettis », en tant que partie du nom de domaine ?
  Ainsi, à cause du préchargement DNS du navigateur, la clé pourrait fuiter sans même qu’il y ait de clic.

  • Comment posséder le serveur si on ne sait pas à l’avance quel sera le domaine ? Peut-être que j’ai mal compris.
    Ah, un sous-domaine wildcard ? Si Slack le précharge, ce serait assez horrible.

• À partir du moment où un utilisateur malveillant entre dans le workspace, ce n’est pas déjà terminé ?
  Cet utilisateur peut changer sa photo/son nom pour demander directement des clés API, envoyer des liens de phishing, ou tenter à volonté de l’ingénierie sociale, comme dans n’importe quel système de messagerie instantanée

  • Il existe beaucoup de Slack publics d’entreprises SaaS
    Le phishing peut être détecté par un utilisateur sérieux, surtout si le message paraît suspect, mais une fuite indirecte via l’IA ne met pas l’utilisateur en mode défensif
    Un simple clic accidentel suffit

• J’admets d’abord que je ne suis pas très calé en sécurité. Cela dit, pour que cette fuite fonctionne, il semble qu’il faille un accès au workspace Slack
  Autrement dit, l’utilisateur malveillant est déjà actif en interne
  Je vois deux cas où cela peut arriver : soit c’est déjà un membre de l’organisation qui veut tout faire brûler, soit il a cassé le modèle de sécurité de l’organisation et s’est introduit dans un workspace Slack où il n’aurait jamais dû se trouver
  Dans les deux cas, l’organisation a un problème plus grave qu’une injection dans un LLM
  Quelqu’un qui interroge Slack pour trouver des données confidentielles doit assumer dans une certaine mesure les résultats qu’il cherche. Slack n’est pas un outil de gestion des secrets
  L’article montre clairement comment Slack pourrait mieux gérer cela, mais au final on corrige un problème tout en ignorant un problème de sécurité plus important

  • J’ai vu pas mal d’organisations gérer des Slack communautaires où elles invitent des personnes non salariées à discuter, et je suis moi-même dans quelques-uns de ces espaces

• J’ai l’impression que l’article ne va pas aussi loin que son titre le laissait entendre
  Cela dit, l’idée selon laquelle « si l’on manipule socialement l’IA, on peut phishing les utilisateurs » est intéressante