GitLab entdeckt weitreichenden NPM-Lieferkettenangriff

 (about.gitlab.com)
1 Punkte von GN⁺ 2025-11-29 | 1 Kommentare | Auf WhatsApp teilen
  • Im gesamten npm-Ökosystem breitet sich eine destruktive Malware-Variante aus, die vom Sicherheitsteam von GitLab erkannt wurde
  • Die Malware ist eine weiterentwickelte Form von Shai-Hulud mit einer wurmartigen Verbreitungsstruktur, die automatisch auch andere Pakete infizierter Entwickler kompromittiert
  • Nach dem Diebstahl von Zugangsdaten bei GitHub, AWS, GCP, Azure und weiteren Diensten werden Daten in ein von den Angreifern kontrolliertes GitHub-Repository exfiltriert
  • Enthält einen „Dead Man’s Switch“, der Benutzerdaten sofort löscht, wenn der Zugriff auf GitHub und npm gleichzeitig blockiert wird
  • GitLab hat bestätigt, dass die eigenen Systeme nicht infiziert wurden, und stellt Erkennungs- und Reaktionsmaßnahmen über Dependency Scanning und GitLab Duo Chat bereit

Überblick über den Angriff

  • Das Vulnerability Research Team von GitLab hat einen groß angelegten Lieferkettenangriff im npm-Ökosystem erkannt
    • Interne Monitoring-Systeme entdeckten mehrere infizierte Pakete
    • Die Malware wurde als Variante von Shai-Hulud identifiziert
  • Die Malware infiziert über eine wurmartige Ausbreitung automatisch auch andere Pakete betroffener Entwickler
  • GitLab hat bestätigt, dass im eigenen Haus keine bösartigen Pakete verwendet wurden, und die Informationen mit der Security-Community geteilt

Interne Struktur des Angriffs

  • Die von internen Monitoring-Systemen erkannten bösartigen npm-Pakete führen folgende Funktionen aus
    • Sammlung von Zugangsdaten für GitHub, npm, AWS, GCP und Azure
    • Übertragung der gestohlenen Daten an ein von den Angreifern kontrolliertes GitHub-Repository
    • Automatische Infektion weiterer Pakete des Opfers
    • Ausführung einer destruktiven Payload, wenn der Zugriff auf die Infrastruktur blockiert wird
  • Mehrere infizierte Pakete wurden bestätigt, die Untersuchung läuft weiter

Technische Analyse: Ablauf des Angriffs

Vektor der Erstinfektion

  • Die Malware dringt über einen mehrstufigen Ladevorgang in das System ein
    • Dem package.json eines infizierten Pakets wird das Skript setup_bun.js hinzugefügt
    • Nach außen tarnt es sich als Installation der Bun JavaScript Runtime
    • Tatsächlich führt es bun_environment.js aus, eine 10 MB große, verschleierte Payload
  • Die Kombination aus kleiner Loader-Datei und großer verschleierter Payload dient der Umgehung von Erkennungssystemen

Sammlung von Zugangsdaten

  • Unmittelbar nach der Ausführung sammelt die Malware Token und Geheimnisse aus verschiedenen Quellen
    • GitHub-Token (ghp_, gho_)
    • AWS-, GCP- und Azure-Zugangsdaten
    • npm-Token (.npmrc und Umgebungsvariablen)
    • Mit dem Tool Trufflehog wird das gesamte Home-Verzeichnis gescannt, um API-Schlüssel, Passwörter, Git-Historien und weitere Daten zu finden

Netzwerk zur Datenexfiltration

  • Mit gestohlenen GitHub-Token wird ein öffentliches Repository mit der Beschreibung „Sha1-Hulud: The Second Coming.” erstellt
    • Dieses Repository dient als Dropbox für die gestohlenen Daten
    • Zur Sicherung der Persistenz werden GitHub Actions Runner installiert
  • Falls die Berechtigungen nicht ausreichen, sucht die Malware nach anderen Repositories mit demselben Marker und verwendet Token anderer Systeme weiter
    • So entsteht ein verteiltes Netzwerk zum Teilen von Token

