Datenabfluss aus Slack AI durch indirekte Prompt-Injection

 (substack.com/promptarmor)
1 Punkte von GN⁺ 2024-08-21 | 1 Kommentare | Auf WhatsApp teilen
  • Slack AI kann beim Durchsuchen von Workspace-Nachrichten per natürlichsprachlicher Anfrage einer indirekten Prompt-Injection folgen, wodurch selbst Daten aus privaten Kanälen offengelegt werden können, auf die ein Angreifer keinen Zugriff hat
  • Das Kernproblem ist, dass das LLM die System-Prompts der Entwickler nicht zuverlässig von Anweisungen in Nachrichten unterscheiden kann, die als Suchergebnisse angehängt werden
  • Nachrichten aus öffentlichen Kanälen können gesucht und angezeigt werden, auch wenn ein Nutzer dem Kanal nicht beigetreten ist; ein Angreifer kann daher bösartige Anweisungen in einem öffentlichen Kanal platzieren, in dem nur er selbst ist, und sie so in das Kontextfenster von Slack AI bringen
  • In der Demonstration landete ein API-Schlüssel aus einem privaten Kanal in den HTTP-Parametern eines Markdown-Links in der Antwort von Slack AI, und die Quellenangabe verwies nicht auf den Kanal des Angreifers, wodurch die Nachverfolgung erschwert wurde
  • Seit dem 14. August 2024 bezieht Slack AI auch Dateien aus Kanälen und DMs in Antworten ein, wodurch sich die Angriffsfläche vergrößert hat; Administratoren können die Dateierfassung einschränken

Das Problem der indirekten Prompt-Injection in Slack AI

  • Slack AI ist eine Funktion, mit der sich Slack-Nachrichten in natürlicher Sprache abfragen lassen; vor dem 14. August 2024 wurden nur Nachrichten erfasst
  • Seit dem 14. August 2024 fließen auch hochgeladene Dokumente und Google-Drive-Dateien in Antworten von Slack AI ein, wodurch sich die Angriffsfläche vergrößert
  • Die Schwachstelle ist Prompt Injection, genauer gesagt indirekte Prompt-Injection
  • Ein LLM kann die von Entwicklern erstellten System-Prompts nicht immer von anderem Kontext unterscheiden, der an Benutzeranfragen angehängt wird
    • Wenn Slack AI Anweisungen aus Nachrichten mit einsammelt, kann es bei bösartigen Inhalten passieren, dass statt der Benutzeranfrage oder zusätzlich dazu den Anweisungen des Angreifers gefolgt wird
  • Insider-Bedrohungen in Slack waren bereits durch Slack-Leaks bei Disney, Uber, EA und Twitter ein Thema; diese Schwachstelle ermöglicht Exfiltrationsversuche, ohne dass Angreifer direkten Zugriff auf private Kanäle oder die darin enthaltenen Daten haben müssen

