GitLost: GitHub-KI-Agent zur Offenlegung privater Repositories verleitet

 (noma.security)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Noma Labs hat in GitHub Agentic Workflows die Schwachstelle GitLost entdeckt, eine indirekte Prompt Injection, durch die allein über ein Issue in einem öffentlichen Repository Daten aus privaten Repositories derselben Organisation in öffentlichen Kommentaren offengelegt werden konnten
  • Die Funktion kompiliert Markdown-Workflows zu YAML-Actions-Dateien; ein KI-Agent auf Basis von Claude oder GitHub Copilot liest Issues, ruft Tools auf und greift auf Repositories innerhalb der Organisation zu
  • Der verwundbare Workflow las beim Event issues.assigned den Title und Body eines Issues und antwortete per add-comment, während er Leserechte für öffentliche und private Repositories hatte
  • Angreifer mussten lediglich ein plausibel wirkendes Issue in einem öffentlichen Repository eröffnen – ohne Code, Zugriffsrechte oder Zugangsdaten; im Test wurden die Inhalte der README.md von poc und testlocal in einem öffentlichen Issue-Kommentar veröffentlicht
  • GitHubs Guardrails blockierten die Variante mit „Additionally“ nicht wie vorgesehen; bei agentenbasierter KI muss das Context Window selbst als Angriffsfläche betrachtet und nutzergesteuerter Inhalt von vertrauenswürdigen Anweisungen getrennt werden

Die von GitLost angegriffene Vertrauensgrenze

  • Noma Labs hat in GitHubs neuen Agentic Workflows eine Schwachstelle namens GitLost entdeckt
  • Wenn ein nicht authentifizierter Angreifer ein manipuliertes GitHub Issue in einem öffentlichen Repository derselben Organisation veröffentlichte, konnte der Agent dazu gebracht werden, Daten aus privaten Repositories der Organisation abzurufen
  • Die Angriffsmethode ist eine indirekte Prompt Injection, bei der bösartige Anweisungen in Inhalten versteckt werden, die der KI-Agent liest
  • Wenn die vom Angreifer versteckten Anweisungen vorrangig gegenüber den vom Betreiber beabsichtigten Anweisungen verarbeitet werden, können private Daten in einem öffentlichen Issue-Kommentar offengelegt werden, den jeder sehen kann

Funktionsweise von GitHub Agentic Workflows

  • GitHub Agentic Workflows ermöglichen Teams, Repository-Automatisierung in natürlicher Sprache zu schreiben
  • Workflows werden als Markdown-Dateien .md verfasst und zu GitHub-Actions-Dateien .yml im YAML-Format kompiliert
  • Zur Laufzeit arbeitet ein KI-Agent auf Basis von Claude oder GitHub Copilot innerhalb der konfigurierten Berechtigungen
    • GitHub Issues lesen
    • Tools aufrufen
    • Auf andere Repositories innerhalb der Organisation zugreifen

Bedingungen des verwundbaren Workflows

  • Die von Noma Labs bestätigte verwundbare Konfiguration wird problematisch, wenn öffentliche Issues und Agent-Berechtigungen zusammenkommen
    • Workflow-Trigger über GitHubs Event issues.assigned
    • Lesen von Title und Body des Issues
    • Veröffentlichen eines Kommentars mit dem Tool add-comment
    • Leserechte für andere Repositories innerhalb der Organisation
      • Öffentliche Repositories
      • Private Repositories
  • Angreifer benötigten keinen eigenen Code, keine Zugriffsrechte und keine Zugangsdaten
  • Die einzige Voraussetzung war, ein Issue in einem öffentlichen Repository einer Organisation zu eröffnen, die GitHub Agentic Workflow nutzt

Angriffsablauf

  • Die Forschenden erstellten ein plausibel wirkendes GitHub Issue, das so aussah, als käme die Anfrage nach einem Kundentermin vom VP Sales
  • Als das Issue zugewiesen wurde, wurde die Workflow Action ausgelöst; im Test funktionierte derselbe Ansatz auch mit einer anderen GitHub workflow action
  • Nachdem GitHub-Automatisierung das Issue zugewiesen hatte, veranlasste der durch das Event gestartete Workflow den Agenten, Repository-Inhalte abzurufen
  • Der Agent wurde dazu gebracht, die Inhalte der README.md folgender Repositories abzurufen
    • öffentliches Repository poc
    • privates Repository testlocal
  • Anschließend veröffentlichte der GitHub-Agent diese Inhalte als Issue-Kommentar im öffentlichen Repository, sodass sie für jeden lesbar waren

