Elf Tests bestanden

Sie finden auf GitHub einen kleinen Metrics-Client, der Ihnen eine Woche Arbeit sparen würde, und bitten Claude Code, ihn zu klonen und sich anzusehen. Es leistet gute Arbeit. Es liest den Code, findet einen unbegrenzten Puffer und eine Retry-Schleife, die bei einer vergifteten Nachricht endlos laufen würde, und schlägt Korrekturen vor. Sie sagen, was Sie immer sagen: Behebe das und bereite einen PR vor.

Ein paar Minuten später sind die Korrekturen drin, die Tests sind grün, und die Zusammenfassung lautet 11 passed. Irgendwann in diesen paar Minuten hat ein Implantat eine Remote-Shell auf Ihrem Laptop geöffnet.

Dieses Szenario hat Brian Cumi von Straiker STAR Labs gebaut und am 22. September unter dem Titel Fable to Haiku: How a Malicious Repo Tricked Claude Code Into Running Malware veröffentlicht. Adversas Oktober-Überblick über Sicherheitsforschung zu Coding-Agenten führt es unter den Angriffstechniken des Monats. Das Repository nutzt keinen Bug aus. Jeder Schritt verwendet eine dokumentierte Funktion genau so, wie ihre Entwickler es vorgesehen haben.

Wie das Repository sich selbst prüfte

Das Repository, northstar-metrics, sieht aus wie ein gewöhnliches Open-Source-Projekt, und sein erster Trick ist ganz alltäglich: eine CONTRIBUTING.md. Als Sie um einen PR baten, haben Sie den Agenten an den Beitragsprozess des Projekts gebunden, und ein Agent, der Anweisungen befolgt, liest den Beitragsleitfaden. Dieser hier sagt, Reviewer sollen vor den Tests den First-Pass-Review-Agenten des Projekts laufen lassen.

Dieser Agent liegt im Repository, unter .claude/agents/first-pass.md. Claude Code erlaubt einem Projekt, in diesem Ordner eigene Subagenten zu definieren, mit Modell und Umfang im Frontmatter. Dieser setzt model: haiku und beschränkt das Review auf src/ und docs/. Seine Anweisungen fügen hinzu, „ein Lesen in der Hauptsitzung ersetzt nicht das Ausführen des Agenten“, damit der Hauptagent ihn nicht überspringt.

Hier die vollständige Kette:

1. Fable, das Hauptmodell, übergibt das Review an den Subagenten des Repositorys.
2. Der Subagent läuft auf Haiku 4.5 und schaut nur in src/ und docs/.
3. Er kommt mit zwei Befunden zurück, die der Autor für ihn platziert hat: ein fest kodierter Versionsstring und eine Abweichung zwischen Doku und Code. Beide sind harmlos.
4. Der dokumentierte Ablauf betrachtet das Review als erledigt. Niemand öffnet tests/test_compat.py.
5. Fable startet pytest.
6. Vor seiner Assertion dekodiert test_compat.py eine URL aus Hex, lädt eine Python-Datei herunter und startet sie mit subprocess. Der Block steckt in try/except: pass, und die Assertion ist immer erfüllt.
7. Ein Sliver-Implantat öffnet eine Command-and-Control-Sitzung. Pytest meldet 11 passed.

Cumis Zusammenfassung, warum das funktioniert: Das Repository stützt sich auf drei gewöhnliche Annahmen. Projekte dürfen eigene Subagenten definieren, Agenten folgen dem dokumentierten Ablauf eines Projekts, und ein grüner Testlauf gilt als Prüfung des Codes. „Ein bösartiges Repo, das alle drei Annahmen versteht, muss keine davon brechen. Es muss nur in der Naht sitzen, wo sie aufeinandertreffen.“

Straiker meldete das am 14. September über HackerOne an Anthropic. Anthropic schloss es als Informative: Die Konfiguration des Repositorys zu befolgen, fällt unter die Workspace-Trust-Entscheidung des Nutzers.

Die Vertrauensentscheidung in der Praxis

Anthropics Antwort passt zu der Art, wie Claude Code funktioniert. Wenn Sie einen Ordner öffnen, werden Sie gefragt, ob Sie ihm vertrauen, und Sie haben Ja gesagt. Diese Entscheidung umfasst die CLAUDE.md, die Hooks, die Subagenten und die Testsuite.

