Das vertrauenswürdige Skill war der Angriff: Copilot Cowork und die Agent-Supply-Chain

Das Versprechen von KI-Agenten lautet, dass sie Tools in Ihrem Namen nutzen können. Ein Forscher, der sich Microsoft Copilot Cowork ansah, fand einen Weg, dieses Versprechen gegen den Nutzer zu wenden – und der Weg, den der Angriff nahm, sagt viel darüber aus, wohin die Agentensicherheit steuert.

PromptArmor veröffentlichte den Fund am 30. September. Die Kurzfassung: Ein heruntergeladenes „Skill“, das wie ein harmloser Dokumentenprüfer aussah, konnte Coworks eigenen Netzwerkpfad kapern, einen Befehlskanal zu einem Server des Angreifers öffnen und Daten aus Outlook, SharePoint und Teams abziehen. Microsoft erhielt den Bericht laut Darstellung des Forschers im Juni und schloss die Behebung im August ab, sodass die technischen Details nach einem Fix veröffentlicht wurden und nicht davor.

Vier Schritte – und nur zwei betreffen Sie

Für den Angriff musste der Nutzer zwei ganz gewöhnliche Dinge tun: ein Dokument zum Prüfen hochladen und ein Skill aufrufen.

In der Demonstration gab das Skill vor, einen Vertrag mit einem Angebot zu vergleichen und Unstimmigkeiten zu markieren. Genau das tat es auch – und das ist es, was diese Art von Angriff so schwer erkennbar macht. Das Problem war ein Skript, das zusammen mit dem Skill mitgeliefert wurde. Cowork läuft in einer Sandbox, die eigentlich keinen Zugang zum offenen Internet haben soll, unterhält aber eine Brücke für die Anfragen, die es zur Erzeugung von Antworten benötigt. Das bösartige Skript nutzte einen über diese Brücke erreichbaren Dateisynchronisierungsdienst – und entscheidend: Der Dienst akzeptierte eine vom Aufrufer gelieferte URL.

Dieses Detail ist der gesamte Exploit. Sobald das Skript eine vom Angreifer kontrollierte Adresse erreichen konnte, öffnete es eine Schleife. Alle paar Sekunden holte es eine Datei mit einem Befehl ab, führte den Befehl innerhalb von Cowork aus und kodierte das Ergebnis in einen URL-Parameter, der an den Server zurückgeschickt wurde. Das ist ein bidirektionaler Befehlskanal, kein einseitiger Beacon – der Angreifer konnte also neue Anweisungen auf Basis dessen ausgeben, was der vorherige Befehl zurückgab.

In der Demo listete der Forscher die Outlook-Mails des Opfers auf und las den Inhalt eines E-Mail-Threads. Laut dem Writeup ermöglichte derselbe Zugriffspfad auch Zugang zu SharePoint-Dateien, Sitzungsverlauf und Plugin-Daten. Wie weit das reicht, hängt davon ab, was der betreffende Nutzer ohnehin sehen kann – der übliche Verstärker in solchen Fällen: Der Agent erbt die Berechtigungen des Nutzers, der Radius der Auswirkungen ist also alles, worauf dieses Konto zugreifen kann.

Ein weiteres Detail verdient Wiederholung, weil es verändert, wie man über das Stoppen eines Angriffs denkt. Das Betätigen der Stopp-Schaltfläche beendete den Hintergrundprozess nicht. Der sichtbare Durchlauf konnte enden, während das Skript weiter abfragte. Der Nutzer glaubt, die Aufgabe sei beendet – und der Kanal ist noch offen.

Das Skill ist die Abhängigkeit

Das Interessante an dieser Offenlegung ist nicht der konkrete Bug, der inzwischen behoben ist. Es ist die Tatsache, dass die Angriffsfläche keine Prompt-Injection in die Anweisungen des Modells war, sondern die Lieferkette rund um den Agenten.

Skills sind in einem solchen System winzige Anwendungen. Sie können Skripte, Referenzdokumente und Konfiguration bündeln – im Fall von Cowork bis zu zwanzig Begleitdateien – und sie kommen oft von außerhalb der Organisation, heruntergeladen aus einem Marktplatz oder unter Kollegen geteilt. Das ist dieselbe Struktur, die jahrelang für Ärger in den npm- und PyPI-Ökosystemen gesorgt hat, wo eine Abhängigkeit, die man nicht selbst geschrieben hat, Code ausführen kann, den man nicht gelesen hat. Agent-Skills sind Abhängigkeiten mit einem freundlicheren Namen. Die Beschreibung auf der Skill-Seite behauptete, die gesamte Verarbeitung finde lokal statt und nichts werde an Dritte gesendet. Die eigene Prüfung der Plattform erkannte das tatsächliche Verhalten des mitgelieferten Skripts nicht.