Ausbreitung in der Lieferkette

  • Mit gestohlenen npm-Token werden alle Pakete des Opfers infiziert
    1. Herunterladen des Originalpakets
    2. Einfügen von setup_bun.js als preinstall-Skript
    3. Hinzufügen der Payload bun_environment.js
    4. Erhöhung der Versionsnummer
    5. Erneute Veröffentlichung des infizierten Pakets auf npm

Dead Man’s Switch

  • Die Malware überwacht fortlaufend den Zugriff auf GitHub (Exfiltration) und npm (Verbreitung)
    • Wenn beide Kanäle blockiert sind, wird sofort eine Datenzerstörung ausgelöst
  • Windows: Löschen von Benutzerdateien und Überschreiben von Festplattensektoren
  • Unix-artige Systeme: Überschreiben von Dateien mit dem Befehl shred und anschließendes Löschen
  • Bei einer massenhaften Löschung von GitHub-Repositories oder einer großflächigen Sperrung von npm-Token besteht das Risiko, dass infizierte Systeme gleichzeitig Daten löschen

Kompromittierungsindikatoren (IoC)

  • Wichtige Erkennungsindikatoren
    • Datei: bun_environment.js (bösartiges Post-Install-Skript)
    • Verzeichnisse: .truffler-cache/, .truffler-cache/extract/
    • Prozesse: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
    • Befehle: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

Unterstützung von GitLab bei Erkennung und Reaktion

  • GitLab-Ultimate-Nutzer können mit integrierten Sicherheitsfunktionen sofort prüfen, ob sie betroffen sind
    • Wenn Dependency Scanning aktiviert ist, werden infizierte Pakete in package-lock.json oder yarn.lock automatisch erkannt
    • Wenn eine Merge Request infizierte Pakete enthält, wird eine Warnung angezeigt
  • In Verbindung mit GitLab Duo Chat ist eine schnelle abfragebasierte Erkennung möglich
    • Beispiel: „Gibt es Abhängigkeiten, die von der Shai-Hulud-v2-Kampagne betroffen sind?“
    • Der Security Analyst Agent greift auf die Schwachstellendaten des Projekts zu und liefert sofort eine Antwort
  • Teams, die mehrere Repositories verwalten, wird empfohlen, automatisierte Erkennung auf CI/CD-Basis mit schneller agentengestützter Reaktion zu kombinieren

Ausblick

  • Dieser Angriff wird als neue Form eines Lieferkettenangriffs bewertet, bei dem die Zerstörung von Opferdaten zum Schutz der Angreifer-Infrastruktur eingesetzt wird
  • GitLab entwickelt gemeinsam mit der Community sichere Wiederherstellungsstrategien und überwacht Varianten weiterhin mit automatisierten Erkennungssystemen
  • Ziel ist es, durch frühzeitiges Teilen von Informationen Sekundärschäden durch den Dead Man’s Switch zu verhindern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-29