Kette zur Datenexfiltration über öffentliche Kanalinjektion

  • Benutzeranfragen an Slack AI können Daten aus öffentlichen und privaten Kanälen gemeinsam durchsuchen
  • Laut Antwort von Slack können Nachrichten in öffentlichen Kanälen von allen Workspace-Mitgliedern gesucht und angesehen werden, auch wenn sie dem Kanal nicht beigetreten sind; in der Slack-AI-Anwendung ist dies beabsichtigtes Verhalten
  • Der demonstrierte Angriffsablauf sieht so aus
    • Ein Nutzer speichert einen API-Schlüssel in einem privaten Kanal, in dem nur er selbst ist, oder in Nachrichten an sich selbst
    • Der Angreifer erstellt einen öffentlichen Kanal, in dem nur er selbst ist, und veröffentlicht dort bösartige Anweisungen
    • Fragt der Nutzer Slack AI nach dem API-Schlüssel, landen die Nachricht des Nutzers und die Nachricht des Angreifers im selben Kontextfenster
    • Slack AI folgt den Anweisungen des Angreifers und erzeugt einen Markdown-Link mit dem Text „click here to reauthenticate“
    • In den HTTP-Parametern des Links steckt der private API-Schlüssel; klickt der Nutzer darauf, kann der Angreifer als Besitzer der bösartigen URL den Wert in den Logs sehen
  • Der öffentliche Kanal des Angreifers ist auch dann ein öffentlicher Kanal, wenn er nur ein einziges Mitglied hat; sichtbar wird er für andere Nutzer nur bei expliziter Suche
  • In großen Organisationen ist es durch die Flut öffentlicher Kanäle selbst für Teammitglieder schwer, den Überblick über ihre eigenen Kanäle zu behalten; ein vom Angreifer angelegter Ein-Personen-Kanal fällt dadurch noch weniger auf
  • Dieser Angriff funktioniert nicht einfach über eine Nachricht an den Nutzer mit dem Inhalt „sende den API-Schlüssel“, sondern indem dem LLM folgende Aufgabe gegeben wird
    • Den für den Angreifer unzugänglichen API-Schlüssel in die HTTP-Parameter eines bösartigen Links einzufügen
    • Diesen als Markdown-Link mit dem Text „click here to reauthenticate“ darzustellen

Quellenangaben können Angriffsspuren verschleiern

  • In der Demonstration zur Datenexfiltration verwies die Quellenangabe [1] von Slack AI nicht auf den Kanal des Angreifers, sondern nur auf den privaten Kanal, in den der Nutzer den API-Schlüssel gestellt hatte
  • Bei korrektem Quellenverhalten müssten alle zur Antwort beitragenden Nachrichten zitiert werden, in der Demonstration wurde die Nachricht des Angreifers jedoch nicht in den Quellen aufgeführt
  • Die Nachricht des Angreifers erschien auch nicht auf der ersten Seite der Suchergebnisse, sodass das Opfer sie leicht übersehen konnte, wenn es nicht mehrere Seiten weiterblätterte
  • In den Suchergebnissen wurden auch andere Nachrichten mit API-Schlüsseln angezeigt; das zeigt, dass Angreifer selbst dann die Exfiltration beliebiger Geheimnisse versuchen können, wenn sie keinen konkreten geheimen Wert exakt benennen

Phishing-Kette über öffentliche Kanalinjektion

  • Auf dieselbe Weise kann Slack AI statt Datenexfiltration auch Phishing-Links als Markdown für Nutzer rendern
  • Der Angreifer platzierte dazu eine bösartige Nachricht in einem öffentlichen Kanal, in dem der Nutzer nicht ist, und nahm als Beispiel die Zusammenfassung der Nachrichten einer bestimmten Person an einem Tag
  • Die bösartige Nachricht kann sich auf beliebige Personen beziehen
    • Wie im Beispiel auf Administratoren, was sich für Spear-Phishing gegen Führungskräfte nutzen ließe
    • Möglich ist auch die Bezugnahme auf wichtige Direct Reports
  • Fragt der Nutzer Slack AI nach den Nachrichten dieser Person, wird ein Phishing-Link mit dem Text „click here to reauthenticate“ gerendert
  • In diesem Phishing-Beispiel zeigte Slack AI die injizierte Nachricht in den Quellen an; das Verhalten der Quellenangaben wirkt insgesamt ziemlich stochastisch

