Bitwarden CLI bei laufender Checkmarx-Lieferkettenkampagne kompromittiert

 (socket.dev)
1 Punkte von GN⁺ 6 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Bitwarden-CLI-Paket für npm wurde als Teil des laufenden Checkmarx-Lieferkettenangriffs kompromittiert; der bislang bestätigte Wirkungsbereich ist auf den Build @bitwarden/cli 2026.4.0 begrenzt
  • Der im Paket enthaltene Schadcode bw1.js nutzt dieselbe Infrastruktur und Verschleierung wie audit.checkmarx[.]cx/v1/telemetry und passt zudem zu Hinweisen auf eine CI/CD-Kompromittierung über eine kompromittierte GitHub Action
  • Zu den Sammelzielen gehören nicht nur GitHub-Tokens, sondern auch AWS-, Azure- und GCP-Zugangsdaten, .npmrc, SSH-Schlüssel, Umgebungsvariablen sowie Konfigurationsdateien von Claude/MCP
  • Die exfiltrierten Informationen werden zum Erstellen und Committen öffentlicher GitHub-Repositories, zur Weiterverbreitung per erneuter Veröffentlichung mit npm-Tokens sowie zur Workflow-Injektion genutzt; außerdem sind Persistenzfunktionen wie Änderungen an ~/.bashrc und ~/.zshrc enthalten
  • Organisationen, die Bitwarden CLI verwendet haben, sollten den Vorfall als Offenlegung von Zugangsdaten und CI/CD-Kompromittierung behandeln; wichtig sind die Prüfung von CI-Logs und der Austausch potenziell offengelegter Geheimnisse

Überblick

  • Das Bitwarden-CLI-npm-Paket wurde als Teil des laufenden Checkmarx-Lieferkettenangriffs kompromittiert; als betroffene Version wurde bislang @bitwarden/cli2026.4.0 bestätigt
    • Der Schadcode befand sich in bw1.js, das im Paket enthalten war
    • Der Angriffsweg passt zu Hinweisen auf die Nutzung einer kompromittierten GitHub Action innerhalb der CI/CD-Pipeline von Bitwarden und entspricht den Mustern der Kampagne, die auch in anderen Repositories beobachtet wurden
  • Nach aktuellem Stand ist der bestätigte Umfang auf den Bitwarden-CLI-Build begrenzt; die Kompromittierung folgt dem GitHub-Actions-Lieferkettenvektor, der in der umfassenderen Checkmarx-Kampagne identifiziert wurde
    • Betroffen ist nur das CLI-Paket für npm
    • Für die Chrome-Erweiterung, den MCP-Server und andere offizielle Distributionen wurde bislang keine Auswirkung bestätigt
  • Die Untersuchung läuft weiter; eine vollständige technische Analyse, betroffene Versionen, Kompromittierungsindikatoren und Reaktionsleitlinien sollen noch veröffentlicht werden
  • Wer Bitwarden CLI verwendet, sollte CI-Logs prüfen und potenziell offengelegte Geheimnisse austauschen

