Executive summary
Das Silverfort Ein Forschungsteam hat herausgefunden, dass die Art und Weise, wie Anthropic die Anmeldeinformationen der Claude Code CLI unter macOS speichert, es jedem Prozess, der mit den Berechtigungen des Benutzers ausgeführt wird, leicht macht, die Anmeldeinformationen des Anthropic-Kontos und damit auch die Anmeldeinformationen aller verbundenen MCP-Server zu stehlen. Ein einziger unbemerkter Lesevorgang liefert das gesamte Paket, das ein Angreifer dann von einem anderen Rechner aus wiedergeben kann, um sich als der Benutzer auszugeben.
Der macOS-Schlüsselbund verfügt über einen sicheren Speichermechanismus, der die erneute Eingabe des Passworts oder die biometrische Bestätigung erfordert, bevor ein Geheimnis an einen anfragenden Prozess freigegeben wird. Claude Desktop nutzt dies korrekt. Versucht ein anderer Prozess auf die gespeicherten Anmeldeinformationen zuzugreifen, fordert macOS den Benutzer zur erneuten Authentifizierung auf. Claude Code CLI hingegen nicht. Die Implementierung ermöglicht es jedem Benutzermodus-Prozess, die Anmeldeinformationen ohne erneute Authentifizierungsaufforderung abzurufen. Wir werden dies in diesem Blogbeitrag genauer erläutern.
Technisch gesehen handelt es sich hierbei nicht um eine Sicherheitslücke, sondern um einen Implementierungsfehler: Anmeldeinformationen, die eine erneute Authentifizierung erfordern sollten, werden nicht erneut authentifiziert. Die Ausnutzung erfordert keine ausgefeilten Techniken, außer dem Standardverfahren, Code als Benutzer auszuführen – eine deutlich geringere Hürde als eine Rechteausweitung. Der Designfehler betrifft alle macOS-Benutzer, die Claude Code CLI verwenden (nicht die Desktop-Version und nicht die Benutzer der Windows-/Linux-CLI, da diese auf dateibasierte Speicherung angewiesen sind, bei der bestehende Antiviren-/EDR-Heuristiken bereits Manipulationen erkennen sollten).
Das Ergebnis: Wenn Schadcode unter einem Benutzerkonto ausgeführt wird, kann er unbemerkt Claude-Anmeldeinformationen auslesen – ohne Rechteausweitung, ohne Passwortabfrage, ohne Warnung – und sich lateral ausbreiten, um auf MCP-Server zuzugreifen. Unter macOS ist die Schlüsselbundverwaltung im Vergleich zur dateibasierten Speicherung die bessere Methode. Da die Claude Code CLI jedoch den erneuten Authentifizierungsschritt überspringt, geht dieser Vorteil verloren, und keine bestehende Antiviren-Heuristik überwacht dies, wie es auf anderen Plattformen für Dateizugriffsheuristiken existiert. Wird ein Endpunkt übernommen, erhält ein Angreifer Zugriff auf das Anthropic-Konto des Benutzers und alle verbundenen MCP-Server und kann alles beeinflussen, was diese Server steuern: den Quellcode des Unternehmens auf GitHub, die Wissensdatenbank in Atlassian oder andere sensible MCP-Konnektoren.
Silverfort Am 25. Juni meldete Anthropic diesen Befund über HackerOne gemäß deren Richtlinie zur verantwortungsvollen Offenlegung. Anthropic antwortete umgehend und bestätigte nach Rücksprache mit dem Team, dass die Verschärfung der Zugriffskontrolle für Keychain-Einträge als Sicherheitsmaßnahme verfolgt wird und als „eine sinnvolle Maßnahme zur Stärkung der Sicherheitsarchitektur“ angesehen wird. Anthropic erhob keine Einwände. Silverfort Die Forschungsergebnisse veröffentlichen.
Leitfaden für Verteidiger
Bis dieses Problem behoben ist, sollten Organisationen, die Claude Code CLI auf macOS verwenden, eine Warnung erstellen, sobald dasselbe Token auf verschiedenen Rechnern verwendet wird. Über die herkömmliche Erkennung und Reaktion hinaus sollten Unternehmen eine Identitätssicherheitsplattform in Betracht ziehen, die die Verwendung statischer oder temporärer Anmeldeinformationen kontrollieren und kennzeichnen kann, wenn dasselbe Token von zwei verschiedenen Rechnern verwendet wird – ein starkes Indiz für die Verwendung gestohlener Anmeldeinformationen. Sicherheitsteams sollten auf anomale oder unerwartete Prozesszugriffe auf den vom Claude Code CLI verwendeten Keychain-Eintrag achten. Ungewöhnliche Zugriffsmuster auf diesen Anmeldeinformationsspeicher sind ein aussagekräftiger Indikator für eine mögliche Kompromittierung und sollten als Auslöser für eine Untersuchung behandelt werden.
Hintergrund
KI-Programmieragenten besitzen nun echte Zugangsdaten. Um ihre Arbeit zu erledigen, melden sie sich an und speichern ein Token auf dem Rechner. Claude Code CLI Auch Claude bildet hier keine Ausnahme. Beim Start meldet sich das Programm mit einem OAuth-Paket an: einem kurzlebigen Zugriffstoken und einem langlebigen Aktualisierungstoken. Das Aktualisierungstoken ist der Teil, der Ihnen Sorgen bereiten sollte. Es kann gegen neue Zugriffstoken eingetauscht werden, bis es widerrufen wird. Es handelt sich also nicht um eine temporäre Sitzung, sondern um einen permanenten Kontozugriff auf einem Laptop.
Wo sich das OAuth-Bundle befindet, hängt von Ihrem Betriebssystem ab. Auf zwei der drei Plattformen (Linux und Windows) ist es eine einfache Datei auf der Festplatte. Unter macOS wird es im Schlüsselbund des Systems gespeichert – zunächst naheliegend, aber mit einem Haken: Standardmäßig ist das Element an das Programm gebunden, das es erstellt hat. Hier dient dies der Sicherheit eines Tools, das von jedem Prozess ausgeführt werden kann. Die Sperre ist also vorhanden, wird aber nie aktiv, und jeder Prozess unter Ihrem Benutzerkonto erhält die Tokens, ohne dass der Benutzer sein Passwort erneut eingeben muss.
Wir werden die Anmeldeinformationen der Claude Code CLI auf allen drei Plattformen verfolgen, einen macOS-Fehler genauer untersuchen, einen ressourcenschonenden Trick zur Wiederverwendung eines gestohlenen Pakets vorstellen und schließlich die Frage beantworten, die sich jedes Unternehmen stellen wird: Ist das neue Claude Apps Gateway Macht das das irrelevant? Die kurze Antwort lautet: Nein.
Geheimnisse in einer Akte klingen schlimmer, aber es ist diejenige, die man sich ansehen kann.
Unter Linux und Windows werden die Anmeldeinformationen in einer unverschlüsselten JSON-Datei gespeichert, ohne dass ein Keystore des Betriebssystems verwendet wird. Das klingt zwar nach einem weniger sicheren Ansatz, doch eine Anmeldeinformationsdatei auf der Festplatte ist ein Problem, mit dem Sicherheitsexperten bereits vertraut sind. Es handelt sich um ein klassisches Angriffsziel, und Endpoint-Tools wie Antivirenprogramme und EDR-Lösungen können Prozesse überwachen, die auf eine Datei mit Tokens zugreifen. Es gibt einen bekannten Ort für eine Kontrollmaßnahme und einen konkreten Anlass für eine Warnung. Unter macOS entfällt dieses Sicherheitsnetz, wie wir sehen werden.
Die Dokumentation der Claude Code CLI gibt an, wo sich die Datei befindet:
„Unter Linux werden Anmeldeinformationen gespeichert in
~/.claude/.credentials.jsonmit Dateimodus 0600.“„Unter Windows werden die Anmeldeinformationen gespeichert in
%USERPROFILE%\.claude\.credentials.jsonund übernehmen die Zugriffskontrollen Ihres Benutzerprofilverzeichnisses, wodurch die Datei standardmäßig auf Ihr Benutzerkonto beschränkt ist.“
Ein kleiner Haken: CLAUDE_CONFIG_DIR Verschiebt diese Datei an einen anderen Ort, so dass Erkennungsregeln, die den Pfad fest codieren, diese Installationen nicht erfassen.
In dieser Datei befinden sich alle relevanten Informationen: ein OAuth-Zugriffstoken (sk-ant-oat…), das langlebige Aktualisierungstoken (sk-ant-ort…), ein Ablaufdatum (expiresAt) und die Token-Bereiche. Im selben Speicher befinden sich auch alle MCP-Server-OAuth-Token und Plugin-Geheimnisse, die Sie verbunden haben. Das Aktualisierungstoken ist das wichtigste, da ein einmaliges Auslesen dauerhaften Kontozugriff gewährt. Unter Linux und Windows sollten Sie folgende Punkte beachten:
- Dateiintegritätsüberwachung. Behandeln
~/.claude/.credentials.json(Und dieCLAUDE_CONFIG_DIRVariante) als sensibles Objekt. Die gewünschte Warnung wird bei einem Lese- oder Öffnungsvorgang durch einen beliebigen Prozess ausgelöst, der nicht die Claude-Binärdatei ist. Unter Linux kann dies mit einem auditd-Watch erreicht werden (auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_creds) oder eBPF-Telemetrie (offen). Unter Windows verwenden Sie die Objektzugriffsüberwachung (Ereignis-ID 4663) mit einer SACL oder die EDR-Dateilese-Telemetrie. - Berechtigungsabweichung. Die Linux-Datei sollte unter folgendem Pfad bleiben:
0600Wenn es für eine Gruppe oder die ganze Welt verständlich wird, ist das an sich schon ein Warnsignal. - Inhaltssignaturen. Die Präfixe sk-ant-oat (Zugriff) und sk-ant-ort (Aktualisierung) dienen DLP und AV als Indikatoren für Anmeldeinformationen. Kennzeichnen Sie diese in Dateien außerhalb des Konfigurationsverzeichnisses, in Archiven, in der Zwischenablage und im ausgehenden Datenverkehr. Ein Treffer des Refresh-Token-Präfixes ist besonders schwerwiegend.
- Der Identitätsaspekt. Das beste Signal befindet sich gar nicht am Endpunkt. Ein Token, das zuerst auf einem Host auftaucht und dann auf einem anderen, ist ein typisches Anzeichen für Diebstahl. Achten Sie darauf, ob dieselbe OAuth-Sitzung kurz nach einem lokalen Zugriff von einem neuen Gerät, Standort oder einer anderen IP-Adresse auftaucht. Genau dafür ist eine Plattform zur Erkennung von Identitätsbedrohungen da.
Bewahren Sie die Begleitdatei auf. ~/.claude.json, auch auf Ihrem Radar. Es ist nicht der geheime Shop, aber er enthält die Kontoidentität (oauthAccount,userIDDas ist die andere Hälfte einer Arbeitssitzung. Mehr dazu im nächsten Abschnitt.
Das Schloss, das nicht schließt: Unter macOS ist der Schlüsselbund die richtige Idee – muss aber korrekt implementiert werden.
macOS bricht mit diesem Muster, indem die CLI ihre Anmeldeinformationen im Schlüsselbund anstatt in einem anderen Speicher ablegt. .credentials.json Datei. Die Dokumentation ist eindeutig:
„Unter macOS werden die Anmeldeinformationen im verschlüsselten macOS-Schlüsselbund gespeichert.“
Das ist der richtige Ansatz. Ein verschlüsselter, vom Betriebssystem geschützter Speicher ist einer einfachen Datei immer überlegen. Ein Keychain-Eintrag ist jedoch nur so sicher wie die ihm zugeordnete Zugriffssteuerungsliste (ACL), und genau hier liegt die Schwäche dieses speziellen Eintrags.
Claude Code CLI erstellt seinen Keychain-Eintrag durch einen Shell-Aufruf an /usr/bin/security add-generic-passwordEs werden keine Zugriffssteuerungsargumente übergeben: weder -T, um einer bestimmten Anwendung zu vertrauen, noch -A, um beliebige Anwendungen zuzulassen. Das Element erbt daher die Standard-Zugriffssteuerungsliste (ACL) des Schlüsselbunds. Die Manpage „security(1)“ von macOS beschreibt die Funktionsweise dieser Standardeinstellung.
„Standardmäßig wird der Anwendung, die ein Element erstellt, der Zugriff auf dessen Daten ohne Warnung gewährt. Sie können diesen Standardzugriff entfernen, indem Sie explizit einen leeren Anwendungspfad angeben: -T “”.
Auf diesem Codepfad ist die Anwendung, die das Element erstellt, folgende: /usr/bin/security selbst. Der auf dem Artikel hinterlegte vertrauenswürdige Leser ist also /usr/bin/security, sitzend in der apple-toolDie Partition, die macOS für Apples eigene signierte Tools reserviert. Genau diese Standardeinstellung ist das Problem. /usr/bin/security ist ein universelles, von Apple signiertes Befehlszeilentool, das von jedem Prozess unter Ihrem Account ohne besondere Berechtigungen aufgerufen werden kann. Eine ACL, deren einziger vertrauenswürdiger Leser der ist security Das Tool wird von jedem Prozess als zufrieden angesehen, der Folgendes ausführt: security Das Werkzeug, also jeder Prozess auf dem Rechner, ist gemeint. Die Zugriffskontrollliste (ACL) soll eigentlich festlegen, welches Programm das Geheimnis lesen darf. In der Praxis hat sie jedoch keine Wirkung, da jedes Programm es lesen kann, indem es eine Standard-Binärdatei dazu auffordert.
Das Ergebnis ist eine einzeilige, stumme Lektüre:
security find-generic-password -s "Claude Code-credentials" -a "$USER" -w
Keine Touch ID, keine Anmelde- und Passwortabfrage, keine Rechteerweiterung. Die vollständigen Anmeldeinformationen werden im JSON-Format zurückgegeben: das Zugriffstoken, das langlebige Aktualisierungstoken und alle MCP- oder Plugin-Geheimnisse, die dieses Element gemeinsam nutzen.
Anthropic macht das mit Claude Desktop bereits richtig, warum also nicht auch mit Claude Code CLI?
Der deutlichste Beweis dafür, dass es sich hier um eine Implementierungsentscheidung und nicht um eine macOS-Beschränkung handelt, ist, dass Anthropic dies in Claude Desktop bereits korrekt umsetzt. Claude Desktop läuft auf demselben Betriebssystem, für denselben Benutzer und schützt dieselbe Art von Geheimnis. Es verwendet hierfür Electron safeStorage, und das Design verdient eine genauere Erläuterung, da es sich vom Design der Kommandozeilenschnittstelle (CLI) unterscheidet. safeStorage Electron speichert einen Verschlüsselungsschlüssel im Schlüsselbund und die eigentlichen Token als Chiffretext in einer Datei auf der Festplatte. Die Electron-Dokumentation beschreibt, wie dieser Schlüssel geschützt wird:
„Die Verschlüsselungsschlüssel Ihrer App werden im Schlüsselbund so gespeichert, dass andere Anwendungen sie nicht ohne Zustimmung des Benutzers laden können.“
Der Keychain-Eintrag, der diesen Schlüssel enthält, listet in seiner ACL nur die signierte Claude-App auf, und seine Partition ist dem Entwicklerteam von Anthropic zugeordnet, sodass ein Sicherheitszugriff von jedem beliebigen Ort aus unmöglich ist. Andernfalls wird das Anmeldepasswort angefordert.Der auf der Festplatte gespeicherte Geheimtext ist ohne den Schlüssel nutzlos, und der Schlüssel wird ohne diese Aufforderung nicht ausgegeben.
Die beiden Designs sehen ähnlich aus, verhalten sich aber völlig unterschiedlich. Die CLI speichert die Tokens im Keychain mit einer ACL, die es jedem Prozess erlaubt, sie zu lesen. Claude Desktop speichert hingegen nur einen Schlüssel im Keychain, bindet diesen an seine eigene Signatur und bewahrt die verschlüsselten Tokens in einer Datei auf, die für sich genommen nutzlos ist. Gleiches Betriebssystem, gleicher Benutzer, gleiche Art von Geheimnis: Das eine kann von jedem Prozess unbemerkt gelesen werden, während das andere die Zustimmung des Benutzers erfordert. Der Unterschied liegt darin, wie der Keychain-Eintrag erstellt wird und was er schützt.
Ursache: Die CLI übergibt die Elementerstellung an /usr/bin/security Anstatt die native Keychain Services API zu verwenden, um das Element an die eigene Codesignatur der Claude-Binärdatei zu binden (was dem Standardmuster von Claude Desktop entspricht), kann das Sicherheitstool ein Element nicht an das aufrufende Programm binden. Dies ist nur über die native API möglich. Es handelt sich dabei um Sicherheitslücken (CWE-732 – falsche Berechtigungszuweisung für eine kritische Ressource und CWE-522 – unzureichend geschützte Anmeldeinformationen).
Die Sitzung wird neu erstellt, ohne dass eine einzige Konfigurationsdatei geändert wird.
Das Auslesen des Tokens ist nur die halbe Miete für eine Identitätsfälschung. Um sich als Opfer auszugeben, muss die Claude Code CLI außerdem wissen, wer angemeldet ist; diese Information befindet sich normalerweise im oauthAccount Block innerhalb ~/.claude.jsonDer naheliegende Schritt wäre, auch diese Datei zu stehlen. Es gibt jedoch eine sauberere Methode, die deutlich weniger Spuren hinterlässt, und es lohnt sich, diese genauer zu betrachten, denn die naheliegende Erklärung für die Funktionsweise ist falsch.
Das Rezept auf dem Rechner des Angreifers:
1. Exportieren Sie das gestohlene Zugriffstoken und führen Sie Claude einmal aus:
export ANTHROPIC_API_KEY=<access-token>
claude
2. Ausgang, dann unset ANTHROPIC_API_KEY.
3. Verstecke das gesamte gestohlene Bündel in deinem eigenen Schlüsselanhänger:
security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'
4.Laufen claude Sie sind nun wieder als Opfer angemeldet.
Und hier kommt der kontraintuitive Teil: Die Umgebungsvariable ist nicht das, was Sie anmeldet. sk-ant-oat… Der in ANTHROPIC_API_KEY gespeicherte Wert wird gemäß der Dokumentation zur Authentifizierungspriorität der Claude Code CLI als X-Api-Key-Header ausgegeben. Dies ist der falsche Header und auch der falsche Token-Typ, da ein OAuth-Zugriffstoken kein Console-API-Schlüssel ist. Es authentifiziert Modellaufrufe überhaupt nicht.
Wozu dient der Export? Die Reihenfolge der Operationen ist entscheidend. Beim ersten Durchlauf, bei dem das gestohlene Zugriffstoken exportiert wird, wird die Kontoidentität des Opfers in ~/.claude.json geschrieben, sodass der Angreifer diese Datei nicht kopieren muss. Anschließend wird die Variable entfernt und das vollständige Paket inklusive Refresh-Token im Schlüsselbund abgelegt. Die Dokumentation beschreibt dies. unset ANTHROPIC_API_KEY Als Ausweichmöglichkeit für das Abonnement dient die letzte Ausführung genau diesem Zweck: Die Authentifizierung erfolgt mit dem Keychain-Bundle als Abonnement-Anmeldeinformation, dessen langlebiges Aktualisierungstoken kontinuierlich neue Zugriffstoken generiert. Diese Anmeldeinformation hat die niedrigste Priorität in der Liste und ist gleichzeitig die langlebigste.
Warum sollte das für Sicherheitsexperten relevant sein? Weil der Clou dieser Methode in ihrer geringen Spurensuche liegt. Ein einziger unbemerkter Zugriff auf den Schlüsselbund ersetzt das Abgreifen mehrerer Dateien, und weniger kopierte Dateien auf dem Quellrechner bedeuten weniger Anzeichen für eine Exfiltrationserkennung. Unter macOS kann man nicht einmal auf ein Dateiereignis warten, da keine Datei existiert. Der Lesevorgang findet innerhalb eines Prozesses statt, daher muss dieser Prozess überwacht werden.
Die gesamte Kette, von Anfang bis Ende
Fügt man die beiden Hälften zusammen, ist der Angriff kurz. Auf der Seite des Opfers läuft alles wie beim normalen Benutzer ab, ohne Eingabeaufforderung und ohne Privilegien; auf der Seite des Angreifers wird lediglich die Aktion wiederholt.
Hier ist derselbe Ablauf als Machbarkeitsnachweis, von Anfang bis Ende durchlaufen:
Wird das Claude-Apps-Gateway dieses Problem nicht beheben?
Kurze Antwort: Nein. Wir haben das Gateway bereitgestellt, unseren eigenen Claude-Code darauf ausgerichtet und genau denselben Diebstahl durchgeführt. Es hat trotzdem funktioniert.
Es ist hilfreich, die Funktion des Gateways genau zu definieren, da sie enger gefasst ist, als der Name vermuten lässt. Es handelt sich nicht um eine zusätzliche Sicherheitsebene für Ihre normale Claude-Konfiguration. Vielmehr ist es ein Routing-Tool, mit dem Claude Code auf einen bestimmten Modellendpunkt verweisen kann, den eine Organisation selbst auswählt oder betreibt – abseits des Standardpfads von Anthropic: lokal, Microsoft Foundry, Amazon Bedrock, Google Cloud oder ein eigener Anthropic-Endpunkt. Die Gründe hierfür waren die üblichen: Datenresidenz- und Compliance-Vorgaben, ein bevorzugter Cloud-Anbieter oder eine lokale Bereitstellung. Trifft dies nicht auf Ihre Organisation zu, war das Gateway nie Teil Ihrer Konfiguration, und der Keychain-Eintrag wird genau wie im weiteren Verlauf dieses Beitrags beschrieben bereitgestellt.
Man kann sich durchaus fragen, welchen Nutzen das Gateway tatsächlich bietet, denn es ist nicht nichts. Entwickler melden sich mit dem unternehmensinternen SSO an, Sitzungen dauern etwa eine Stunde, und der Entzug von Berechtigungen erfolgt über den Identitätsanbieter (IdP). Sobald eine Organisation einen Benutzer deaktiviert, erlischt dessen Gateway-Zugriff innerhalb einer Sitzung. Der Upstream-Schlüssel, der Claude-API-Schlüssel oder die Cloud-Anmeldeinformationen bleiben vom Laptop fern. Genau das meint die Ankündigung mit:
„Auf den Rechnern der Entwickler bleiben keine langlebigen Geheimnisse verborgen.“
Es lohnt sich, diese Zeile genau zu lesen, denn es geht um den Upstream-Schlüssel, nicht um Diebstahl. Was sich noch im Keychain unter dem Gateway befindet, ist eine Aktualisierungsberechtigung. Diese kann so konfiguriert sein, dass nur das Gateway sie akzeptiert, aber genau darin liegt der Haken: Ein Angreifer, der sie ausliest und sich als der Benutzer mit dem Gateway verbindet, kann so lange neue Sitzungen erstellen, wie dieses Konto aktiviert ist. Die einstündige Sitzung schränkt den Dieb nicht ein. Nur wenn die Organisation den Vorfall bemerkt und den Benutzer deaktiviert, kann er gestoppt werden – und ein unbemerktes Auslesen des Keychains bewirkt dies nicht. „Keine dauerhaften Geheimnisse“ wird stillschweigend zu dauerhaftem Zugriff für jeden, der den Eintrag ausliest.
Wir richteten also ein Gateway ein, verbanden Claude damit und wiederholten den Angriff aus dem vorherigen Abschnitt. Der Keychain-Auslesevorgang blieb unverändert. Dasselbe einzeilige Python-Skript extrahierte die Anmeldeinformationen ohne Nachfrage, und wir kopierten sie auf einen zweiten Rechner.
Diesmal benötigten wir weder die zusätzlichen Vorbereitungen aus dem vorherigen Abschnitt noch eine zweite Datei des Opfers. Die Adresse des Gateways ist bereits in den gestohlenen Zugangsdaten enthalten. Der unter dem Schlüsselbundeintrag „Claude Code-credentials“ gespeicherte Wert enthält mehr als nur die Token. Er speichert auch das Gateway, an dem das Opfer angemeldet war. Ein einziger stiller Lesevorgang liefert uns somit sowohl die Schlüssel als auch die Adresse des Gateways, das sie öffnen.
Das bedeutet, dass nichts Zusätzliches von der Festplatte des Opfers kopiert werden muss. Die Konfiguration wird auf dem Rechner des Angreifers selbst erstellt, und zwar unter:
/Library/Application Support/ClaudeCode/managed-settings.json
und richten Sie es auf die Gateway-URL, die wir soeben aus den gestohlenen Anmeldeinformationen ausgelesen haben:
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
Das Schreiben dieser Datei stellt kein Hindernis dar. Anthropic selbst bezeichnet verwaltete Einstellungen als „clientseitige Steuerung, nicht als Sicherheitsgrenze“, sodass ein Angreifer seine eigenen erstellen kann. Anschließend laden wir die gestohlenen Anmeldeinformationen und starten Claude Code. Es ist kein separater Schritt erforderlich, um die Identität des Opfers wiederherzustellen. Die Anmeldeinformationen enthalten das Token, das Token authentifiziert sich am Gateway, und das Gateway führt die Sitzung als Opfer mit dessen Zugriffsrechten aus.
Das Gateway stellt jedoch eine Hürde dar, die ein rein entfernter Angreifer nicht überwinden kann. Claude Code kommuniziert nicht über eine öffentliche Adresse mit einem Gateway:
„Unter /login verlangt Claude Code, dass der Hostname oder die IP-Adresse des Gateways ausschließlich zu privaten Adressen aufgelöst wird: RFC 1918, Link-Local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 oder Loopback für die lokale Entwicklung. Für ein von Ihnen gehostetes Gateway werden alle öffentlichen Adressen abgelehnt.“
Die gestohlenen Zugangsdaten funktionieren also nur von einem Ort aus, der das private Gateway erreichen kann. Das klingt zunächst wie eine unüberwindbare Hürde, bis man sich das Bedrohungsmodell vor Augen führt. Wir gehen bereits davon aus, dass der Angreifer als Benutzer auf dem Rechner des Opfers agiert, der sich also innerhalb desselben Netzwerks befindet. Von dort aus eine private Adresse zu erreichen, ist der einfache Teil. Es handelt sich eher um eine Hürde als um eine unüberwindbare Grenze.
Hier die ehrliche Bewertung. Das Gateway ist aus anderen Gründen sinnvoll. Es hält den Upstream-Schlüssel vom Laptop fern und bietet der Organisation über den Identitätsanbieter (IdP) einen zentralen Not-Aus-Schalter. Dieser greift jedoch erst, wenn der Diebstahl bemerkt wurde. Die Schwachstelle, um die es in diesem Beitrag geht, wird dadurch nicht behoben. Die Anmeldeinformationen landen weiterhin im selben Schlüsselbund, dieser ist weiterhin ohne Aufforderung von jedem Prozess lesbar, und gestohlene Anmeldeinformationen funktionieren so lange gegen das Gateway, bis das Konto deaktiviert wird.
Die Netzwerkprüfung ist ein Umweg, kein Stopp. Und für die große Mehrheit der Benutzer, die das Gateway überhaupt nicht berühren, ändert sich dadurch nichts.
Was sollte ein Verteidiger sofort tun?
- macOS: Solange die ACL des Objekts nicht an die Claude-Signatur gebunden ist, ist der Prozess der Erkennungspunkt, nicht die Datei. Das Signal ist ein Aufruf von `/usr/bin/security find-generic-password`, dessen Dienstzeichenfolge „Claude Code-credentials“ lautet und der die Option `-w` zum Ausgeben des Geheimnisses enthält. Lassen Sie sich darüber per Prozessausführungs- oder Endpoint-Security-Telemetrie benachrichtigen und nutzen Sie die Prozessherkunft, um Fehlalarme zu vermeiden: Legitime Lesevorgänge lassen sich auf die Claude-Binärdatei zurückführen, daher sollten diese zuerst überprüft werden. Verdächtige Lesevorgänge stammen hingegen von einem Shell-Einzeiler, einem Editor, einem Erweiterungshost oder einem Skript zur Installation von Abhängigkeiten. Überwachen Sie auch `add-generic-password` für denselben Dienst, da so ein gestohlenes Paket auf einem zweiten Rechner installiert werden kann. Behandeln Sie diese Warnungen als zusätzliche Kontrollmaßnahme.
- Linux und Windows: Dateiintegritätsüberwachung und DLP auf Basis von .credentials.json, Warnungen bei Änderung der Berechtigungen und Inhaltssignaturen auf Basis der Präfixe sk-ant-oat und sk-ant-ort.
- Überall: Korrelieren Sie Zugriffe auf den Anmeldeinformationsspeicher mit unerwartetem ausgehendem Datenverkehr und überwachen Sie die Identitätsebene auf die Wiederverwendung desselben Tokens auf verschiedenen Hosts. Rotieren Sie das Token bei Verdacht. Ein einzelner Zugriff übergibt ein langlebiges Aktualisierungstoken. Daher erfordert ein glaubwürdiges Zugriffsereignis ein Abmelden und erneutes Anmelden sowie die Rotation des Konsolenschlüssels, nicht nur die Bereinigung des Endpunkts.
- Die eigentliche Lösung liegt bei Anthropic und ist risikoarm: Das Keychain-Element der CLI wird über die native API erstellt und an die Codesignatur der Claude-Binärdatei gebunden. Dieses Muster ist bereits in Claude Desktop enthalten.
Die gute Nachricht ist, dass der schwierigste Teil bereits im Quellcode von Anthropic gelöst ist. Die CLI benötigt kein neues Sicherheitsmodell, sondern kann das bereits vorhandene nutzen.
Offenlegungszeitplan
25. Juni, 3:46 Uhr UTC. Der Forscher reicht den Bericht mit Reproduktionsschritten, Auswirkungen und drei Screenshots ein.
25. Juni, 4:05 Uhr UTC. Anthropic schließt es nur 19 Minuten später als informativ, indem es es unter „Lokale Speicherung von Claude Code-Anmeldeinformationen, Konfigurationen und Protokollen“ als nicht relevant einstuft und erklärt, dass Prozesse desselben Benutzers vollständig vertrauenswürdig sind, sodass Keychain-ACLs pro Prozess keine sinnvolle Einschränkung darstellen.
2. Juli, 11:12 Uhr UTC. Der Forscher fordert eine erneute menschliche Bewertung, argumentiert, dass der Verschluss dem falschen Ausschluss zugeordnet wurde (es handelt sich um eine Fehlkonfiguration der Keychain-ACL, nicht des lokalen Speichers, und Desktop macht es auf demselben Betriebssystem richtig), fügt das POC-Video bei und kündigt eine defensive schriftliche Erklärung mit dem Angebot an, die Offenlegung zu koordinieren.
2. Juli, 11:14 Uhr UTC. Anthropic bestätigt den Erhalt des Antrags auf erneute Bewertung und teilt mit, dass eine interne Überprüfung erfolgen wird. Die Organisation bestätigt, dass eine öffentliche Diskussion zulässig ist, da der Bericht abgeschlossen ist, und bittet darum, vorab einen Entwurf einsehen zu dürfen.
Juli 22. Der Forscher teilt, wie von Anthropic gewünscht, den finalen Entwurf des Blogbeitrags zur Vorabprüfung mit und merkt an, dass dieser nun auch eine Analyse darüber enthält, ob das Claude-Apps-Gateway den Fehler behebt oder nicht.
Juli 24. Anthropic schließt seine Überprüfung ab, meldet keine sachlichen Bedenken oder Korrekturwünsche und gibt den Bericht zur Veröffentlichung frei. Die Klassifizierung bleibt unverändert: Anthropic ergänzt, dass die Verschärfung der Zugriffskontrolle für das Keychain-Element nun als sinnvolle Verbesserung der mehrschichtigen Sicherheitsarchitektur verfolgt wird, obwohl sie dies gemäß ihrem Bedrohungsmodell nicht als Schwachstelle einstuft.