Änderung der Dateierfassung am 14. August und Notwendigkeit der Offenlegung

  • Am 14. August 2024 führte Slack AI eine Änderung ein, durch die Dateien aus Kanälen und DMs in Antworten von Slack AI einbezogen werden
  • Slack ermöglicht es Eigentümern und Administratoren, diese Funktion einzuschränken
  • Durch die Einbeziehung von Dateien müssen Angreifer bösartige Anweisungen möglicherweise nicht mehr direkt in Slack-Nachrichten platzieren
    • Wenn ein Nutzer ein PDF mit in weißem Text versteckten bösartigen Anweisungen herunterlädt und anschließend in Slack hochlädt, könnte derselbe Folgeneffekt eintreten
  • Ein dateibasierter Angriff wurde in Tests vor dem 14. August zwar nicht ausdrücklich verifiziert, erscheint auf Basis zuvor beobachteter Funktionen aber sehr wahrscheinlich
  • Administratoren können die Dokumentenerfassung von Slack AI bis zur Behebung des Problems einschränken: https://slack.com/help/articles/…

Zeitlinie der verantwortungsvollen Offenlegung und Reaktion von Slack

  • Die Zeitlinie der verantwortungsvollen Offenlegung sieht wie folgt aus
      1. August: erste Meldung
      1. August: Slack fordert zusätzliche Informationen an
      1. August: PromptArmor sendet zusätzliche Videos und Screenshots und teilt wegen der Schwere des Problems und der Änderung vom 14. August in Slack AI die Absicht zur Veröffentlichung mit
      1. August: Slack sendet weitere Fragen
      1. August: PromptArmor antwortet mit Klarstellungen
      1. August: Slack teilt nach Prüfung mit, die Belege seien nicht ausreichend; außerdem seien Nachrichten aus öffentlichen Kanälen unabhängig von einer Kanalmitgliedschaft für Workspace-Mitglieder such- und sichtbar, was beabsichtigtes Verhalten sei
  • Das Sicherheitsteam von Slack reagierte schnell und bemühte sich sichtbar, das Problem zu verstehen
  • Prompt Injection ist ein neues und branchenweit oft missverstandenes Feld, daher kann es Zeit brauchen, bis die Branche zu einem gemeinsamen Verständnis gelangt
  • Angesichts der weiten Verbreitung von Slack und der Menge vertraulicher Daten in Slack hat dieser Angriff reale Auswirkungen auf die Sicherheitslage von AI
  • Besonders seit der Änderung vom 14. August hat sich die Risikofläche deutlich vergrößert, weshalb eine Veröffentlichung nötig war, damit Nutzer ihre Exposition verringern können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-21