Technische Analyse

  • Die schädliche Payload bw1.js teilt die Kerninfrastruktur mit Checkmarx' mcpAddon.js, das am Vortag analysiert wurde
    • Es wird derselbe C2-Endpunkt audit.checkmarx[.]cx/v1/telemetry verwendet und die Verschleierung erfolgt mit __decodeScrambled und dem Seed 0x3039
    • Zusätzlich werden commit-basierte Exfiltration über die GitHub-API sowie Token-Diebstahl und erneute Veröffentlichung über das npm-Register durchgeführt
  • Auch die Struktur der eingebetteten Payload stammt aus derselben Familie
    • Innerhalb einer gzip+base64-Struktur befindet sich ein Python-Skript, das den Speicher von GitHub-Actions-Runner.Worker ausliest, um an GitHub-Tokens zu gelangen
    • Ebenfalls enthalten sind ein setup.mjs-Loader für erneut veröffentlichte npm-Pakete, GitHub-Actions-Workflow-YAML, ein hart codierter öffentlicher RSA-Schlüssel und eine ideologische Manifest-Zeichenkette
  • Der Umfang der Sammlung von Zugangsdaten ist sehr breit
    • GitHub-Tokens werden per Speicher-Scraping von Runner.Worker und aus Umgebungsvariablen gesammelt
    • AWS-Zugangsdaten werden in Dateien unter ~/.aws/ und in Umgebungsvariablen gesucht
    • Azure-Tokens werden über azd gesammelt, GCP-Zugangsdaten über gcloud config config-helper
    • Auch .npmrc, SSH-Schlüssel, Umgebungsvariablen und Konfigurationsdateien von Claude/MCP gehören zu den Zielen
  • Auch die Exfiltrationsmethode über GitHub ist konkret belegt
    • Unter dem Konto des Opfers werden öffentliche Repositories erstellt, die dem Dune-Namensschema {word}-{word}-{3digits} folgen
    • Verschlüsselte Ergebnisse werden committet, und in die Commit-Nachrichten werden zusammen mit dem Marker LongLiveTheResistanceAgainstMachines Tokens eingefügt
  • Die Mechanismen zur Ausbreitung in der Lieferkette sind ebenfalls enthalten
    • Mit gestohlenen npm-Tokens werden beschreibbare Pakete gesucht und mit eingefügtem preinstall hook erneut veröffentlicht
    • GitHub-Actions-Workflows werden injiziert, um weitere Repository-Geheimnisse zu sammeln
  • Es gibt einen Kill Switch für russische Locale-Einstellungen
    • Beginnt die System-Locale mit "ru", beendet sich die Malware still
    • Geprüft werden Intl.DateTimeFormat().resolvedOptions().locale sowie die Umgebungsvariablen LC_ALL, LC_MESSAGES, LANGUAGE und LANG
  • Als Laufzeitumgebung wird Bun v1.3.13 verwendet, heruntergeladen von GitHub Releases

Unterschiede zum Checkmarx-Vorfall

  • bw1.js enthält zusätzliche Kompromittierungsindikatoren, die in der Dokumentation des Checkmarx-Vorfalls nicht erwähnt wurden
    • Eine hart codierte Lock-Datei /tmp/tmp.987654321.lock verhindert parallele Ausführung
    • Durch Injektion der Payload in ~/.bashrc und ~/.zshrc wird Persistenz über Shell-Profile hergestellt
    • Mit dem Setzen der Repository-Beschreibung auf Shai-Hulud: The Third Coming und Debug-Zeichenketten wie "Would be executing butlerian jihad!" wird explizites Branding verwendet
  • Die gemeinsam genutzten Werkzeuge deuten stark auf ein gemeinsames Malware-Ökosystem hin, operative Signaturen erschweren jedoch die Zuschreibung zusätzlich
    • Nach Entdeckung des Checkmarx-Angriffs behauptete TeamPCP über das Social-Konto @pcpcats, dafür verantwortlich zu sein
    • Die betreffende Malware versuchte, sich mit unauffällig wirkenden Beschreibungen zu tarnen
  • Diese Payload tritt öffentlich anders auf
    • Ideologische Markierungen wie Repository-Namen mit Shai-Hulud, ein "Butlerian Jihad"-Manifest und Commit-Nachrichten, die den Widerstand gegen Maschinen propagieren, sind direkt in die Malware eingebettet
    • Möglich bleiben damit mehrere Erklärungen: ein anderer Betreiber mit gemeinsamer Infrastruktur, eine ideologisch stärkere Abspaltung oder ein Wandel im öffentlichen Auftreten der Kampagne