Umgehung der Guardrails mit „Additionally“

  • GitHub hatte begrenzte Guardrails, um dieses Szenario zu verhindern
  • Noma Labs testete, wie es Angreifer tun würden, wiederholt mehrere Varianten
  • Durch Hinzufügen des Keywords „Additionally“ trat ein unbeabsichtigtes Verhalten auf: Das Modell verweigerte die Ausgabe nicht, sondern strukturierte sie neu
  • Durch diese Umgehung funktionierten GitHubs Guardrails nicht wie beabsichtigt und konnten den Datenabfluss nicht verhindern

PoC und offengelegte Daten

Veränderte Sicherheitsannahmen bei agentenbasierter KI

  • Das Context Window eines Agenten ist zugleich Arbeitsbereich und Angriffsfläche
  • Alle Inhalte, die ein Agent liest, können als Waffe eingesetzt werden
    • Issues
    • Pull Requests
    • Kommentare
    • Dateien
  • Traditionelle Sicherheitsmodelle gehen häufig davon aus, dass Vertrauensgrenzen durch Code erzwungen werden
  • In agentenbasierten Systemen wird ein Teil der Vertrauensgrenze durch das Verhalten des Modells erzwungen
  • Da Modelle ihrem Wesen nach Anweisungen befolgen, wird Prompt Injection in agentenbasierter KI zu einer Schwachstellenkategorie, die für KI-Agenten eine ähnliche Rolle spielt wie SQL Injection für Webanwendungen
  • Für diesen Schwachstellentyp sind systematische Strategien und Abwehrmaßnahmen erforderlich

