Es sollte nichts geben, das geharvestet werden kann

Gestern hat eine kompromittierte Version der Bitwarden-CLI SSH-Schlüssel, AWS-Zugangsdaten, npm-Token, Umgebungsvariablen, Shell-Verlauf und Git-Geheimnisse von 334 Entwicklerrechnern abgeschöpft.

Heute war es Bitwarden. Letzten Monat war es Axios. Davor Checkmarx. Morgen wird es eine VS-Code-Erweiterung sein, oder Acrobat, oder ein Homebrew-Formula, oder ein Docker-Image. Der Vektor ändert sich wöchentlich. Das Ergebnis ist immer dasselbe.

Die Schadsoftware landet. Sie liest ~/.ssh/. Sie liest ~/.aws/credentials. Sie liest ~/.npmrc. Sie liest ~/.git-credentials. Sie liest Shell-Verlauf, Umgebungsvariablen, Passwortspeicher des Browsers. Sie packt alles zusammen und sendet es an einen C2-Server.

Und es funktioniert. Jedes Mal.

Die Ernte

Die Bitwarden-Nutzlast — eine 10 MB große, obfuskierte Datei namens bw1.js — hat nicht versucht, eine Verschlüsselung zu brechen. Das war auch nicht nötig. Das ist, was sie gesammelt hat, dokumentiert von Socket und Aikido:

• SSH-Schlüssel und Host-Fingerprints
• AWS-, GCP- und Azure-Cloud-Zugangsdaten
• npm-Authentifizierungstoken
• Git-Zugangsdaten und Remote-URLs
• Umgebungsvariablen
• Shell-Verlauf
• Claude-Code-Authentifizierung und MCP-Konfigurationen

Anschließend nutzte sie die gestohlenen npm-Token, um weitere Pakete des Opfers neu zu veröffentlichen, und verbreitete sich so weiter. Aus Opfern wurden Vektoren.

Nichts davon erforderte das Brechen einer Verschlüsselung. Jedes dieser Geheimnisse war eine Datei im Dateisystem, lesbar durch jeden Prozess, der als der betreffende Benutzer läuft.

Das ist keine Bitwarden-Geschichte

Die Tresorverschlüsselung von Bitwarden wurde nicht gebrochen. Deren Zero-Knowledge-Architektur hielt stand. Die Schadsoftware hat den Tresor nie berührt.

Sie musste es auch nicht.

Der Tresor schützt, was darin liegt. Aber SSH-Schlüssel lagen nie im Tresor. AWS-Zugangsdaten lagen nie im Tresor. npm-Token, Git-Zugangsdaten, API-Schlüssel in .env-Dateien — nichts davon liegt in Passwort-Managern. Es liegt in Dotfiles, im Klartext, auf jedem Entwicklerrechner.

Der Angreifer hat das verstanden. Der Tresor ist ein verschlossener Tresor in einem Haus, in dem jede Schublade offen steht.

Die tatsächliche Angriffsfläche

Öffnen Sie jetzt ein Terminal. Sehen Sie sich an, was auf Ihrem Rechner liegt.

~/.ssh/id_ed25519 — Ihr privater Schlüssel. Klartextdatei.

~/.aws/credentials — Ihr Cloud-Zugang. Klartextdatei.

~/.npmrc — Ihr Publish-Token. Klartextdatei.

~/.git-credentials — Ihr Repository-Zugang. Klartextdatei.

~/.env in einem Dutzend Projektverzeichnissen — API-Schlüssel, Datenbankpasswörter, Signing-Geheimnisse. Alles Klartextdateien.

Jeder Prozess, der als Ihr Benutzer läuft, kann all das lesen. Keine Rechteerweiterung nötig. Kein Exploit erforderlich. Einfach cat.

Das ist die Standardentwicklerkonfiguration im Jahr 2026. Wir legen unsere Passwörter in einen verschlüsselten Tresor und lassen alles andere offen liegen.

Die falsche Frage

Nach jeder Supply-Chain-Attacke stellt die Branche dieselbe Frage: Wie verhindern wir, dass Schadsoftware hereinkommt?

Bessere CI/CD-Sicherheit. Code Signing. Dependency-Scanning. Sandbox-Laufzeiten. Das alles ist sinnvoll. Nichts davon reicht aus. Die Angriffsfläche ist zu breit. Es gibt zu viele Vektoren — Paketmanager, Browser-Erweiterungen, IDE-Plugins, OAuth-Apps, kompromittierte Build-Werkzeuge. Sie können nicht jeden Eingangspunkt versiegeln.

Die richtige Frage lautet: Wenn Schadsoftware unausweichlich Code auf einem Entwicklerrechner ausführt, was findet sie dort vor?

Wenn die Antwort „hunderte Klartext-Zugangsdaten an vorhersagbaren Orten im Dateisystem“ lautet, ist jede Absicherung der Lieferkette ohne Belang. Sie spielen Verteidigung auf einem Feld, hinter dem das Tor offensteht.

Es sollte nichts geben, das geharvestet werden kann

Die Lösung ist nicht eine bessere Erkennung von Schadsoftware. Die Lösung ist nicht die Sandboxisierung von npm install. Die Lösung ist nicht eine schnellere Reaktionszeit im Incident.

Die Lösung lautet: Geheimnisse sollten nicht als Dateien auf der Festplatte existieren.

SSH-Schlüssel, die im Moment der Authentifizierung aus Hardware abgeleitet werden — nicht in ~/.ssh/ gespeichert. Cloud-Zugangsdaten, die pro Sitzung aus einer hardwaregebundenen Identität ausgestellt werden — nicht nach ~/.aws/ geschrieben. API-Token, die begrenzt, flüchtig und hardwaregesteuert sind — nicht in .env-Dateien liegend.

Wenn ein Zugangsdatensatz nur innerhalb eines Hardware-Sicherheitsmoduls und in flüchtigem Prozessspeicher während der Verwendung existiert, gibt es nichts, was Schadsoftware lesen könnte. Keine Datei zum Exfiltrieren. Kein Dotfile zum Abschöpfen. Der Prozess läuft, findet nichts, geht weiter.

Das ist nicht theoretisch. Hardwaregebundene Zugangsdaten gibt es heute bereits. WebAuthn PRF kann kryptografische Schlüssel aus einer physischen Authentisierer-Berührung ableiten — Schlüssel, die das Dateisystem nie berühren. Die Technologie ist da. Die Branche hat sie nur nicht als Standard übernommen.

Was Sie jetzt tun können

Wenn Sie von der Bitwarden-CLI-Kompromittierung betroffen waren:

• Erneuern Sie jeden Zugangsdatensatz auf dem Rechner — SSH-Schlüssel, Cloud-Token, npm-Token, API-Schlüssel, alles in Dotfiles und Umgebungsvariablen
• Prüfen Sie, ob npm-Pakete, die Sie betreuen, neu veröffentlicht wurden
• Prüfen Sie GitHub-Aktivität und CI/CD-Workflows auf unautorisierte Änderungen

Wenn Sie nicht betroffen waren, ist der Schritt derselbe. Sehen Sie sich Ihren Rechner an. Zählen Sie die Geheimnisse im Klartext. Fragen Sie sich, was passiert, wenn — nicht falls — etwas Böses als Ihr Benutzer läuft.

Die Antwort sollte lauten: nichts. Es sollte nichts geben, das geharvestet werden kann.