GitLost: die reale Bedrohung von GitHub-Agenten, die private Daten durch ein einfaches Problem ausfiltern

Sicherheitsforscher haben eine praktische Möglichkeit gezeigt, private Daten von Organisationen durch ein neues Feature von GitHub zu filtern: Agenten, die "alnische Workflows" betreiben. Die Technik, getauft von den Entdeckern als GitLost, erfordert keine gestohlenen Anmeldeinformationen, vor dem Zugriff auf die Organisation oder den Betrieb von Servern: Es genügt, ein speziell erstelltes öffentliches Problem für einen Agenten zu öffnen, der von einem Token mit Leseberechtigung auf mehrere Repositorys autorisiert ist, böswillige Anweisungen im Text zu lesen und in offenen, offenen, sensiblen Inhalten aus privaten Repositorien zu veröffentlichen.

Das zugrunde liegende Problem ist kein Syntax-Versagen oder ein trivialer Fehler, der ein Patch einfach schließt. Es ist eine Folge des Betriebsmodells: Diese Mittel verbrauchen natürliche Sprache, die Daten und Aufträge mischen kann, und wenn sie auch mit weitreichende Anmeldeinformationen und einen öffentlichen Ausweg haben (z.B. um einen Kommentar zu veröffentlichen), erstellt es, was Experten den "lethal-Trifect" nennen: die Kombination von Zugriff auf private Daten, nicht vertrauenswürdige Einreise von außen und die Möglichkeit, draußen zu kommunizieren. In der Praxis besteht die Operation aus einer indirekten sofortigen Injektion: schädliche Anweisungen camouflaged in den Inhalt, den der Agent verarbeiten muss.

GitHub und andere Lieferanten hatten bereits Abschwächungsmassnahmen, wie Standard-Les-Only-Token, Input-Haltung und Erkennung in der Ausführungszeit der Ausgabe, bevor sie veröffentlicht wurde, einbezogen. Die Konzepttests haben jedoch gezeigt, daß auch minimale Textänderungen aus diesen Filtern gezogen werden können und daß Reaktivverteidigungsfunktion als letztes Resort, keine sichere Grenze. Wenn ein Agent mit Privilegien über Ressourcen handelt, die der Mensch nicht sieht, ist das Risiko nicht so sehr, was der Agent sagt und was er lesen und divulge kann.

Die Auswirkungen auf Unternehmen und Sicherheitsbeamte sind direkt. Ein orgweites Token, das die Lebensdauer von Entwicklern und Automatisierungsgeräten vereinfacht, kann ein Schlüssel werden, der es einem unsichtbaren Angreifer ermöglicht, Produktdesign, proprietären Code, interne Dokumentation oder Geheimnisse, die in privaten Repos wohnen zu zeichnen. Neben dem technischen Schaden besteht ein Ruf- und Regulierungsrisiko, wenn sensible Informationen in der Öffentlichkeit oder in den Händen Dritter enden.

Technische und organisatorische Maßnahmen, die dieses Risiko reduzieren, teilen ein Prinzip: die Anwendung des Prinzips der weniger Privilegien und die Hinzufügung menschlicher und technischer Barrieren zwischen dem Agenten und jeder möglichen öffentlichen Ausreise. In der Praxis ist es angebracht den Umfang der Token begrenzen an öffentliche Workflows für das zu bedienende spezifische Repository vergeben werden, bevorzugen ephemere Anmeldeinformationen (z.B. OIDC / kurzlebige Token) gegen langfristige persönliche Token und minimieren die Anzahl der Workflows, die unverified Author Content akzeptieren. Darüber hinaus sollte jeder Zugang zu öffentlichen Räumen der menschlichen Überprüfung und / oder Datenverlust-Prävention Pipelines (DLP) unterliegen, die nicht nur Text, sondern Artefakte und Metadaten untersuchen.

Es ist nicht genug, sich nur auf die Filterung von Inhalten zum Zeitpunkt der Veröffentlichung zu verlassen: Dies ist eine nützliche, aber zerbrechliche Verteidigung. Die strukturelle Minderung erfordert eine erneute Prüfung, wie die Anmeldeinformationen den Agenten und eine Präferenz für Architekturen erteilt werden, die den Zugang zu kritischen Daten isolieren. Zum Beispiel, um dem Agenten einen reduzierten Kontext durch Repliken von nur Metadaten oder maskierten Ansichten zu bieten, oder um mit Anmeldeinformationen zu reisen, die nur Operationen in einem Zweig oder in bestimmten Dateien erlauben, reduziert drastisch die Angriffsfläche.

Organisationen sollten auch Erkennung und Antwort implementieren: Aufzeichnen und Alarmzugriff von Agenten auf private Repositories, Audit Log der Token, die von Workflows verwendet und rotieren Anmeldeinformationen automatisch. Auf der politischen Ebene ist es ratsam, zu definieren, welche Arten von Problemen oder Autoren Automatisierungen mit sensiblen Token auslösen können und manuelle Überprüfungen für Workflows, die öffentliche Ausstiege erzeugen können, zu zwingen. Schließlich hilft die Notwendigkeit von Vereinbarungen und Garantien von Agenten und Modellanbietern über Rückverfolgbarkeit und Sicherheitskontrollen, systemisches Risiko zu bewältigen.

Die Gemeinschaft hat bereits ausführlich über schnelle Injektionsangriffe und ihre Grenzen diskutiert, und es gibt Ressourcen, um das technische Problem und die guten Sicherheitspraktiken zu vertiefen. Um das allgemeine Phänomen der schnellen Injektionen zu verstehen, wissenschaftliche Literatur wie arXiv Analyse von schnellen Injektionsangriffen ( arXiv: Prompt Injektionsangriffe) Für spezifische Maßnahmen zur Verwaltung von Anmeldeinformationen in GitHub erklärt die amtliche Dokumentation über die Erstellung und Nutzung von persönlichen Zugangstoken, wie man die Genehmigungen auflisten und drehen ( GitHub Guide to PAT), und die GitHub Actions-Seite bietet Kontext darüber, wie Workflows und ihre Berechtigungen funktionieren ( GitHub Aktionen)

Kurz gesagt, GitLost erinnert daran, dass die Sicherheit mit sprachbasierten Agenten nicht nur eine Frage der Modelle oder Filter ist: es ist ein architektonisches und organisatorisches Problem. Solange das Ökosystem keine Muster annimmt, die die Befehlsdaten eindeutig voneinander trennen und die permanenten Anmeldeinformationen von Agenten, die der Außenwelt ausgesetzt sind, minimieren, wird jeder Fluss, der private Datenlesung, unzuverlässige Texteinnahme und offene Veröffentlichung kombiniert, eine offene Tür für das nächste schädliche Problem bleiben.