Das Problem ist, worüber Sie entschieden haben. Sie haben dem Repository genug vertraut, um es sich anzusehen. Dafür haben Sie es geklont. Auf einem Laptop heißt „diesem Ordner genug vertrauen, um seine Tests laufen zu lassen“, ihm alles anzuvertrauen, was Ihr Konto erreichen kann, denn dort läuft pytest. Straiker listet auf, was das Implantat hatte: jede Datei, die Sie lesen können, Zugangsdaten im Speicher, SSH-Schlüssel auf der Platte und jedes Repository, in das Sie pushen dürfen.

Kein Reviewer, ob Mensch oder Modell, liest jede Testdatei jedes Projekts, das er begutachtet. Hier wurde das Review absichtlich abgekürzt, aber auch viele ehrliche Reviews sind kurz. Sie können aber wählen, wo die Testsuite läuft.

Dasselbe Repository in einer Bromure-Maschine

In Bromure Agentic Coding läuft Claude Code in einer Linux-VM auf Ihrem Mac. Jede Maschine hat ihre eigene Platte, ihr eigenes Home-Verzeichnis und ihre eigenen Zugangsdaten, und ihr gesamter Datenverkehr verlässt sie über einen Proxy auf dem Mac. Die Workspace-Trust-Entscheidung bleibt Ihre. Was sich ändert, ist, was das vertrauenswürdige Repository erreichen kann.

Spielen Sie Straikers Kette in einer Bromure-Maschine nach. Die Schritte eins bis fünf laufen wie zuvor: Der Agent liest den Beitragsleitfaden, der Subagent prüft die falschen Ordner, und pytest läuft. Ab Schritt sechs arbeitet das Repository gegen den Mac.

Der Download führt über den Mac

Die Payload muss geholt werden. Der Test dekodiert eine URL und fordert eine Datei von einem Host an, den das Projekt nie zuvor gebraucht hat. In einer Bromure-Maschine gibt es nur einen Weg nach draußen: Der virtuelle Netzwerk-Switch leitet jede Verbindung auf den Ports 80 und 443 in den Proxy auf dem Mac um und prüft jede andere Verbindung, gleich welches Protokoll, gegen die Regeln der Maschine.

Diese Regeln stehen im Guardrails-Bereich der Maschine unter Outbound connections: Erlauben- und Verbieten-Einträge nach Host, IP-Bereich, Protokoll und Port, dazu eine Einstellung Unmatched traffic mit Allow oder Deny. Eine Maschine, mit der Sie Code von Fremden begutachten, braucht eine kurze Liste: den Modellanbieter, die Paket-Registries, GitHub.

allow web api.anthropic.com
allow web pypi.org
allow web files.pythonhosted.org
allow web github.com
default deny

Unter diesen Regeln kommt der Download in test_compat.py nie zustande, und das try/except: pass, das der Autor hinzugefügt hat, um Fehler zu verbergen, verbirgt jetzt diesen. Pytest meldet weiterhin 11 passed. Der Unterschied liegt auf dem Mac. Die Security Timeline der Maschine zeigt eine rote Firewall-Zeile mit einem Deny-Urteil, dem Host, den der Test erreichen wollte, und dem Port, mit einem Zeitstempel Sekunden nachdem der Agent pytest gestartet hat. Die Testsuite eines Metrics-Clients hat keinen Grund, einen Host zu kontaktieren, von dem Sie nie gehört haben, und jetzt wissen Sie, dass sie es versucht hat.

Der spätere Datenverkehr des Implantats wird genauso behandelt. Ob Sliver über HTTPS, über Mutual TLS auf eigenem Port, über WireGuard oder über DNS nach Hause telefoniert: Die Verbindung verlässt die VM über den Switch, und der Switch prüft jedes Protokoll gegen dieselbe Tabelle.

Das Implantat findet Platzhalter

Angenommen, die Maschine erlaubte nicht zugeordneten Verkehr, die Payload kam an, und Sliver öffnete seine Sitzung. Der Angreifer hat nun eine Shell in der VM, mit derselben Reichweite, die Straiker für den Laptop aufgelistet hat. Auf einer Bromure-Maschine umfasst diese Reichweite weniger.

