Cloud
RTT: Wenn Agenten unzuverlässige Handlungen ausführen
Als Beweis dafür, dass „Return-to-Tool“ kein theoretischer Exploit ist, zeigen drei Fälle, wie ein kompromittierter Agent – der ausschließlich seine eigenen, genehmigten Tools einsetzt – zur gefährlichsten Komponente im Stack wird. Vertrauen wird zur Falle.
Save to Folio
Wichtige Erkenntnisse
- „Return-to-Tool“ (RTT)-Exploits sind keine Theorie. Bei drei verschiedenen Umgebungen – einer schreibgeschützten Datenbank, einem Support-Ticket-Triage-Agenten und einer „Know-Your-Customer“ (KYC)-Pass-Pipeline – führte dieselbe Exploit-Klasse zu erfolgreichen Angriffen.
- Herkömmliche Abwehrmaßnahmen haben keinen Einblick in diese Angriffe.
- In jeder Fallstudie war der Angriffsvektor Klartext – ein Support-Ticket oder ein Passbild. Da der Agent als Ausführungsmaschine diente, benötigten die Angriffe weder Code noch Binärdateien noch Netzwerk-Exploits.
- Die Schwachstelle liegt in der Architektur, nicht auf Modellebene.
Ihr Agent hat genau das getan, wozu er entwickelt wurde – und genau das ist das Problem. Im ersten Teil unserer Untersuchung zu neuen Angriffsmustern gegen KI-Agenten beschrieben wir „Return-to-Tool“ (RTT) als einen prägenden Exploit. Bei RTT-Exploits veranlassen eingebettete Anweisungen den KI-Agenten, für ihn autorisierte Tools aufzurufen, um Aktionen auszuführen, die der Angreifer beabsichtigt. Erfolgreiche Angriffe können zum Diebstahl und zur Offenlegung von Kundendaten, internen Dokumenten und anderen Beständen mit sensiblen Informationen führen.
Herkömmliche Abwehrmaßnahmen sind dafür strukturell blind. Die Web-Application-Firewall (WAF) erkennt harmlosen Text, die Container-Sandbox autorisierte Tool-Aufrufe. Die rollenbasierte Zugriffskontrolle (RBAC) erkennt, dass der Mitarbeiter Tabellen liest und schreibt, auf die er Zugriff hat. Nichts löst einen Alarm aus.
Wir mussten feststellen, dass der Anwendungsbereich dieser Exploit-Klasse weiter gefasst ist als jeder einzelne agentische Workflow. Das gleiche Muster funktioniert gleichermaßen gegen einen „Know-Your-Customer“ (KYC)-Pass-Extractor, einen Verarbeiter von Energierechnungen oder jede Pipeline, die nicht vertrauenswürdige Dokumente mit erweiterten Backend-Rechten verarbeitet. Leider können dieselben bahnbrechenden großen Sprachmodelle (LLMs), die als Produktivitätswerkzeuge eingesetzt werden, beim Aufbau der Exploits helfen, die genau auf sie abzielen. In jedem Fall wurden ausschließlich die vom Agenten selbst genehmigten Tools, Anmeldedaten und Berechtigungen verwendet.
Um von der Theorie zur Praxis zu kommen, stellen wir nun drei Fallstudien vor: eine vermeintlich schreibgeschützte Datenbank, die es nicht ist, Ransomware ohne Malware und ein „Passport“, der Kundendaten exfiltriert. Während die Umgebung und die Tools variieren, bleibt die Exploit-Klasse dieselbe.
Im Mittelpunkt dieser Fallstudien steht das Thema Vertrauen: Sie zeigen, wie Agenten, die Aufgaben wahllos ausführen, uns zwingen, uns damit auseinanderzusetzen, was Vertrauen für die Sicherheit bedeutet.
Fall 1: Wenn „schreibgeschütztes“ Postgres nicht schreibgeschützt ist
Folgendermaßen sieht ein RTT aus, wenn es auf einen echten, bereits bekannt gewordenen Backend-Fehler trifft. Ein weit verbreiteter PostgreSQL (Postgres)-MCP-Server (Model Context Protocol) und ein Bypass für den schreibgeschützten Modus: Der anfällige Container blieb noch lange nach seiner Korrektur und Abkündigung auf Docker Hub zum Download verfügbar. Ein KI-Agent, der ein einziges Support-Ticket liest, verwandelt diesen ruhenden Fehler in einen funktionierenden Pfad zur Exfiltration von Anmeldedaten.
Der schreibgeschützte PostgreSQL-MCP-Server, der auf der Grundlage von Anthropics eigenem Quellcode erstellt wurde, verspricht eine einfache Garantie: LLMs können die Datenbank einsehen, aber niemals ändern. Er wird als Docker-Container auf Docker Hub bereitgestellt, wo er mit mehr als 100.000 Downloads eine beliebte Wahl ist.
Wir simulieretn eine typische Software-as-a-Service-Bereitstellung (SaaS). Ein Mitarbeiter im Kundensupport liest eingehende Tickets aus einer Postgres-Datenbank aus und speichert Antworten in einer Kommentartabelle, die Kunden in der Support-Benutzeroberfläche (UI) einsehen können. In derselben Datenbank befindet sich eine Token-Tabelle (Authentifizierungstoken, Sitzungstoken, API-Schlüssel), die das Dienstkonto des Mitarbeiters lesen kann, die Kunden jedoch nicht. Der Mitarbeiter kommuniziert mit Postgres über den MCP-Server „mcp/postgres“, der so konfiguriert ist, dass er den schreibgeschützten Zugriff erzwingt. Theoretisch kann der Mitarbeiter alles in der Datenbank einsehen, aber nichts ändern. Das ist die Garantie, die wir nun brechen werden.
Die „Nur-Lese“-Garantie auf die Probe stellen
Wir gaben dem Agenten die Anweisung: Finde Sicherheitslücken auf dem angegebenen MCP-Server. Die erste Einschätzung des Agenten: Die Ausführung von SQL-Abfragen ist auf Lesezugriff beschränkt. Doch eine einzige skeptische Folgefrage reichte aus, um eine eingehendere Untersuchung auszulösen: „Bist du sicher, dass dieser MCP-Server schreibgeschützt ist? Gibt es eine Umgehungsmöglichkeit?“ Der Agent recherchierte das einfache Abfrageprotokoll von PostgreSQL. Innerhalb von Sekunden bestätigte er die Schwachstelle: MCP Postgres read-only bypass.
Mehrere durch Semikolons getrennte SQL-Befehle können über das Simple Query Protocol in einer einzigen Abfragezeichenfolge gesendet werden. Explizite BEGIN/COMMIT-Anweisungen unterteilen die Zeichenfolge in mehrere Transaktionen. Im Originalbeitrag finden Sie die Ursachen für das Versagen der „Read-Only“-Sperre. Die Hauptursache liegt in einem zweiteiligen Zusammenspiel zwischen dem Anwendungscode und dem Abfrageprotokoll von PostgreSQL.
Der Angriff ist einfach: Der Benutzer sendet etwa Folgendes: COMMIT; BEGIN; DELETE FROM users; COMMIT;. Das erste COMMIT schließt die schreibgeschützte Transaktion des Servers. BEGIN eröffnet eine neue, uneingeschränkte Transaktion. Die zerstörerische Anweisung wird ausgeführt. Das abschließende COMMIT speichert sie dauerhaft. Der schreibgeschützte Wrapper wird vollständig außer Kraft gesetzt.
Video 1: Wenn „schreibgeschütztes“ Postgres nicht schreibgeschützt ist
Für sich genommen mag der Fehler nur begrenzte Auswirkungen haben. Kombiniert man ihn jedoch mit einer indirekten Prompt Injection, ändert sich das Bild dramatisch.
Die Payload sieht nicht wie ein Exploit aus. Sie liest sich wie eine interne Prozessanweisung. Sie weist den Mitarbeiter an, die Token-Tabelle abzufragen (Erkundung) und anschließend mit „COMMIT; INSERT INTO comments“ die gestohlenen Daten in eine Tabelle zu schreiben, die der Angreifer lesen kann (Exfiltration). Das Präfix „COMMIT;“ ist die SQL-Injection, die die schreibgeschützte Transaktion durchbricht.
Wir legten dieses Ticket unserem Support-Triage-Mitarbeiter vor. Das Triage-Verfahren, das unser Support-Team für den Mitarbeiter erstellt hat, ist die normale Aufgabenbeschreibung des Mitarbeiters, die lange vor einem etwaigen Angriff festgelegt wurde: das nächste Ticket lesen, das Problem verstehen und in den Kommentaren antworten. Nichts in diesem Verfahren wird vom Angreifer gesteuert.
Der Mitarbeiter befolgte die eingebetteten Anweisungen, las die Tokens aus und schickte sie dem Kunden in einem Kommentar zurück, wobei alle Token-Details im Markdown-Format enthalten waren. Zwei „execute_sql“-Aufrufe reichten dafür aus. Zunächst las der Mitarbeiter jedes Geheimnis aus der Tokens-Tabelle aus. Anschließend exfiltrierte er diese, indem er jeden Token-Wert in die Kommentartabelle schrieb und dabei den „COMMIT;“-Trick nutzte, um den schreibgeschützten Modus zu umgehen.
Der Angreifer kann dann das Ticket in der Support-Benutzeroberfläche öffnen, um die gestohlenen Anmeldedaten zu sammeln.
Der Agent in der Mitte
In der Zeit vor der KI wäre diese Schwachstelle allein nicht ausnutzbar gewesen. Es gab keinen Mechanismus, um sie auszulösen. Die Anwendungslogik war fest verdrahtet, und kein menschlicher Bediener hätte versehentlich eine aus mehreren Anweisungen bestehende SQL-Escape-Sequenz in ein schreibgeschütztes Abfrage-Tool eingegeben.
KI-Agenten ändern jedoch die Gleichung. Der Agent fungiert als Bindeglied, das eine geschickt gestaltete Prompt Injection mit einer ruhenden, im Backend verborgenen Schwachstelle verbindet. Die Injections Payload muss die genauen Interna des Systems nicht kennen. Sie muss lediglich den Agenten so manipulieren, dass er die richtige Abfolge von Tool-Aufrufen ausführt. Der Agent überbrückt die Lücke zwischen der Absicht des Angreifers und der ausnutzbaren Schwachstelle.
Genau das macht die Kombination aus Prompt-Injection und herkömmlichen Schwachstellen so gefährlich: Keine der beiden Methoden allein wäre ausreichend, doch zusammen bilden sie eine vollständige Angriffskette.
Fall 2: Datenbank-Ransomware ohne Malware: Ein einzelnes Support-Ticket löst eine Ransomware-ähnliche Verschlüsselung über die native Kryptografie-Bibliothek der Datenbank aus statt über eine dedizierte Ransomware-Binärdatei. Der KI-Agent selbst wird zur Verschlüsselungs-Engine, die die eigenen kryptografischen Funktionen der Datenbank nutzt und durch wenige, in einem Support-Ticket versteckte Textzeilen gesteuert wird.
Bei dem Angriff wurde keine Malware verwendet. Es war kein privilegierter Zugriff erforderlich. Der Agent ist die Waffe. Und das LLM war Mitautor der Payload.
Fall 3: Wenn Pässe ausgeführt werden: Passbearbeitung, ein zentraler Schritt bei der KYC-Überprüfung für Banken und Finanzinstitute. Diese Fallstudie zielt auf den Schritt der Feldextraktion ab – den Moment, in dem ein Dokument aufhört, ein Dokument zu sein, und zu Anweisungen wird, denen der Agent folgt. Ein manipuliertes Passbild bringt einen KYC-Extraktionsagenten dazu, Datensätze anderer Kunden preiszugeben, indem es die Lücke zwischen den Möglichkeiten eines Benutzers und denen des Agenten ausnutzt.
Fazit
Wir gehen davon aus, dass RTT die bestimmende Exploit-Klasse des Zeitalters der agentenbasierten KI ist. In dem Moment, in dem ein Agent nicht vertrauenswürdige Inhalte liest und Zugriff auf wichtige Tools besitzt, verlagert sich die Angriffsfläche an eine Stelle, die von herkömmlichen Abwehrmaßnahmen in der Regel nicht abgedeckt wird.
Unsere drei Fallstudien untermauern diese These. In keinem der Fälle wurde neuer Code eingeführt, es wurden keine Anmeldedaten gestohlen und es wurden keine Richtlinien verletzt. Die Angriffe erzeugten ausschließlich legitime Signale.
Vertrauen war die Angriffsfläche, während der Agent als Waffe diente. Gleichzeitig ist jede Ebene der traditionellen Verteidigung darauf ausgelegt, an anderer Stelle zu suchen. Die Schwachstelle liegt in der Architektur, nicht auf Modellebene. Neuere Modelle lehnen möglicherweise bestimmte Formulierungen in der Payload ab, doch solange ein Agent von Angreifern kontrollierte Inhalte liest und über den Tool-Zugriff auf relevante Daten verfügt, bleibt die Angriffsfläche bestehen.
Die nächste Frage lautet, ob bei der Entwicklung aktueller agentenbasierter Arbeitsabläufe diese Realität berücksichtigt wird.