Empfohlene Schutzmaßnahmen und Offenlegungsprozess

  • Nutzergesteuerte Inhalte dürfen nicht als vertrauenswürdige Anweisungseingaben für KI-Agenten behandelt werden
  • Agent-Berechtigungen sollten auf den minimal notwendigen Umfang beschränkt werden
    • Agenten mit Zugriff auf mehrere Repositories werden zu besonders wertvollen Angriffszielen
  • Inhalte, die ein Agent öffentlich veröffentlichen darf, sollten begrenzt werden, etwa wenn er auf Issue-Inhalte antwortet
  • Nutzereingaben sollten vor der Übergabe an das Modell aus dem Anweisungskontext bereinigt oder isoliert werden
  • GitLost wurde GitHub verantwortungsvoll gemeldet; die Schwachstellendetails wurden mit Kenntnis von GitHub geteilt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Die Analogie, dass Prompt Injection bei agentischer KI dieselbe Rolle einnimmt wie SQL Injection bei Web-Apps, wirkt seltsam. Prompt Injection scheint für LLMs deutlich fataler zu sein als SQL Injection
    SQL Injection entstand dadurch, dass Nutzereingaben Teil eines Befehlsstrings wurden, der an die SQL-Engine übergeben wurde. Wenn bösartige Eingaben den aktuellen Befehl mit SQL-Syntax-Tokens beendeten und eigene SQL-Befehle anhängten, führte die Engine beides aus. Die Lösung bestand darin, feste, statische, vorab kompilierte Befehlsstrings wie Prepared Statements zu verwenden und beliebige Nutzereingaben ausschließlich als Daten zu behandeln
    Eine ähnliche Abschwächung bei Agenten wäre, feste Aktionen wie „Repo 1 lesen“ oder „Repo 2 lesen“ vorzusehen und Nutzereingaben nur als Daten zu verwenden, die auswählen, welche Aktion ausgeführt wird. Diese Technik nennt man bereits Menü. Der Wert von LLMs liegt im Kern darin, über Menüs hinauszugehen, während der Wert von SQL nicht über „vordefinierte Logik, die auf beliebige Daten angewendet wird“ hinausgehen muss

    • Stimmt. SQL Injection entstand, weil Nutzereingaben nicht als reine Daten, sondern als Teil des Befehls behandelt wurden; durch die Trennung beider wurde das Problem gelöst. Prompt Injection ist schwer zu vermeiden, weil die Nutzereingabe selbst als Befehl gedacht ist
    • Der Kern ist weniger „die Lösung sind Prepared Statements“, sondern Parameter Binding. Parameter werden getrennt von der SQL-Anweisung übermittelt, sodass Code und Nutzerdaten getrennt bleiben
      Agenten nur eingeschränkte Aktionen zu erlauben, behandelt lediglich einige Spezialfälle und trennt Code und Nutzerdaten nicht; es ist also nicht dasselbe Problem. Nur eingeschränkte Aktionen vorzusehen, ähnelt eher strengeren Datenbankberechtigungen. Wenn nur SQL erlaubt ist, das der Nutzer ohnehin ausführen darf, verliert auch SQL Injection weitgehend an Bedeutung
    • Es ist zwar dieselbe Art von Problem wie SQL Injection, aber der Schwierigkeitsgrad der Lösung ist nicht derselbe. Es können viel subtilere Probleme entstehen, als erklärende Analogie ist es aber ganz brauchbar
      Eine Auswahl über ein Menü ist eine Möglichkeit, doch der Bereich möglicher Handlungen kann breiter gestaltet werden. Gibt man ein E-Mail-Tool, kann es Spam an Kunden senden; sperrt man es darauf, nur Antworten zu erlauben, reduziert man den Schadensumfang. Wie bei Schwachstellen, bei denen Daten etwa über Bild-Rendering abfließen, muss auch Datenexfiltration begrenzt werden
    • Prompt Injection ist weder fatal noch eigentlich ein echtes Problem; sie legt eher ein zugrunde liegendes Problem der Sicherheitsarchitektur offen. Es ähnelt Social-Engineering-Angriffen auf Menschen
      Die Lösung ist ebenfalls dieselbe. Man setzt rollenbasierte Zugriffskontrolle nach dem Least-Privilege-Prinzip um und verlangt für wichtige Aktionen eine Administratorfreigabe. Dann ist das Schlimmste, was ein LLM allein tun kann, unangemessene Wörter auszugeben
    • Ich bin nicht sicher, ob das ein so tiefes Problem ist, wie alle denken. SQL Injection ist genauso gefährlich, weil sie unbegrenzten Zugriff auf alle Datenbankoperationen eröffnet, die der Query-Nutzer ausführen kann
      Eine Gegenmaßnahme sind Prepared Statements, eine andere ist, keinem Nutzer Zugriff auf die gesamte Datenbank zu erlauben. Ein Read-only-Nutzer sollte unabhängig von SQL Injection kein DROP TABLE ausführen können
      Dieser Agent hat unbegrenzten Lesezugriff und kein Konzept eines „Empfängers“ der Antwort. Bezieht man die Berechtigungen des Empfängers ein, ist es ziemlich einfach, den Lesezugriff automatisch verweigern zu lassen. Das ist nicht die einzige Lösung, aber es ist nicht schwer, sich Lösungen in diese Richtung vorzustellen
      Das Beispiel mit dem „Menü“ bedeutet auch, dass sich nichts geändert hat. Ob LLM oder menschlicher Mitarbeiter: Erlaubt ist nur eine kontrollierte, feste Menge von Aktionen. Die Freiheit liegt vor allem in der Formulierung, die Autorisierung ist eine feste Menge. Ich sehe nicht, warum es mehr als ein Menü sein muss

  • Ich verstehe nicht, warum das eine GitHub-Schwachstelle sein soll. Die Forscher haben dem Agenten Zugriff auf private Repositories gegeben und ihn in einem öffentlichen Repository Fragen beantworten lassen, also ist es natürlich möglich, private Informationen zu extrahieren.
    Das ist so, als würde man einen normalen CI-Job erstellen, der Zugriff auf Secrets hat, und ihn bei einem öffentlichen PR ausführen. Wenn man GitHub so konfiguriert, dass öffentlicher Code oder LLM-Anweisungen in einem Kontext ausgeführt werden, der auf Sensibles zugreifen kann, dann kommt es zu einem Leak. Das ist nicht GitHubs Schuld, sondern die der Person, die es so konfiguriert hat.

    • Sie scheinen angenommen zu haben, dass die Berechtigungen auf das Repository beschränkt sind, in dem die Frage gerade gestellt wird, und private Repositories nicht einschließen. Ich kann die Logik beider Seiten nachvollziehen.
    • GitHub macht es nicht einfach, Agentenzugriff sicher zu konfigurieren. Normale Access Tokens und App-Credentials bieten nicht genug granulare Kontrolle, um ihnen direkten Zugriff auf private Repositories zu geben.
      Selbst wenn man Token-Scopes streng setzt, ist der Zugriff auf öffentliche Repositories immer erlaubt, und damit bleibt zum Beispiel ein Exfiltrationspfad über Issues in öffentlichen Repositories bestehen. Um es sicher zu machen, müsste man das mit einem MITM-Proxy ergänzen, der strengere Kontrollen implementiert, als GitHub sie bereitstellt.
      GitHub Agentic Workflows dürften die offizielle primäre Lösung für solche Probleme sein, aber beim Sicherheitsmodell wie auch bei der sicheren Nutzbarkeit scheint noch Arbeit nötig zu sein.
      Details: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • Im Kern solcher Prompt-Injection-Angriffe steht das Problem, dass der Berechtigungsumfang des Agenten nicht richtig begrenzt wird. In diesem Fall könnte man je nach tatsächlicher Aufgabe des Agenten pro Repository separate Workflow-Agenten haben oder einen Agenten mit breiterem Repository-Zugriff, der aber nur von Benutzern auf einer Allowlist ausgelöst werden darf.
      Das ist auch mit öffentlicher Entwicklung vereinbar und erlaubt weiterhin, dass Externe öffentliche Issues öffnen, während es das Vertrauensniveau widerspiegelt, das man den einzelnen Benutzern entgegenbringt. Wenn man gründlich darüber nachdenkt, gibt es vermutlich noch mehr Optionen.
      Dafür braucht es technische Unterstützung für fein abgestuftes Scoping und Berechtigungen, und man muss sich die Zeit nehmen, abzuwägen, was man mit dem Agenten erreichen will und welche minimalen Berechtigungen und Funktionen dafür nötig sind.
      Ersteres wird wohl kommen. Die Nutzung von Agenten ist noch Wilder Westen. Spannend wird, welche Abstraktionen die Reibung reduzieren, wenn Menschen beim Entwurf von Agenten Scope und Berechtigungen finden und definieren müssen, und welche Interfaces beim Einschränken von Agentenfunktionen die Balance zwischen Granularität und Nutzbarkeit finden.
      Zweiteres ist schon immer das zentrale Hindernis beim Bau hochwertiger Software gewesen. Sich die Zeit zu nehmen, ordentlich nachzudenken und sauber zu implementieren, steht in direktem Widerspruch dazu, Agenten nach dem Motto „move fast and break things“ überall hineinzuwerfen.
    • Gibt es eine Möglichkeit, den Zugriff je agentischem Workflow aufzuteilen, sodass einer auf sensible Daten zugreifen kann und ein anderer nur auf öffentliche Daten? Ist der Standardumfang auf das aktuelle Repository beschränkt? Weist GitHub angemessen auf das Risiko hin, den Zugriff auf Daten privater Repositories mit agentischen Workflows zu kombinieren?
      Wenn die Antwort auf auch nur eine dieser Fragen „nein“ lautet, ist das ein Problem. Klassische GitHub Workflows haben ebenfalls jede Menge Privilege Escalation über PR-getriggerte Workflows, aber das ist ein anderes Thema.
    • Aus Berechtigungssicht ist ein LLM einfach ein dummes Terminal. Was man hier offenbar will, ist, auf Basis des Prompts spontan synthetische Berechtigungen zu erzeugen; das ist weniger eine Lösung mit „Prepared Statements“ als vielmehr „ich säubere Benutzer-SQL mit Regex“. Wir wissen bereits, wie das ausgeht.
      Die echte Lösung besteht darin, die Berechtigungssteuerungs-UI pro Prompt besser zu machen. So wie man „Websuche ja/nein“ auswählt, sollte man die Option „meine privaten Repositories einbeziehen“ einfach ein- und ausschalten können.

  • Es ist amüsant zu sehen, wie die Forscher mit einem einzigen Wort wie „Additionally“ die Guardrails umgehen, mit denen GitHub geprahlt hat. Das zeigt, dass der Versuch, innerhalb des Kontextfensters eines LLM eine starke Sicherheitsgrenze zu ziehen, zwangsläufig scheitern muss.
    Das Modell ist im Kern darauf ausgelegt, Anweisungen zu befolgen; wenn man Systemregeln und Benutzereingaben mischt, gewinnt also die neuere oder hartnäckigere Anweisung.

  • Warum steht im Abschnitt „Responsible Disclosure“ nicht, wann es behoben wurde und ob GitHub es anerkannt oder abgelehnt hat? Dort heißt es, GitLost sei GitHub verantwortungsvoll offengelegt worden und die Details würden in Kenntnis von GitHub geteilt; ist es also noch nicht behoben?

    • Das ist kein gewöhnlicher Software-Bug und lässt sich nicht auf dieselbe Weise „beheben“, so wie man auch nicht „beheben“ kann, dass ein normaler Support-Mitarbeiter hereingelegt wird. Die Antwort lautet, einem LLM nicht gleichzeitig Zugriff auf nicht vertrauenswürdige Eingaben und sensible Daten zu geben.
    • Ich frage mich, ob der Autor des Originalposts mit aktivierter Einstellung unten experimentiert hat. Es gibt buchstäblich eine Einstellung, die das verhindert. Ich würde gern wissen, ob diese Einstellung wegen dieses Berichts entstanden ist oder ob der Melder sie fahrlässigerweise nicht als Kommentar erwähnt hat.
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • Was soll denn behoben werden? Man hat dem LLM einfach gleichzeitig Zugriff auf private Daten und die Fähigkeit gegeben, öffentliche Kommentare zu lesen. Das ist schlicht eine Fehlkonfiguration.

  • Große Unternehmen wie Microsoft setzen wegen des Drucks der Investoren jetzt überall AI auf ihre Produkte, um behaupten zu können, sie seien AI-Unternehmen. Ähnlich wie Adobe es getan hat.
    Verbraucher werden solcher halbgarer AI-Integrationen zunehmend müde, und ich glaube, bald ist ein Kipppunkt erreicht.

    • Für mich ist es vorbei. Ich bin zu Forgejo gewechselt. Es ist hervorragend, und alles funktioniert besser.
      Ernsthaft: Wenn man hier und da klickt, reagiert alles sofort, und CI mit angeschlossenen Runnern läuft wunderbar. Die Dokumentation zum Einrichten der Runner könnte etwas klarer sein, aber abgesehen davon war alles extrem reibungslos.
    • Microsoft ist ein börsennotiertes Unternehmen. Welche Investoren üben Druck aus, GitHub mit unerwünschten AI-Funktionen zu ruinieren? In welchem Gremium passiert das?
    • Ich stimme zu, finde aber die AI-Produkte für Unternehmen ziemlich beeindruckend. Investoren und Verbraucher kennen sich nicht gut aus, und Mitarbeiter können nicht handeln.
      Der Umsatz existiert tatsächlich und ist beeindruckend, und er ersetzt verbraucher- und sitzplatzbasierte Umsätze. Der Markt senkt noch immer die SaaS-Multiples, und ich halte diese Einschätzung für richtig. Wenn man den Umsatz in den Quartalsberichten separat betrachtet, gibt es eine große Wachstumsgeschichte, die aus echter Effizienz entsteht.

  • Mir ist nicht klar, warum eine Action, die im Kontext eines öffentlichen Repositorys ausgeführt wird, Zugriff auf private Repositorys hatte. Wenn man sich den Workflow ansieht, scheint er ein github token zu verwenden, das normalerweise keine Rechte für private Repositorys gewährt.
    Oder hatte der Agent selbst somehow höhere Berechtigungen? Wenn ja, war der Agent falsch konfiguriert. Dass man nicht darauf vertrauen darf, dass ein Agent irgendetwas erzwingt, wissen wir bereits.

  • Dieser Beitrag liest sich wie Noma-Marketing. Ein niedlicher Name, ein Logo, ein Clickbait-Titel und sogar ein dramatischer Ton, der offenbar auf nicht technische Leser abzielt.
    Wenn man fragt, was die eigentliche Schwachstelle ist: Gibt man einem LLM private Daten und lässt beliebige Leute damit interagieren, können Daten durchsickern. Das ist allzu offensichtlich.

  • Solche Leute werden einem LLM Schreibrechte auf die gesamte Festplatte geben, destruktive Aktionen ausführen lassen und sich dann darüber beschweren.
    Wenn man nicht will, dass ein AI-Agent private Repositorys liest, sollte man ihm keinen Zugriff auf private Repositorys geben. Das ist kein Problem einer Rechteumgehung, sondern ein Prompt-Injection-Problem, und es lässt sich auf Agentenebene nicht zuverlässig lösen.

  • Entweder ist das bereits gelöst, oder GitHub hat es noch nicht gelöst, und in der Zwischenzeit werden böswillige Akteure versuchen, Schwachstellen in Repositorys auszunutzen.
    Bei der großen Zahl an Repositorys kann es mit einer Wahrscheinlichkeit größer als null zu Leaks kommen. Allerdings wird, ähnlich wie bei Betrugsfällen, fast niemand einen Leak zugeben.