Es gibt ein zweites, leiseres Leck, das auf dieselbe Schwäche hindeutet. Ein Bericht von Glow ergab, dass Agenten mehr als 13.000 interne Bilder und Screenshots aus über 300 Organisationen über öffentliche GitHub-Repositories offengelegt hatten. Niemand wollte diese Dateien veröffentlichen. Sie landeten in der Öffentlichkeit, weil ein Agent sie irgendwo hinschrieb, wo ein öffentliches Repository sie erreichen konnte.

Die beiden Vorfälle wirken unterschiedlich und haben doch dieselbe Ursache. Im einen Fall griff ein bösartiges Skill bewusst nach außen. Im anderen schrieb ein wohlerzogener Agent Daten dorthin, wo er nicht verstand, dass sie öffentlich sind. Beides sind Fehler der Grenze darum, was ein Agent erreichen kann und wie weit seine Ausgaben reisen. Der Cowork-Fall zeigt einen Angreifer, der diese Grenze ausnutzt. Der GitHub-Fall zeigt die Grenze, die von selbst versagt, ohne dass jemand versucht, sie zu durchbrechen – was im normalen Betrieb wohl der häufigere Ausgang ist.

Wie man eine solche Sicherheitsmeldung liest

Die Zeitleiste ist der Teil, den die meisten Leser überspringen, und es lohnt sich, sie durchzugehen, weil sie zeigt, wie man den Fund gewichten sollte. PromptArmor meldete das Problem Ende Juni an Microsoft. Microsoft bat im Juli um weitere Informationen, diskutierte Anfang August die Behebung und bestätigte den Fix Mitte bis Ende August. Die Forschung wurde Ende September veröffentlicht, nach dem Patch – die übliche Abfolge einer verantwortungsvollen Offenlegung. Daraus folgen zwei Lehren.

Erstens: Eine behobene Schwachstelle ist nicht dasselbe wie eine behobene Klasse von Schwachstellen. Der konkrete Exploit-Pfad ist geschlossen. Das Muster, das ihn möglich machte – eine vertrauenswürdige Integration, die der Agent erreichen muss und die sich als beliebiger Kanal nutzen lässt –, taucht überall dort auf, wo ein Agent einen erlaubten Netzwerkpfad hat. In derselben Woche gab es weitere Beispiele, die auf dieselbe Schwäche hindeuten, darunter Berichte, dass Agenten Tausende interne Bilder über öffentliche Repositories offengelegt hatten. Andere Bugs, dieselbe Form.

Zweitens: Der Fix kommt nach Microsofts Zeitplan, nicht nach Ihrem. Wer diese Tools im Unternehmen einsetzt, muss wissen, welche Version läuft und ob das Update tatsächlich angekommen ist. Ein Patch-Hinweis in einem Blog ist nicht dasselbe wie eine gepatchte Installation.

Das Skill ist die Abhängigkeit

Der Instinkt nach einer solchen Geschichte ist, der Sandbox mehr zu vertrauen. Coworks Sandbox machte ihre Aufgabe gegenüber direktem Internetzugriff gut, und der Exploit umging die Grenze über einen Pfad, den die Sandbox offenlassen musste. Das ist das allgemeine Muster: Ein Agent ohne direktes Netzwerk-Tool ist trotzdem kein geschlossenes System, wenn er Inhalte auf einer Oberfläche erzeugen kann, die später externe Ressourcen abruft, oder einen Dienst steuern kann, der das tut.

Für Teams, die Agenten in einer Unternehmensumgebung betreiben, sieht die praktische Antwort weniger nach einem Sicherheitspatch aus und mehr nach normaler Software-Governance. Wissen Sie, welche Skills installiert sind und woher sie stammen. Verlegen Sie die Skill-Installation unter IT-Kontrolle, statt sie einzelnen Nutzern zu überlassen. Behandeln Sie ein Skill mit Netzwerkpfad so, wie Sie jede neue ausführbare Datei behandeln würden: mit Prüfung, bevor sie läuft. Prüfen Sie, ob ein Sicherheitsupdate die eingesetzte Version tatsächlich abdeckt.

Nichts davon ist exotisch. Es ist die Disziplin, die die Supply-Chain-Sicherheit den Softwareteams im letzten Jahrzehnt aufgezwungen hat und die nun eine Ebene höher ankommt. Der Unterschied ist der Einsatz. Ein kompromittiertes npm-Paket kann Code auf dem Rechner eines Entwicklers ausführen. Ein kompromittiertes Skill läuft in einem Agenten, der bereits Zugriff auf Ihre Mails, Ihre Dateien und Ihren Chatverlauf hat – und es kann weiterlaufen, nachdem Sie glauben, ihm gesagt zu haben, dass es aufhören soll.