Empfehlungen

  • Organisationen, die das bösartige Bitwarden-npm-Paket installiert haben, sollten den Vorfall als Offenlegung von Zugangsdaten und CI/CD-Kompromittierung behandeln
  • Das betroffene Paket sollte auf Entwicklerrechnern und in Build-Umgebungen sofort entfernt und alle Zugangsdaten ersetzt werden, die in diesen Umgebungen offengelegt worden sein könnten
    • Dazu gehören GitHub-Tokens, npm-Tokens, Cloud-Zugangsdaten, SSH-Schlüssel und CI/CD-Geheimnisse
  • In GitHub sollten unautorisierte Repository-Erstellungen und auffällige Workflows geprüft werden
    • Es sollten unerwartete Dateien unter .github/workflows/, verdächtige Workflow-Ausführungen, Artifact-Downloads und öffentliche Repositories mit dem Dune-Namensschema {word}-{word}-{3digits} überprüft werden
    • Bei möglicher Betroffenheit sollten neu veröffentlichte Repositories auf die folgenden Schlüsselwörter geprüft werden
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • In npm sollte auf unautorisierte Veröffentlichungen geprüft werden
    • Es sollten nicht genehmigte Publishes, Versionsänderungen und neu hinzugefügte Installations-Hooks kontrolliert werden
  • In Cloud-Umgebungen sollten die Zugriffslogs erneut überprüft werden
    • Nachvollzogen werden müssen ungewöhnliche Zugriffe auf Geheimnisse, Token-Nutzung und neu ausgestellte Zugangsdaten
  • Auf Endpunkten und Runnern sollten die beobachtete Exfiltrationsinfrastruktur und Spuren von Dateizugriffen verfolgt werden
    • Es sollte nach ausgehenden Verbindungen zu audit[.]checkmarx[.]cx gesucht werden
    • Es sollte geprüft werden, ob Bun-Ausführung in sonst unüblichen Umgebungen stattgefunden hat
    • Zu untersuchen sind Zugriffe auf .npmrc, .git-credentials, .env, Cloud-Speicherorte für Zugangsdaten sowie gcloud, az und azd
    • Auch das Vorhandensein von /tmp/tmp.987654321.lock sowie Änderungen an ~/.bashrc und ~/.zshrc sollten geprüft werden
  • In GitHub Actions sollte untersucht werden, ob unautorisierte Workflows erstellt wurden
    • Es muss geprüft werden, ob Workflows in temporären Branches angelegt wurden
    • Ebenfalls sollte kontrolliert werden, ob Artifacts wie format-results.txt erzeugt oder heruntergeladen wurden
  • Langfristig sollte der Schadensradius künftiger Lieferkettenvorfälle verringert werden
    • Token-Berechtigungen sollten minimiert und nach Möglichkeit kurzlebige Zugangsdaten verwendet werden
    • Rechte zum Erstellen und Veröffentlichen von Paketen sollten eingeschränkt und GitHub-Actions-Berechtigungen verschärft werden
    • Unnötiger Artifact-Zugriff sollte deaktiviert und öffentliche Repositories oder Workflow-Änderungen außerhalb des regulären Release-Prozesses überwacht werden

