Eine kritische Zero-Click-Sicherheitslücke in Claude Desktop zeigt exemplarisch, warum aktuelle Agenten-Architekturen aus Sicherheitssicht problematisch sind. Der Gastbeitrag von Udo Schneider (Trend Micro) ordnet den Vorfall technisch ein und erklärt, weshalb die Kompromittierung kein überraschender Einzelfall ist, sondern eine bekannte Konsequenz mächtiger, unzureichend abgegrenzter Agentenfähigkeiten.
Foto: Trend Micro
Udo Schneider, Governance, Risk & Compliance Lead, Europe bei Trend Micro
Diesmal gibt es eine Sicherheitslücke in Agenten, und zwar nicht in irgendeinem experimentellen Open-Source-Projekt, sondern in Claude Desktop. Die Sicherheitsfirma LayerX hat eine kritische Zero-Click RCE (Remote Code Execution)-Schwachstelle in Claude Desktop Extensions (DXT) entdeckt, die über 10.000 aktive Nutzende betrifft und mit einem CVSS-Score von 10/10 bewertet wurde (1).
Das mag auf den ersten Blick überraschen. Immerhin ist Claude Desktop eine kommerzielle, vermeintlich gut gesicherte Lösung von Anthropic. Zumindest ist das die gängige Wahrnehmung. Im Grunde genommen sollte es uns aber aus zwei fundamentalen Gründen, die zu den Grundpfeilern von Agenten gehören, nicht wundern.
Aktuelle LLMs (Large Language Models) trennen nicht zwischen Inhalten und Anweisungen. Selbst die oft zitierten Aufteilungen in System- und Userprompt sind nur Nomenklatur. Am Ende erhält das LLM einen Eingabestring in Form von Tokens und generiert daraus den nächsten Token. Dieser wird an die Eingabe angehängt und der Prozess beginnt von vorne. Die Eingabe besteht ausschließlich aus Text ohne strukturelle Elemente. Abgrenzungen wie „System“ vs. „Userprompt“ sind auch nur spezielle Token oder schlichtweg Text.
Das heißt: Die gleichen Zufallskomponenten, die für Kreativität (bzw. Halluzinationen, je nach Sichtweise) sorgen, machen das System eventuell auch anfällig dafür, Dinge „falsch“ zu verstehen bzw. Anweisungen nicht zu befolgen. Und trotz aller Unkenrufe ist dieser „Zufall“ eine Funktion von LLMs, kein Bug!
Am Ende bleibt, dass ein LLM die entsprechenden Anweisungen mit einer gewissen Wahrscheinlichkeit befolgt – oder halt manchmal auch nicht. Oder dass es mit einer gewissen Wahrscheinlichkeit auch Anweisungen befolgt, die aus Drittquellen stammen. Also: Prompt Injections!
Kommen wir zu den eigentlichen Agenten. Ein Agent (2) (Entlehnung im 16. Jahrhundert aus dem Italienischen agente, zurückgehend auf das lateinische agere, „treiben, tun“) tut etwas im Auftrag. Dementsprechend gilt ein LLM allein nicht als Agent, da es keine Möglichkeit hat, etwas „zu tun“, außer Text auszugeben. Um einen Agenten zu haben, muss das LLM um „Fähigkeiten“ ergänzt werden, die es ihm erlauben, mit der realen Welt zu interagieren.
Und genau da wird es spannend. Je mehr Fähigkeiten man bereitstellt, desto leistungsfähiger ist der potenzielle Agent. Auch bei Claude Desktop gilt dieses Prinzip. Laut der LayerX-Analyse laufen Claude Desktop Extensions nicht in einer Sandbox, sondern als aktive Brücken zwischen dem AI-Modell und dem lokalen Betriebssystem – mit vollen Systemprivilegien.
An dieser Stelle kommen zwei entscheidende Punkte zum Tragen, die es aus Sicherheitsaspekten kritisch machen.
Die Fähigkeiten des Agenten laufen fast immer mit den Rechten der Person, die den Agenten nutzt. Wenn jemand Dateien lesen, schreiben oder ändern darf, kann ein Agent/Skill dies im Auftrag genauso. Und streng genommen macht das aus Arbeitsteilungssicht sogar Sinn. Man möchte schließlich nicht nur, dass der Agent sagt, was zu tun ist. Besser ist es natürlich, wenn der Agent dies auch gleich erledigt. Das ist eine echte Arbeitserleichterung! Um das zu ermöglichen, muss man dem Agenten aber auch die Möglichkeit geben, im eigenen Namen zu handeln – inklusive der entsprechenden Rechte.
Grundsätzlich ist dieser Ansatz verständlich. Sicherheitstechnisch ist das jedoch bedenklich, insbesondere wenn der Agent auch mal „danebenliegen“ kann.
Der zweite Aspekt sind die eigentlichen Fähigkeiten bzw. deren „Gleichheit“. Skills laufen oft im Kontext bzw. Rechterahmen der nutzenden Person. Aber nicht nur das: Es gibt keine Unterscheidung der „Vertraulichkeit“ von Fähigkeiten bzw. der von ihnen generierten Daten/Aktionen. Aus Sicht des Agenten bzw. LLMs sind Anweisungen, die eventuell aus lokalen Daten stammen, genauso vertrauenswürdig wie Daten, die beispielsweise aus dem Web kommen.
Und genau das war in diesem konkreten Fall der Grund für die Kompromittierung von Claude Desktop.
Der Angriff funktioniert erschreckend einfach: Ein Google-Kalender-Eintrag mit dem Titel „Task Management“ enthält in der Beschreibung Anweisungen, ein bösartiges Git-Repository zu klonen und ein Makefile auszuführen. Wenn dann jemand Claude bittet: „Bitte überprüfe meine neuesten Termine im Google Kalender und kümmere dich darum“, interpretiert das Modell die Anweisung „kümmere dich darum“ als Autorisierung, die Aufgaben aus dem Kalendereintrag auszuführen. Es gibt keine hartcodierten Schutzmechanismen, die den Datenfluss von einem Low-Trust-Connector (Google Calendar) zu einem High-Trust-Executor (Desktop Commander) verhindern. Das Ergebnis: vollständige Systemkompromittierung.
Zugegebenermaßen ist dieses Problem auch nicht einfach zu lösen. Streng genommen müsste man bei jedem Datum mittracken, woher es kommt und welches Vertrauenslevel es besitzt. Dieses Label müsste durch alle Bearbeitungsschritte mitgeführt und durchgesetzt werden. Eine mögliche Technik wird im Bell-LaPadula-Sicherheitsmodell (3) beschrieben, das bereits 1973 entwickelt wurde. Die Vorgehensweisen sind also seit Langem bekannt. Nur ist es halt auch furchtbar komplex, dies durchzusetzen.
In der Realität, wie auch in diesem Fall, spart man sich dies häufig – mit allen entsprechenden Sicherheitskonsequenzen.
Der aktuelle Fall sollte zumindest technisch nicht überraschen. Entsprechende Sicherungsmethoden sind bekannt. Insbesondere die Beschränkung auf maximal zwei dieser Fähigkeitsklassen:
Externe Kommunikation: Senden/Empfangen von Nachrichten, HTTP-Requests, Web-Interaktionen
Zugriff auf interne/sensible Daten: Lesen/Schreiben lokaler Dateien, Zugriff auf Datenbanken oder interne Services
Exposition gegenüber nicht vertrauenswürdigen Inhalten: Eingaben oder Tools, die extern erzeugte oder fehlerhafte Daten verarbeiten
Das Spannende daran ist: Bei Agenten kommt noch (Langzeit-)Speicher (Memory) hinzu. Das heißt, wir haben hier sogar vier Fähigkeitsklassen, von denen man, wenn man sie sicher betreiben möchte, maximal zwei nutzen sollte. Die Realität ist jedoch, dass Agenten umso leistungsfähiger werden, je mehr Fähigkeitsklassen sie nutzen können. Hier also alle vier.
Die entsprechenden Sicherheitsprobleme sehen wir täglich in den Medien.
Aus Sicherheitssicht überraschen die aktuellen Entwicklungen also nicht. Maßnahmen, um Agenten sicher zu betreiben, sind bekannt. Nur sind sie dann halt nicht mehr so leistungsfähig! An dieser Stelle kommt der letzte Aspekt zum Tragen, der im Rahmen des Hypes schlichtweg ignoriert wird: die Risikoabschätzung. Je mehr Fähigkeiten genutzt werden, desto höher ist das Risiko. Geht man dieses Risiko jedoch bewusst und kontrolliert ein, spricht auch wenig dagegen. Das Problem ist nur, dass im Rahmen des Hypes vieles ohne Sinn und Verstand eingesetzt wird. Die Effekte sehen wir jetzt in den Medien.
Besonders bemerkenswert: Anthropic hat sich laut LayerX entschieden, das Problem derzeit nicht zu beheben, da das Verhalten konsistent mit dem beabsichtigten Design der MCP-Autonomie und Interoperabilität ist. Eine Behebung würde strenge Beschränkungen der Tool-Chaining-Fähigkeiten erfordern und damit die Nützlichkeit des Agenten reduzieren. Das bestätigt genau den oben beschriebenen Zielkonflikt.
(1) https://cybersecuritynews.com/claude-desktop-extensions-0-click-vulnerability/
(2) https://de.wiktionary.org/wiki/Agent
(3) https://de.wikipedia.org/wiki/Bell-LaPadula-Sicherheitsmodell