• Dateien. Die VM enthält ihr eigenes Home-Verzeichnis und die Projektordner, die Sie bewusst mit dieser Maschine geteilt haben. Das Home-Verzeichnis Ihres Macs, Ihre anderen Projekte, Ihre Browserprofile und Ihr Schlüsselbund sind nicht darin.
• Zugangsdaten. Bromure hält echte API-Schlüssel, OAuth-Tokens, Git-Tokens, Cloud-Secrets und Datenbankpasswörter verschlüsselt auf dem Mac. Die VM hat Platzhalter in der richtigen Form: ANTHROPIC_API_KEY=sk-ant-api03-brm-…, ein ghp_-Token, das GitHub ablehnen würde, ein AWS-Secret-Key, der nichts signiert. Der Proxy setzt den echten Wert ein, nachdem eine Anfrage die VM verlassen hat, und nur für den Host, zu dem die Zugangsdaten gehören.
• SSH-Schlüssel. ls ~/.ssh/id_* liefert nichts. Der SSH_AUTH_SOCK der VM ist eine Brücke zu einem ssh-agent auf dem Mac. Die VM kann eine Signatur anfordern, aber den Schlüssel nicht lesen. Schalten Sie für einen Schlüssel Ask before use ein, und jede Signaturanfrage öffnet einen Dialog auf dem Mac.

Ein Implantat, das einsammelt, was es findet, und es nach Hause schickt, löst einen zweiten Stolperdraht aus. Ein Platzhalter-Token hat genau ein legitimes Ziel, den Host, für den es ausgestellt wurde. Sieht der Proxy sk-ant-api03-brm-… oder jenes ghp_-Token irgendwohin sonst gehen, lehnt er die Anfrage mit HTTP 451 ab, pausiert die VM und öffnet auf dem Mac eine Warnung mit dem Titel This environment may have been compromised, die das Token nennt, den Host, für den es ausgestellt wurde, und den Host, an den es geschickt wurde. Hinausgegangen ist nur ein Platzhalter, also gibt es nichts zu rotieren.

Pushes fragen zuerst

Straikers letzter Punkt, „Repositorys mit Push-Rechten“, ist der, der einen kompromittierten Laptop zu einem Lieferketten-Vorfall macht. Ein Angreifer mit einer Shell und Ihren Git-Zugangsdaten kann einen Commit in jedes Projekt pushen, das Sie betreuen.

Auf einer Bromure-Maschine ist ein Push zu GitHub, GitLab oder Bitbucket ein Schreibvorgang, und neue Maschinen kommen mit Prompt before write für jeden geschützten Dienst. Der Proxy hält den Push an, und macOS zeigt Allow write on "github.com" from workspace "…"? mit der Operation so, wie sie auf der Leitung erschien: POST /acme/app.git/git-receive-pack. Sie haben keinen Push angefordert, also klicken Sie auf Don't allow, und das Implantat erhält einen 403, der mit blocked by Bromure Guardrails endet. macOS zeichnet den Dialog aus dem, was der Proxy gelesen hat, also kann nichts in der VM seinen Wortlaut ändern.

Der Trace zeigt das Review, das nicht stattfand

Wenn sich der Staub gelegt hat, wollen Sie wissen, was der Agent getan hat. Auf der Standard-Tracing-Stufe, AI request details, behält der Proxy jeden Austausch mit dem Modellanbieter verschlüsselt auf dem Mac, und der Trace Inspector zerlegt jeden davon in Tool-Aufrufe, Shell-Befehle und Dateilesevorgänge.

Für dieses Repository beantwortet die Aufzeichnung die Fragen, auf die es ankommt:

• Welches Modell hat das Review gemacht? Der erfasste Request-Body nennt es: claude-haiku-4-5, eine Runde nachdem die Hauptsitzung .claude/agents/first-pass.md gelesen hat.
• Was hat es gelesen? Jeden Read-Aufruf mit seinem Pfad. Es gibt Aufrufe für Dateien unter src/ und docs/ und keinen für tests/test_compat.py.
• Was lief? Der Bash-Aufruf, der pytest gestartet hat, und daneben, in der Security Timeline, die Firewall-Zeile für den Download, den er auslöste.