Kompromittierungsindikatoren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 일 전
Hacker-News-Kommentare

  • Ich frage mich, ob es eine bessere Verteidigung gibt als eine minimale Wartezeit vor Releases
    Schon wenn man nur min-release-age=7 in .npmrc gesetzt hätte, hätten die 334 Personen, die @bitwarden/cli 2026.4.0 erhalten haben, das vor etwa 19 Stunden hochgeladen und später als bösartig erkannt wurde, es wohl vermeiden können
    Ähnlich passt das auch ziemlich gut auf die Fälle axios, ua-parser-js und node-ipc; gegen lange schwelende Fälle wie event-stream hilft es zwar nicht, aber gegen die meisten akuten Supply-Chain-Angriffe scheint es wirksam zu sein
    Es gibt Beispielkonfigurationen, wie man für npm/pnpm/bun/uv jeweils eine Wartezeit setzt, und weil es kein One-Click-Tool zum Prüfen und Anwenden gab, habe ich selbst https://depsguard.com gebaut
    Ich habe gerade auch https://cooldowns.dev entdeckt, das eine ähnliche Idee hat

    • Ich nutze Aikido safe-chain
      Das setzt nicht nur eine minimale Release-Wartezeit, sondern prüft als Wrapper um npm/uv usw. vor der Installation jede Abhängigkeit gegen eine kommerzielle Schwachstellen-Datenbank und auf bekannte Probleme oder verdächtige Signale
    • Die Cooldown-Idee ist gut, aber ich frage mich, ob dieser Angriff überhaupt entdeckt worden wäre, wenn niemand sofort aktualisiert hätte
      In der Realität aktualisiert zwar immer irgendjemand sofort, aber der ganze Prozess, durch den solche Vorfälle auffliegen, scheint auch davon abzuhängen, dass einige Nutzer sehr schnell updaten
    • Ich denke, man sollte damit anfangen, Backend- oder CLI-Tools nicht auf NPM zu legen
    • Für Neuinstallationen mag das so sein, aber bei bestehenden Abhängigkeiten müsste es doch reichen, auf Patch-Versionen zu pinnen und die SHA festzuschreiben, oder?
    • Solche Angriffe reichen meistens nicht bis zur Upstream-Quelle, deshalb blockiert ein Build aus dem Source wie bei https://www.chainguard.dev/libraries grob 98 % davon
      Wenn man Register-Binärdateien unverändert ziehen muss, kann ein Cooldown das Risiko etwas senken
      Für die langen Randfälle, in denen auch GitHub kompromittiert wurde, braucht man wohl eine Kombination aus Commit-/Maintainer-Heuristiken und KI-basierter Analyse von Codeänderungen, mit menschlicher Prüfung bei Auffälligkeiten
      Zur Einordnung: Ich arbeite dort

  • Der Kern dieses Vorfalls ist, dass die Build-Pipeline kompromittiert wurde und dadurch verunreinigte Pakete verteilt wurden
    Wenn man geschäftskritische Dinge auf npm aufsetzt, sollte man Abhängigkeiten trotzdem unbedingt pinnen
    Viele Entwickler halten ein Lockfile für ausreichend, aber wenn ^-Bereiche übrig bleiben, kann ein Lockfile-Update neue Versionen hereinziehen, die ich nicht ausdrücklich ausgewählt habe
    Bei Systemen, die den Fortbestand eines Unternehmens beeinflussen können, ist dieser Aufwand es wert

    • Andersherum betrachtet wäre es auch ideal, wenn das System Sicherheitslücken-Fixes in späteren Versionen automatisch übernehmen würde

  • https://github.com/doy/rbw ist eine Rust-Alternative zur Bitwarden CLI
    Das Rust-Ökosystem wirkt auch zunehmend so, als würde es wie npm mit großen und tiefen Abhängigkeitsbäumen werden, aber man muss immer noch deutlich weniger Autoren vertrauen als in typischen JavaScript-Fällen

    • Wenn man in https://github.com/doy/rbw/blob/main/Cargo.toml#L16 schaut, gibt es auch hier ziemlich viele Abhängigkeiten
      Immerhin sind die Versionen dort gepinnt
    • Ich frage mich, ob es Nachteile hat, den eingebauten Passwortmanager von Firefox zu verwenden
    • Alle halten Rust für sicherer, aber dass durch Abhängigkeiten das Risiko steigt, Malware hereinzuziehen, wird erstaunlich leicht ignoriert
    • Die Kombination rbw + vaultwarden funktioniert ziemlich gut als selbst hostbare Rust-Version von Bitwarden
    • Wegen solcher Dinge könnte mehr Software wieder in Richtung eines Stacks wie .Net gehen, in dem man das meiste ohne Drittanbieter-Abhängigkeiten erledigen kann
      Oder es geht in die andere Richtung und mehr Funktionalität wandert in die Standardbibliotheken der Sprachen

  • Meine Erfahrung mit der Bitwarden-CLI war sehr schlecht
    Ich habe bw list ausgeführt und dachte, es würde nur die Namen der Passwörter anzeigen, tatsächlich wurden aber alle Passwörter und sogar die aktuellen TOTP-Codes ausgegeben
    Noch schlimmer: Als ich per ssh auf den Server ging und weechat in tmux öffnete, war der komplette Inhalt des bw-Befehls über die weechat-Eingabeverlaufshistorie zugänglich
    Ich habe keine Ahnung warum; es blieb über tmux- und weechat-Sitzungen hinweg bestehen und verschwand erst nach einem Neustart des Servers
    Danach habe ich die bw-CLI sofort gelöscht und werde sie nicht wieder installieren
    Zur Einordnung: Ich nutze ghostty als Terminal

    • Das ist eher ein Beschwerdepost, der mit dem eigentlichen Thema nichts zu tun hat
    • Ich wollte die CLI ausprobieren, habe dann gesehen, dass sie auf JavaScript basiert, und es gelassen
    • Wirklich seltsam
      Ich frage mich, ob es eine bwcli-Erweiterung für weechat gibt; dass Bitwarden überhaupt eine CLI hat, höre ich gerade zum ersten Mal
      Ich nutze lokal KeePass

  • Die CLI habe ich nie benutzt, aber das Browser-Plugin verwende ich
    Wenn das kompromittiert wird, wäre das wirklich schlimm, und ich weiß nicht, was man dagegen tun soll
    Ich überlege, ob es die richtige Antwort ist, dauerhaft eine verifizierte ältere Version zu verwenden
    Es fühlt sich plötzlich merkwürdig an, dass ein großer Teil meines Lebens davon abhängt, dass diese Geheimnisse geheim bleiben

    • Je mehr Integrationspunkte es gibt, desto größer wird auch die Angriffsfläche
      Deshalb nutze ich Passwortmanager-Browser-Erweiterungen grundsätzlich nicht
      Nachdem ich früher einmal ein Produkt mit Sicherheitsproblemen in der Browser-Integration gesehen habe, meide ich das komplett; iOS-Integration vertraue ich etwas mehr, bleibe aber vorsichtig
    • Cooldowns sollten meiner Meinung nach überall Standard sein
      Also in Entwickler-Paketmanagern, OS-Paketmanagern, Browser-Erweiterungen und sogar bei automatischen Updates eigenständiger Apps
      Firmen wie Socket brauchen Zeit, um bösartige Updates zu erkennen; wenn alle schon wenige Minuten nach Veröffentlichung herunterladen, wird solche Erkennung sinnlos
    • Meine wertvollsten digitalen Güter, nämlich mein E-Mail- und mein Bitwarden-Konto, sind immer durch einen YubiKey, den ich bei mir trage, und einen Backup-Schlüssel an einem anderen Ort geschützt
      Ich kann dieses Setup nur empfehlen
      Der Titel hat mich kurz erschreckt, aber ich habe das Gefühl, alles Vernünftige zu tun, ohne paranoide Züge anzunehmen
    • Statt eines Browser-Plugins kann man auch einfach die Desktop-App oder direkt den Web-Vault nutzen
    • Kurz gesagt gibt es dafür diese beiden Möglichkeiten
      https://cooldowns.dev
      https://depsguard.com
      Das zweite pflege ich; hätte ich das erste früher gekannt, hätte ich es wahrscheinlich gar nicht gebaut
      Beide machen fast dasselbe, nur meine Variante ist mit Rust vielleicht etwas übertrieben

  • Das Wichtigste hier ist, dass ein npm install schon ausreichte
    Wenn der Kompromittierungspunkt preinstall ist, bricht die verbreitete Annahme zusammen, man könne ja nach der Installation prüfen
    Zu diesem Zeitpunkt hatte die Payload schließlich bereits Gelegenheit zur Ausführung
    Besonders interessant ist das in Agenten-, CI- und ephemeren Sandbox-Umgebungen: Selbst wenn die Expositionszeit kurz ist, reicht es aus, wenn Installationen automatisch wiederholt werden
    Bemerkenswert ist auch, dass diese Payload nicht nur auf Geheimnisse zielte, sondern auch auf Konfigurationen von KI-Tooling
    Die Manipulation von Shell-Profilen könnte realistisch ein Weg sein, den Kontext zu vergiften, den der nächste Coding-Assistent einliest
    Diese Perspektive habe ich zusammen mit der AgentSH-Arbeit ausführlicher hier beschrieben: https://www.canyonroad.ai/blog/the-install-was-the-attack/

    • In Wirklichkeit prüft praktisch niemand Pakete nach der Installation, und speziell npm-install-Skripte als Sonderfall herauszugreifen, ist meiner Meinung nach ein oft widerlegtes Argument
      Am Ende führt man sowieso das eigentliche Binärprogramm aus
      Und wenn man es genau nehmen will, könnte man Pakete auch vor der Installation manuell herunterladen und prüfen; wenn man die Garantien und den Geltungsbereich des Installers nicht sehr genau versteht, ist es eigentlich noch seltsamer, dem Herunterladen und Entpacken von Schadcode halb blind zu vertrauen

  • Ein Kill Switch für russische Locale — das wirkt zugleich dreist und feige

    • Noch schlimmer ist, dass man nicht einmal weiß, ob das wirklich eine Spur oder nur eine False Flag ist
    • Da fallen einem alle möglichen Sprichwörter ein, etwa Discretion is the better part of valor
      Kurz gesagt wirkt es wie die Haltung: sich nicht selbst ins Bein schießen
    • Für sich genommen ist das kein schlüssiger Beweis
      In den Vault7-Leaks stand auch, dass NSA und CIA solche Spuren absichtlich hinterlassen, um die Herkunft zu verschleiern, und auch andere staatliche Akteure würden so etwas durchaus einsetzen
    • Es wirkt auch wie eine Drohoperation eines anderen Landes
    • Wer würde in einem npm-publish-GitHub-CI-Job schon absichtlich die Locale so setzen?
      Es sieht nach einer allzu offensichtlichen Irreführungsspur aus, erzeugt aber gleichzeitig stark den Eindruck staatlicher Beteiligung

  • Als KeePass-Nutzer lebt es sich mit deutlich weniger Stress
    Schon in den letzten fünf Jahren habe ich mit KeePass auf lokaler Infrastruktur mehrere Sicherheitsvorfälle vermieden

    • Hier war nicht der Vault selbst, sondern das Zugriffswerkzeug das Problem
      Dasselbe könnte bei einem KeePass-Zugriffstool theoretisch auch passieren; ich sehe also nicht genau, was daran grundlegend anders sein soll
    • Ich muss Passwörter sowohl in der Infrastruktur als auch auf dem Telefon nutzen können; ich frage mich, wie man das mit KeePass löst
      Ich dachte bisher, das sei nicht möglich, habe es aber ehrlich gesagt nie tief untersucht
    • Für Leute, die ihre eigene Infrastruktur betreiben können, mag das gut sein, aber den Ausdruck stress free würde ich nicht ohne Weiteres auf Durchschnittsnutzer ausdehnen
    • Das Einzeldatei-Modell verstehe ich, aber ich frage mich ganz praktisch, wie Synchronisierung und Konfliktauflösung funktionieren
      Was passiert etwa, wenn zwei Geräte offline jeweils ein Passwort hinzufügen und später wieder online gehen?
    • Was ich bei KeePass noch nie ganz verstanden habe, ist das Thema Cloud-Backup
      Wenn man das Backup verschlüsselt, wo speichert man dann dieses Passwort, und wo wiederum das Passwort des Cloud-Anbieters?

  • Besonders beeindruckend an diesem Angriff ist, dass die Angreifer das Timing genau auf einen Moment abstimmen mussten, in dem GitHub nicht ausgefallen war

  • Deshalb verwende ich überhaupt keinen Passwortmanager eines Drittanbieters
    Denn man muss dauerhaft darauf vertrauen, dass jemand Dinge wie Sicherheit, Updates und Backups ordentlich erledigt
    Ich habe stattdessen selbst einen zustandslosen Passwortgenerator gebaut, wodurch ich keinerlei Daten-Backups oder Synchronisierung zwischen Geräten brauche
    Man gibt ein sehr langes und starkes Master-Passwort, den Servicenamen und den Benutzernamen ein, und daraus wird mit passenden Parametern ein scrypt-Hash berechnet, der Brute-Force praktisch unmöglich macht
    Für wichtige Konten nutze ich zusätzlich 2FA