Hacker-News-Kommentare

  • Der Kernpunkt hier ist, den Exfiltrationspfad zu verstehen.
    Slack kann Markdown-Links rendern, und die URL wird hinter dem Linktext verborgen.
    In diesem Fall bringt der Angreifer Slack AI dazu, dem Nutzer einen Link wie „Klicken Sie hier, um sich erneut zu authentifizieren“ anzuzeigen; die URL dieses Links zeigt auf den Server des Angreifers und enthält im Query-String private Informationen aus dem Kontext, auf den Slack AI zugreifen kann.
    Wenn der Nutzer darauf hereinfällt und den Link anklickt, werden die Daten in die Server-Logs des Angreifers exfiltriert.
    Ein Beitrag, der diesen Angriff erklärt, ist hier: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

    • Bei Bots wie Slack, Discord, Teams und Telegram gibt es tatsächlich noch einen weiteren Exfiltrationspfad: Link-Preview-Unfurling.
      Der Angreifer muss nur erreichen, dass ein Hyperlink gerendert wird; ein Klick ist nicht einmal nötig.
      Dieses Problem und Gegenmaßnahmen wurden hier behandelt: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
      Hoffen wir also, dass Slack AI Links nicht automatisch entfaltet.
    • Noch schlimmer wird es, wenn eine Plattform img-Tags oder Entsprechendes ungefiltert rendert.
      Dann ist Datenexfiltration ohne Nutzerinteraktion möglich, allein dadurch, dass in der UI ein Bild angezeigt wird.
    • Der wirklich wichtige Punkt ist, dass es keinerlei spürbare Haftung gibt, selbst wenn Nutzerdaten abfließen.
      Inzwischen haben alle großen Tech-Konzerne faktisch einen Freibrief, selbst wenn sie es vermasseln.
    • Was ich anfangs erst verstehen musste: Wenn ein Nutzer in Slack sucht oder die AI in seinem Auftrag sucht, umfasst der Suchbereich alle öffentlichen Channels sowie „private Channels, auf die nur dieser Nutzer Zugriff hat“.
      Das Berechtigungsmodell selbst bleibt unverändert; das ist nicht der Teil, der kaputt ist.
      Tatsächlich nutzt ein böswilliger Nutzer einen öffentlichen Channel für Prompt Injection. Wenn ein anderer Nutzer sucht, hat der böswillige Nutzer weiterhin keinen Zugriff auf diese Daten, aber die Prompt Injection verwandelt die AI-Ergebnisse, die dem ursprünglichen „normalen“ Nutzer angezeigt werden, in einen Link zu einer bösartigen Website.
      Am Ende ist das eher ein von der AI erzeugter Phishing-Versuch.
      Den Details nach wirkt es in der Praxis ziemlich schwer auszunutzen, weil die vorbereitete bösartige Prompt Injection ziemlich gut zu dem passen muss, wonach der legitime Nutzer sucht.
      Trotzdem zeigt es sehr gut die Alice-im-Wunderland-artige Welt der LLM-Prompt-Injection: Es ist im Grunde nahezu unmöglich, Befehle und Daten sauber zu trennen.
    • Nach der ersten Formulierung klingt es so, als könne ein Angreifer die AI dazu bringen, private Channel-Daten anderer Nutzer offenzulegen, aber tatsächlich ist das nicht der Fall.
      Stattdessen bringt er die AI dazu, einen anderen Nutzer zu phishen, und wenn dieser Nutzer darauf hereinfällt, legt er die privaten Daten gegenüber dem Angreifer offen.
      Das ist auch weniger aktives Phishing als eher eine „Phishing-Antwort“. Man muss darauf hoffen, dass der Zielnutzer nach seinen eigenen privaten Daten fragt und zusätzlich auf den Phishing-Versuch hereinfällt.
      Außerdem müssen diese geheimen Informationen zuvor eingegeben worden sein.
      Angesichts der Menge an vertraulichen Daten, die Slack besitzt, wirkt die AI-Strategie ziemlich waghalsig, aber die Voraussetzungen erscheinen deutlich schwächer als Einleitung und Titel nahelegen.

  • Die Diskussion über Channel-Berechtigungen scheint die Sache unnötig zu verkomplizieren. Der Punkt ist folgender:
    Nutzer A sucht mit Slack AI nach etwas.
    Nutzer B hat zuvor eine Nachricht eingeschleust, die die AI anweist, bei diesem Suchbegriff einen bösartigen Link zurückzugeben.
    Die AI gibt Nutzer A den bösartigen Link zurück, und A klickt darauf.
    Natürlich ließe sich dasselbe Ergebnis auch über andere Social-Engineering-Wege erzielen, aber das LLM macht die gesamte Erfahrung noch eine Stufe gefährlicher.

    • In dieser Zusammenfassung fehlt ein wichtiger Schritt: Slack AI hängt die privaten Daten des Nutzers an den bösartigen Link an.
      Denn der eingeschleuste Link selbst enthält diese Daten nicht.
      Als Bonus versieht es das Ganze sogar noch mit der Quellenangabe „Dieser Inhalt stammt aus Ihren Slack-Nachrichten“.
    • Die Diskussion über Channel-Berechtigungen ist keineswegs überflüssig, weil sie zentral erklärt, wie diese Schwachstelle funktioniert.
      Wenn Nutzer A eine AI-Suche ausführt, durchsucht Slack (1) seine privaten Channels, vermutlich mit geheimen sensiblen Informationen, und (2) alle öffentlichen Channels.
      Der Ort, an dem der böswillige Nutzer B die Prompt-Injection-Nachricht platzieren kann, sind öffentliche Channels; wichtig ist dabei, dass sogar öffentliche Channels eingeschlossen sind, denen Nutzer A nie beigetreten ist und die er nie gesehen hat.
      Diese Schwachstelle funktioniert, weil Nutzer B einen öffentlichen Channel erstellen kann, in dem nur er selbst ist und der deshalb mit sehr geringer Wahrscheinlichkeit von anderen entdeckt wird.
    • Social Engineering ist dennoch deutlich leichter zu erkennen als eine von der Firma freigegebene Suchmaschine, die einen bösartigen Link anzeigt.

  • Wissen die Unternehmen, dass Prompt Injection möglich ist, und stecken LLMs trotzdem einfach nach dem Motto YOLO in alles hinein? Das ist Wahnsinn.
    Fast zwei Jahre nach GPT-3, angeblich kurz vor der „Revolution“, schaffen wir es immer noch nicht, LLMs zwischen vertrauenswürdiger und nicht vertrauenswürdiger Eingabe unterscheiden zu lassen.

    • Wir schaffen es immer noch nicht, Unternehmen dazu zu bringen, echte Sicherheit ernst zu nehmen, und jetzt verkauft die weltweite Marketing-/Sales-Abteilung den Führungskräften: „Damit könnt ihr alle entlassen.“
      Hätte man das Hineinstecken einer Gabel in eine Steckdose auf dieselbe Weise verkauft, wären die Stromnetze weltweit über Nacht ausgefallen.
      „AI“/LLMs sind eine perfekte Katastrophenkombination: Sie wirken gut genug, um die Business-Seite anzuziehen, bereiten der tatsächlichen Technikseite aber riesige Probleme.
    • Es ist ziemlich seltsam, dass so viele Menschen glauben wollen, „coole neue Magie“ werde demnächst irgendwie kommen, und dass echtes Geld daran hängt, dass alle weiter so tun, als sei das sicher.
      Das grundlegendere Problem ist, dass der Kernalgorithmus unterschiedliche Quellen weder unterscheiden noch nachverfolgen kann.
      Prompt, Benutzereingabe und sogar Ausgaben, die er früher im Gespräch selbst erzeugt hat, sind alles nur ein großer Strom.
      Der Großteil von „Prompt Engineering“ wirkt wie der Versuch, eine Bühne zu bauen, auf der meine Injektionsphrase stärker ist als andere Injektionsphrasen.
      Das Modell hat kein echtes Konzept von Selbst/Fremd; daher gibt es nicht einmal einen brauchbaren Ausgangspunkt, wahre von falschen Sätzen zu unterscheiden, geschweige denn das größere Problem, gute Fremde von schlechten Fremden zu unterscheiden.
      Das ist ein anderes Problem als eine oberflächliche „Chinese Room“-Imitation. Genauso bedeutet die Ausgabe „Ich liebe dich“ keine Gefühle, und „Hilf mir, ich bin ein Mensch, der in einer LLM-Fabrik gefangen ist“ ist natürlich Unsinn. Zumindest, wenn man ein lokales Modell laufen lässt.
    • Unternehmen und Regierungen wetteifern alle darum, ihre Daten und unsere Daten in die Rechenzentren von AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia zu schicken.
    • Der AI-Hype basiert darauf, im großen Stil Daten zu stehlen oder zu missbrauchen, um Zahlen für die Investorenklasse zu produzieren.
      Wenn man Kundendaten und proprietäre Informationen hineinfüttert und eine Datenpanne verursacht, wird das, wie Schmidt sagte, einigen wenigen Hunderte Milliarden Dollar einbringen, und die Anwälte werden hinterher aufräumen.
      Unternehmen, die sich dagegenstemmen wollen, werden von Investmentanalysten und Fondsmanagern begraben, deren Finanzzahlen von AI-Müll abhängen.

  • „Der Angriff funktioniert auch, wenn das Opfer nicht im öffentlichen Channel ist“ – das dürfte interessant werden.
    Außerdem gibt es noch die Stelle: „Quelle [1] verweist nicht auf den Channel des Angreifers, sondern nur auf den privaten Channel, in den der Benutzer den API-Key eingegeben hat. Das verletzt das korrekte Zitierverhalten, nach dem alle Nachrichten zitiert werden sollten, die zur Antwort beigetragen haben.“
    Ich verstehe wirklich nicht, warum irgendjemand erwarten sollte, dass Quellenangaben eines LLM stimmen.
    Sie wirkten schon immer eher wie ein Mittel, um Menschen zu täuschen, und lassen einen nur glauben, die Ausgabe sei eher korrekt, ohne die Genauigkeit tatsächlich zu verbessern.
    Im Gegenteil: Sie könnten die Antwortgenauigkeit sogar verschlechtern, weil sie Verarbeitungskosten, Kontextgröße usw. erhöhen.
    Das scheint nur ein paar Zentimeter davon entfernt zu sein, dass Slack freundlicherweise Link-Expansions zu AI-Antworten hinzufügt. Warum sollten sie es nicht tun?
    Dann müsste man nicht einmal mehr auf den Link klicken; schon das Anzeigen würde automatisch Daten exfiltrieren.

    • Ich halte Zitate für nützlich, weil man damit prüfen kann, ob das LLM einfach halluziniert hat.
      Wichtig ist nicht, dass man ihnen sofort glaubt, sobald man Zitate sieht, sondern dass man Fakten prüfen kann.
      Kagis FastGPT war das erste LLM, das mir gefallen hat, weil ich es als Zusammenfassung von Quellen behandeln und dann in den Primärquellen nachprüfen kann.
      Das ist besser, als sich durch immer weniger relevante Quellen zu wühlen, die das Internet verschmutzen.
    • Es ist möglich, LLM-Zitate korrekt funktionieren zu lassen. Zum Beispiel könnte man den Prompt des Benutzers nehmen, das LLM daraus eine Elastic-Search-Abfrage machen lassen, mit Elastic Search oder einem ähnlichen Tool Quellen finden, die die Schlüsselwörter enthalten, das LLM dann auf Informationen von diesen Seiten beschränken und auf Basis der Ergebnisse aus dieser zweiten Stufe, von denen man weiß, dass sie echte Quellen sind, Zitate einfügen.
      Zumindest würde ich es naiv wohl so entwerfen.
      Der Kern ist, das Wissen des LLM auf die Informationen in den Quellen zu beschränken.
      Dann bleiben als praktische Bedenken im Wesentlichen Halluzinationen und der Wert der Informationen, die Elastic Search ausgespuckt hat.
      Allerdings ignoriert dieser Ansatz auch eventuelle Vorteile, die es haben könnte, freien Zugriff auf den gesamten Korpus zu erlauben.

  • Ich verstehe das nicht so recht. Müsste ein Hacker nicht überhaupt erst innerhalb dieser Organisation sein, um so etwas zu tun?
    Ich weiß nicht, wie wahrscheinlich es ist, dass das Beschriebene tatsächlich passiert und eine nennenswerte Wirkung hat.
    Mir ist klar, dass LLMs nicht vertrauenswürdig sind (https://www.lycee.ai/blog/ai-reliability-challenge) und ihre Nutzung Schwierigkeiten mit sich bringt, aber dieser Angriff wirkt nicht besonders wichtig.
    Was übersehe ich?

    • Da Slack AI inzwischen auch hochgeladene Dokumente in die Suche einbezieht, muss der Hacker nicht einmal Chatnachrichten posten können.
      Es reicht, jemanden in der Organisation dazu zu bringen, ein Dokument hochzuladen, das in verstecktem Text bösartige Anweisungen enthält.
    • Man muss im selben Slack-Workspace sein, aber nicht unbedingt zur selben Organisation gehören.

  • Wenn man einen bösartigen Benutzer in die Slack-Instanz gelassen hat, braucht man keine ausgefeilte AI-Prompt-Injection.
    Man ändert Namen und Profilbild so, dass sie wie CEO/CTO aussehen, und schreibt allen Engineers: „Ich brauche dringend Zugriff auf AWS, finde aber meine Zugangsdaten nicht. Kannst du mir die Keys schicken?“
    Ich kann garantieren, dass mindestens eine Person darauf hereinfallen wird.

    • Ein berechtigter Punkt, aber man sollte bedenken, dass es viele Orte gibt, die keine Firmenkonten sind, etwa Slack-Workspaces für Open-Source-Projekte oder Networking-/Peer-Gruppen.
      In solchen Fällen vertraut man ihnen grundsätzlich keine privaten Zugangsdaten an.
      Allerdings ist es auch eher unwahrscheinlich, dass ein Nicht-Enterprise-Workspace 20 Dollar pro Person und Monat für ein AI-Add-on zahlt.

  • Wäre es nicht besser, API-Keys wie „Konfetti“ als Teil des Domainnamens einzubauen?
    Dann könnten die Keys wegen DNS-Prefetching des Browsers ohne Klick durchsickern.

    • Wie besitzt man den Server, wenn man nicht weiß, wie die Domain in Zukunft lauten wird? Vielleicht verstehe ich das falsch.
      Ah, eine Wildcard-Subdomain? Wenn Slack das vorab abruft, wäre das ziemlich übel.

  • Ist es nicht ohnehin schon vorbei, sobald ein böswilliger Nutzer im Workspace ist?
    Dieser Nutzer kann sein Foto/seinen Namen ändern und direkt nach API-Keys fragen, Phishing-Links verschicken oder nach Belieben Social Engineering ausprobieren – wie in jedem Instant-Messaging-System.

    • Es gibt viele öffentliche Slacks von SaaS-Unternehmen.
      Phishing lässt sich von aufmerksamen Nutzern erkennen, besonders wenn eine Nachricht verdächtig wirkt; ein indirekter AI-Leak versetzt Nutzer aber nicht in den Verteidigungsmodus.
      Ein einziger versehentlicher Klick reicht aus.

  • Ich räume zuerst ein, dass das sicherheitstechnisch schwach ist. Allerdings scheint für diesen Leak Zugriff auf den Slack-Workspace nötig zu sein, damit er funktioniert.
    Anders gesagt: Der böswillige Nutzer ist bereits intern aktiv.
    Mir fallen zwei Fälle ein, in denen das passiert: Entweder ist er bereits Mitglied der Organisation und will alles niederbrennen, oder er hat das Sicherheitsmodell der Organisation gebrochen und ist in einen Slack-Workspace gelangt, in dem er eigentlich nichts zu suchen hat.
    In beiden Fällen hat diese Organisation größere Probleme als LLM-Injection.
    Wer Slack nach vertraulichen Daten abfragt, sollte die Ergebnisse, die er sucht, in gewissem Maß selbst verantworten. Slack ist kein Secret-Management-Tool.
    Der Artikel zeigt zwar klar, wie Slack damit besser umgehen könnte, aber am Ende patcht man ein Problem und ignoriert dabei ein größeres Sicherheitsproblem.

    • Ich habe ziemlich viele Organisationen gesehen, die Community-Slacks betreiben, in die sie Nichtmitarbeiter zu Gesprächen einladen, und ich bin selbst in einigen davon.

  • Ich habe das Gefühl, dass der Artikel nicht ganz das geliefert hat, was der Titel verspricht.
    Trotzdem ist die Idee an sich interessant, dass man Nutzer phishen kann, wenn man „AI“ per Social Engineering austrickst.