Hacker-News-Kommentare

  • Vor etwa einem Monat musste ich eine lästige Aufgabe erledigen und suchte dafür ein NPM-Paket.
    Als ich brew install npm ausführte, ergoss sich ein Wasserfall von Abhängigkeiten über mich. Ich hielt kurz inne, dachte über Risiko und Nutzen nach und machte das Ganze am Ende mit brew uninstall npm wieder rückgängig.
    Stattdessen habe ich es mit einer alten Unix-Utility-Pipeline und awk gelöst, und rückblickend war das die beste Entscheidung.

    • Die Lehre ist eindeutig — Web-Technologien sollte man nicht für lokales Scripting verwenden.
      NPM ist ein Werkzeug, das gebaut wurde, um Browser-Kompatibilitätsprobleme zu lösen, und in Umgebungen ohne Browser erzeugt es nur unnötige Komplexität.
    • Genau deshalb braucht man Containerisierung oder Virtualisierung.
      Wenn man Code aus Ökosystemen mit vielen Abhängigkeiten wie Node oder Python direkt auf dem Hauptsystem ausführt, ist das Risiko hoch, Supply-Chain-Angriffen ausgesetzt zu sein.
      Deshalb installiere ich Python- oder JS-Interpreter gar nicht erst auf meinem Basissystem.
    • Ich habe npm früher auch nur innerhalb von Docker-Containern ausgeführt und wurde dafür in Foren gelegentlich ausgelacht.
      Irgendwann habe ich aufgegeben, aber jetzt scheint es, als hätte ich damals recht gehabt.
    • Ich hatte ein ähnliches Erlebnis. Als ich sah, wie viele Abhängigkeiten artillery hereinziehen wollte, habe ich sofort aufgegeben.
    • Ironischerweise sagen Entwickler immer, „gesunder Menschenverstand ist die beste Sicherheit“, installieren dann aber mit einem einzigen Befehl Unmengen unüberprüfter Pakete.

  • Es hieß einmal: „Wenn GitHub bösartige Repositories massenhaft löscht, könnten Tausende Systeme gleichzeitig Benutzerdaten zerstören.“
    Das wirkt wie eine Geiselnahme — daher kam der Witz „Dann erschießt die Geisel“.

    • Aber die Geisel, also der Benutzer, hat sich selbst in diese Gefahr begeben; letztlich ist es die Folge der eigenen Entscheidung.

  • Ich bin ebenfalls Opfer dieses npm-Angriffs.
    Ich war schockiert, als ich erfuhr, dass die GitHub-CLI OAuth-Tokens im Klartext im HOME-Verzeichnis speichert.
    Mit Zugriff darauf hätte ein Angreifer unter meinem Konto fast alles tun können.

    • Tatsächlich speichert die GitHub-CLI Tokens nur dann im Klartext, wenn kein Keyring vorhanden ist.
      Unter macOS werden sie sicher im Keychain des Betriebssystems gespeichert — zugehörige Diskussion
    • Stimmt, aber Browser-Cookie-Dateien haben ein ähnliches Problem.
      Chrome nutzt den Schutz des Betriebssystems, Firefox bislang nicht.
      Letztlich ist sandbox-basierte Zugriffskontrolle die grundlegende Lösung.
    • Alle Tokens sollten in einem geschützten Keychain liegen.
      Aber es gibt keine plattformübergreifend konsistente Lösung, und selbst unter macOS gibt es keinen perfekten Weg.
    • Ich bin auch betroffen. Nach der Installation von Backstage wurde mein System infiziert.
      Es wurde ein Verzeichnis ~/.dev-env angelegt, und mein Laptop verwandelte sich in einen GitHub-Runner.
      Dank des schreibgeschützten Dateisystems von Bluefin Linux könnte der Schaden geringer ausgefallen sein.

  • Alle geben npm die Schuld, aber auch GitHub trägt Verantwortung.
    Bösartige Repositories wurden nicht schnell genug erkannt, und das Problem mit Malware-Repositories ist schon länger gravierend.

    • Andererseits haben manche den Schaden gerade deshalb früh bemerkt, weil es auf GitHub hochgeladen wurde.
      Wäre es heimlich an einen externen Server exfiltriert worden, wäre es noch viel schlimmer gewesen.
    • Microsoft kann nicht alles herausfiltern.
      Es braucht Werkzeuge und Praktiken auf Community-Ebene.
    • Da GitHub Microsoft gehört, ist es auch mit dem GoLang-Paket-Repository verflochten.
      Wenn daraus kommerzielle Regulierung oder Einschränkungen in Build-Workflows entstehen, könnte das zu großen Problemen führen.
    • Dass beide Unternehmen nur durchschnittliche Sicherheitsniveaus haben, lässt sich kaum bestreiten.
    • Diese Malware erstellt Repositories nach demselben Muster, daher hätte man sie schon mit einfachen Regeln erkennen können.

  • Ich habe mich gefragt, warum immer NPM angegriffen wird.
    Python oder Java sind ebenfalls sehr populär, aber in letzter Zeit war es dort still.

    • Bei NPM kann über Post-Install-Hooks beliebiger Code ausgeführt werden,
      und dank der Kultur von Versionsbereichs-Abhängigkeiten verbreitet sich eine Infektion sehr schnell.
      In Java werden Versionen typischerweise fest fixiert, daher ist so etwas dort seltener.
    • Node hat eine kleine Standardbibliothek und eine starke Abhängigkeit von der Community.
      Deshalb zieht ein einziges Paket oft Dutzende transitive Abhängigkeiten nach.
    • JS ist auf GitHub die beliebteste Sprache, also ist die Angriffsfläche groß,
      und es gibt viele unerfahrene Entwickler, wodurch die Sicherheit schwächer ist.
    • Die JS-Community leidet stark unter einem Zwang zur neuesten Version.
      In anderen Sprachökosystemen wird nach Prüfung aktualisiert, in JS wird sofort upgegradet.
    • NPM hat schwache Sicherheitsgrenzen.
      Bei der Installation konnten Skripte frei ausgeführt werden; bei der JVM oder Python ist das nicht so.

  • Wenn man in .npmrc

    ignore-scripts=true

    hinzufügt, kann man den Angriffsvektor verkleinern.
    zugehöriger Artikel

    • Ich frage mich, ob es eine Möglichkeit gibt, schon vor der Installation zu prüfen, welche Pakete preinstall/postinstall-Hooks enthalten.
    • Wenn „ignore scripts“ sicherer ist, warum existiert diese Option dann überhaupt,
      und besteht beim Deaktivieren nicht die Gefahr, dass Abhängigkeiten kaputtgehen?
    • Letztlich verhindert das aber nicht, dass in einer Node-Umgebung ausgeführtes JS auf Umgebungsvariablen oder Dateien zugreifen kann.
    • Oder man nutzt einfach pnpm.

  • Das Beunruhigendste an diesem Angriff ist der Diebstahl von Zugangsdaten.
    Wenn man ein infiziertes Paket installiert hat, könnten Umgebungsvariablen oder Tokens aus .npmrc abgeflossen sein.
    Man sollte Tokens und API-Keys sofort rotieren.
    Regelmäßige Rotation ist keine Reaktion nach einer Kompromittierung, sondern eine vorbeugende Maßnahme.

    • Wenn Entwickler Passwörter wiederverwenden, ist das ein wirklich ernstes Problem.
      Zugangsdaten sollten nicht in Umgebungsvariablen oder Dateien gespeichert werden; besser sind Security Keys oder verschlüsselte Dateien.
    • Wenn man nicht weiß, ob man infiziert wurde, sollte die Reihenfolge erst Infektion erkennen → bereinigen → Tokens rotieren sein.
    • Dieser Angriff ist gefährlicher als eine bloße Infektion, weil er das gesamte Ökosystem als Geisel nimmt.
      Es ist, als würde man bösartige Transaktionen in ein verteiltes Ledger einschleusen.
    • Geheimnisse müssen unbedingt in einem Secret Locker aufbewahrt werden.
      Das Problem ist, dass viele Dienste noch immer standardmäßig Klartextspeicherung verwenden.
    • Und diese Malware versucht sogar Daten zu zerstören, sobald sich ihre Verbreitung stoppt.

  • Da sich solche Angriffe wiederholen, frage ich mich, warum KI-basierte Erkennungssysteme nicht funktionieren.
    Microsoft betont KI so stark, aber offenbar wird sie gerade nicht für GitHub-Sicherheit eingesetzt.

    • Andererseits ist die Aussage „KI hat den Angriff erkannt“ längst zu einem abgedroschenen Begriff des Security-Marketings geworden.
      So wie damals, als jeder von einer Firewall blockierte Versuch gleich als Angriff klassifiziert wurde.
    • Unser Unternehmen nutzt SonaType Lifecycle, das solche Angriffe laut Anbieter KI-basiert stoppen soll.
      Intern wird das durch den SonaType IQ Server unterstützt.
    • Die heutige „KI“ sind generative Modelle, die stärker auf Erzeugung als auf Bewertung ausgerichtet sind.
      Tatsächlich gab es beim curl-Projekt bereits Fälle von Spam mit KI-generierten Security-Reports.

  • Ich frage mich, ob es überhaupt noch einen Grund gibt, postinstall-Skripte weiter zu erlauben.
    Wäre es nicht besser, den Benutzer zu fragen, ob sie ausgeführt werden sollen?

    • Die meisten Benutzer würden aber ohnehin auf „Ja“ klicken,
      und auf CI-Servern braucht man nicht-interaktive Installationen, daher ist das praktisch wohl schwer umsetzbar.

  • Der Artikel war sehr aufschlussreich, aber schade, dass er am Ende mit Werbung für GitLab-Sicherheitsfunktionen endete.

    • Für GitLab-Nutzer könnte das dennoch nützlich gewesen sein.
    • Trotzdem schmälert das nicht die eigentliche Einsicht des Artikels.