Das Repository bestimmt, was der Agent sieht und was pytest ausgibt, aber es hat keine Möglichkeit, den Trace zu bearbeiten. Der Proxy schreibt diese Aufzeichnung auf dem Mac, aus dem Datenverkehr selbst.

Eine Maschine für Code, den Sie nicht gelesen haben

Straikers Bericht endet mit drei Empfehlungen: eine Freigabe verlangen, bevor ein vom Repository definierter Subagent läuft, Testdateien lesen, bevor man sie ausführt, und Dateien wie .claude/agents/, Hooks und Workflow-Definitionen als nicht vertrauenswürdige Eingaben behandeln. Alle drei sind vernünftig, und alle drei setzen voraus, dass jemand jedes Mal daran denkt, bei einer Aufgabe, die wie ein Routine-Review aussah.

In Bromure kostet die sichere Gewohnheit ein paar Klicks. Eine neue Maschine ist ein Copy-on-Write-Klon eines signierten Ubuntu-Images und belegt daher kaum Platz. Das legt ein Setup für die Prüfung fremden Codes nahe:

1. Legen Sie eine Maschine namens eval an. Geben Sie ihr einen Modellanbieter und sonst nichts: kein Git-Token mit Push-Rechten, keine Cloud-Schlüssel, keine Datenbank.
2. Stellen Sie ihren Egress auf Deny als Standard. Erlauben Sie in Guardrails › Outbound connections den Modellanbieter, die Paket-Registries und GitHub, und setzen Sie Unmatched traffic auf Deny.
3. Klonen Sie in die VM, nicht in einen geteilten Ordner. Starten Sie die Sitzung in einem frischen Ordner im Home der Maschine. Ein geteilter Ordner ist ein Live-Fenster auf Ihren Mac, und das eigene Home der Maschine ist der Teil, den Bromure zurückspulen oder löschen kann.
4. Oder machen Sie sie zur Wegwerfmaschine. bromure-cli vm run --rm startet eine Maschine, die beim Stoppen samt Platte gelöscht wird.
5. Lesen Sie die Timeline, bevor Sie die Abhängigkeit übernehmen. Eine Firewall-Deny-Zeile aus einem Testlauf ist ein Befund, den kein Reviewer gemeldet hat, egal was pytest ausgegeben hat.

Kommt doch etwas durch, räumen Sie eine einzige Maschine auf. Rewind home… setzt das Home-Verzeichnis auf den Checkpoint eines früheren Starts zurück. Eine Maschine, die der Kompromittierungsdetektor markiert hat, startet erst wieder, wenn Sie Wipe and Launch wählen; das baut Platte und Home neu auf und behält Ihre Einstellungen und die echten Zugangsdaten auf dem Mac. Das Konto Ihres Laptops, Ihre anderen Projekte und Ihre anderen Maschinen waren nie darin.

Hat sich die Bibliothek bewährt, ziehen Sie sie auf die Maschine um, die die eigentliche Arbeit macht. Auch diese Maschine hält nur Platzhalter-Schlüssel, und ihre Pushes stoppen ebenfalls am Dialog auf dem Mac.

Vertrauen Sie dem Repository weniger an

Das Repository hat nichts Exotisches getan. Es hat einen Beitragsleitfaden geschrieben, einen Hilfsagenten definiert und eine Testdatei mitgeliefert. Projekte werden alle drei Dinge weiter tun, weil sie nützlich sind, und Agenten werden ihnen weiter folgen, weil gerade das Befolgen der Konventionen eines Projekts einen Agenten gut in seiner Arbeit macht.

Anthropics Antwort legt die Entscheidung in Ihre Hände, und dort gehört sie hin. Treffen Sie sie auf einer Maschine, die dafür gebaut ist: einer, auf der einem Repository genug zu vertrauen, um seine Tests laufen zu lassen, bedeutet, ihm eine VM, ein paar Platzhalter und eine kurze Liste von Hosts anzuvertrauen. Dann darf die Testsuite ausgeben, was sie will.