- Bei der Sicherheit von npm geht es heute nicht mehr nur um die Behebung einzelner CVEs, sondern um das Management von Lieferkettenrisiken über weitverzweigte Abhängigkeitsstrukturen hinweg.
- Tools wie npm audit, Sperrdateien, Dependabot und CI/CD-Prüfungen arbeiten zusammen, um anfällige oder veraltete Pakete zu erkennen und zu beheben.
- Reale Angriffe wie Browser-Interceptor-Malware und der Shai-Hulud-Wurm zeigen, wie kompromittierte npm-Pakete Anmeldeinformationen stehlen oder Pipelines sabotieren können.
- Durch die Kombination von automatisiertem Scannen, starkem Account- und Geheimnismanagement sowie sorgfältiger Paketauswahl wird die Wahrscheinlichkeit erfolgreicher npm-basierter Angriffe erheblich verringert.
Wer heute etwas mit Node.js oder TypeScript entwickelt, steht auf einem riesigen Berg von npm-Abhängigkeiten, die er nicht selbst geschrieben hat und die er wahrscheinlich auch nie vollständig lesen wird. Das ist zwar unglaublich praktisch für die schnelle Bereitstellung von Funktionen, öffnet aber auch eine riesige Angriffsfläche für Bedrohungen der Lieferkette, den Diebstahl von Zugangsdaten und subtile Hintertüren, die sich in Ihre Anwendungen oder CI/CD-Pipelines einschleichen.
Moderne npm-Sicherheit beschränkt sich nicht mehr nur auf die Frage: „Gibt es bekannte CVEs in meinen Paketen?“ – es geht um Abwehr von Phishing-Kampagnen, die die Accounts von Account-Managern kapern.Würmer, die infizierte Versionen automatisch veröffentlichen, und bösartige Bibliotheken, die versuchen, die Daten eines Entwicklers zu löschen home Verzeichnisse anlegen oder Cloud-Zugangsdaten stehlen. In diesem Leitfaden erklären wir, wie das geht. npm-Sicherheitsprüfung funktioniert, wie Sie Ihre Arbeitsabläufe mit Tools wie npm audit, Dependabot, SAST/SCA-Scanner und CI/CD-Prüfungen sowie was Sie als Entwickler realistischerweise tun können, wenn Sie befürchten, dass „diese coole kleine Bibliothek Malware sein könnte“.
Warum die Sicherheit von npm-Abhängigkeiten so wichtig ist
Jedes Mal, wenn du läufst npm installSie importieren also Code von Drittanbietern in Ihr Projekt und effektiv seinen Autoren vertrauen mit einem Teil Ihrer Angriffsfläche. In Node.js kann diese Vertrauenskette überraschend tiefgreifend sein: Eine einzige Abhängigkeit auf oberster Ebene kann Hunderte von transitiven Paketen einbinden, die Sie nie direkt ausgewählt haben.
Anfällige oder vernachlässigte Abhängigkeiten können zu klassischen Sicherheitsproblemen führen, wie zum Beispiel Injection-Angriffe, Denial-of-Service-Angriffe (DoS), Rechteausweitung oder Datenexfiltration. Selbst ein kleiner Fehler in einem Low-Level-Hilfsprogramm – einem HTTP-Client, einem Farbparser, einem YAML-Loader – kann weitreichende Folgen haben, wenn er unter weit verbreiteten Frameworks und Tools liegt.
Über die traditionellen Schwachstellen hinaus muss sich das Ökosystem nun auch mit offenkundig böswilligem Verhalten auseinandersetzen: Pakete, die absichtlich so gestaltet wurden, dass sie Geheimnisse stehlenSie können Kryptomining-Code einschleusen oder CI/CD-Pipelines kompromittieren. Dies sind keine theoretischen Risiken; zahlreiche reale Vorfälle haben gezeigt, dass Angreifer es auf die Konten von Paketbetreuern abgesehen und anschließend vertrauenswürdige Pakete für ihre Zwecke missbraucht haben.
Abhängigkeiten prüfen und auf dem neuesten Stand halten Es handelt sich daher nicht um eine optionale, aber notwendige Maßnahme, sondern um einen Kernbestandteil der Wartung jedes ernsthaften Node.js- oder TypeScript-Projekts. Regelmäßige Sicherheitsüberprüfungen, sowohl automatisiert als auch manuell, sind die einzige Möglichkeit, das Risiko durch Drittanbietercode auf einem akzeptablen Niveau zu halten.
npm audit verstehen und was es tatsächlich prüft
npm audit ist der integrierte Befehl, der den Abhängigkeitsbaum Ihres Projekts anhand einer Datenbank bekannter Schwachstellen überprüft und einen Sicherheitsbericht erstellt. Wenn Sie ihn im Stammverzeichnis Ihres Projekts ausführen, untersucht npm Ihre Abhängigkeiten. package.json und Sperrdatei, erstellt den vollständigen Abhängigkeitsgraphen und gleicht jede Version mit den Empfehlungen ab.
Der Prüfbericht umfasst beides direkte und indirekte Abhängigkeiten (Die von Ihnen selbst aufgelisteten Pakete und deren Abhängigkeiten). Für jedes Problem werden das betroffene Paket, eine Zusammenfassung der Sicherheitslücke, deren Schweregrad (niedrig, mittel, hoch, kritisch) und der Versionsbereich, der die Korrektur enthält, aufgeführt.
Aus Sicht des Arbeitsablaufs, npm audit kann interaktiv genutzt werden von Entwicklern und nicht-interaktiv in CI/CD-Pipelines. In Pipelines kann man sogar erreichen, dass der Build nur dann fehlschlägt, wenn Schwachstellen einen bestimmten Schweregrad überschreiten, indem man Flags wie beispielsweise verwendet. --audit-level.
Das Werkzeug gehört zur größeren Familie der Analyse der Softwarezusammensetzung (SCA)Es konzentriert sich auf bekannte Probleme in Open-Source-Komponenten anstatt auf Fehler im eigenen Code. Das bedeutet, es ist sehr effektiv beim Aufspüren veralteter oder anfälliger Bibliotheken, erkennt aber nicht auf magische Weise brandneue Schadsoftware, die erst gestern unter einem noch nie dagewesenen Paketnamen veröffentlicht wurde.
Wie man npm audit ausführt und die Ergebnisse interpretiert
Um eine grundlegende Sicherheitsprüfung durchzuführen, öffnen Sie ein Terminal im Projektverzeichnis (wo package.json Leben) und laufen npm auditNach einer kurzen Abhängigkeitsanalyse gibt npm eine Tabelle mit Problemen aus, gruppiert nach Schweregrad, zusammen mit Vorschlägen zur Behebung, wie z. B. einem Upgrade auf eine gepatchte Version.
Die Prüfergebnisse enthalten typischerweise den Paketnamen, die installierte Version, die Beschreibung der Schwachstelle und Schweregrad (niedrig, mittel, hoch, kritisch)Zusätzlich sollten die Pfade angegeben werden, die zeigen, wo im Abhängigkeitsbaum das Paket verwendet wird, sowie eine empfohlene feste Version oder ein Versionsbereich. Betrachten Sie dies wie eine priorisierte Aufgabenliste: Beginnen Sie mit den kritischen und wichtigen Aufgaben und arbeiten Sie sich dann nach unten vor.
Wenn Sie die Ergebnisse in andere Tools einlesen oder für später speichern möchten, können Sie die JSON-Ausgabe anfordern über npm audit --jsonDas ist besonders praktisch bei der Integration mit benutzerdefinierten Dashboards, Ticketsystemen oder Sicherheitsorchestrierungsplattformen.
In CI/CD-Pipelines konfigurieren viele Teams die Pipeline so, dass sie ausgeführt wird npm audit --json Direkt nach der Installation der Abhängigkeiten wird das Ergebnis analysiert und der Build fehlgeschlagen, falls eine Sicherheitslücke oberhalb eines festgelegten Schweregrades vorhanden ist. Externe Hilfsfunktionen wie audit-ci Diese Logik kann für Sie kapseln und Ihnen komfortable Optionen bieten, um Builds abzubrechen, wenn Schwellenwerte überschritten werden.
Behebung von Sicherheitslücken mit npm audit fix
Sobald npm audit Bei Flaggenproblemen ist Ihre erste Verteidigungslinie npm audit fix, das versucht, anfällige Abhängigkeiten automatisch auf die nächstliegenden sicheren Versionen zu aktualisieren. Im Hintergrund wird der Code umgeschrieben. package-lock.json (und package.json (sofern zutreffend) Pakete innerhalb kompatibler Versionsbereiche aktualisieren.
Diese automatische Behebung funktioniert gut bei vielen leichten und mittelschweren Problemen und sogar bei einigen schwerwiegenderen Problemen, deren Lösung ein kleineres Update oder ein Patch ist. Es ist eine schnelle Lösung, die oft einen Großteil des Problemrückstands mit minimalem Aufwand beseitigt.
Nicht jede Sicherheitslücke lässt sich durch ein automatisches Upgrade sicher beheben; manche erfordern größere Versionsänderungen, die Ihren Code oder andere Abhängigkeiten beeinträchtigen können. Genau da setzt das Problem an. npm audit fix --force Hier kommt es darauf an: Es erzwingt Aktualisierungen selbst bei grundlegenden Änderungen, aber man sollte es mit Vorsicht einsetzen und anschließend immer gründlich testen.
Bevor Sie in wichtigen Projekten die Option „Erzwingen“ anwenden, sollten Sie Ihre Sperrdatei sichern und eine gute Testabdeckung gewährleisten. Ein erzwungenes Upgrade kann Verhaltensänderungen oder Regressionen hervorrufen, die schwerer zu finden sind, wenn Sie keine Vergleichsbasis haben.
Sperrdateien, npm CI und deterministische Installationen
Das package-lock.json Datei (oder yarn.lock/pnpm-lock.yaml (für andere Manager) ist aus Sicherheitsgründen unerlässlich, da es die exakten Versionen aller von Ihrem Projekt verwendeten Abhängigkeiten festlegt. Ohne diese Einstellung würde jede Abhängigkeit nicht korrekt erkannt. npm install Es können leicht unterschiedliche kompatible Versionen verwendet werden, was die Builds nicht deterministisch macht und die Überprüfung erschwert.
Sie sollten Bearbeitungen vermeiden. package-lock.json Manuelles Hinzufügen und stattdessen npm die Verwaltung überlassen, wenn Sie Abhängigkeiten hinzufügen, entfernen oder aktualisieren. Beim Einchecken von Code sollten Sie immer beides angeben. package.json und die Sperrdatei, damit alle – und Ihre CI/CD-Pipeline – die gleichen Versionen installieren.
In automatisierten Umgebungen bevorzugen npm ci übrig npm install weil npm ci Die Sperrdatei dient als strikter Vertrag, und die Ausführung wird verweigert, wenn sie nicht mit den deklarierten Abhängigkeiten übereinstimmt. Dies führt zu schnelleren und vollständig reproduzierbaren Installationen – genau das, was man in CI-Umgebungen benötigt.
Aus Sicht der Lieferkettensicherheit bedeutet das Sperren und Reproduzieren von Installationen, dass Sie genau wissen, welche Versionen für einen bestimmten Build verwendet wurden. Dies ist entscheidend, um zu untersuchen, ob eine schädliche Version in Ihre Pipeline gelangt ist. Bei Bedarf können Sie Builds mithilfe historischer Sperrdateien wiederholen, um festzustellen, ob eine anfällige oder mit einer Hintertür versehene Version im Einsatz war.
Automatisierte Updates mit Dependabot, Renovate und npm-Tools
Die manuelle Nachverfolgung veralteter oder anfälliger Pakete in vielen Repositories wird schnell unüberschaubar, weshalb die Automatisierung mithilfe von Tools wie Dependabo Oder Renovate ist so wertvoll. Diese Dienste überwachen Ihre Abhängigkeiten und öffnen Pull-Anfragen, wenn neue Versionen oder Sicherheitskorrekturen verfügbar sind.
Der Dependabot von GitHub wird beispielsweise über einen konfiguriert .github/dependabot.yml Eine Datei, die festlegt, welche Ökosysteme überwacht werden sollen, die Aktualisierungshäufigkeit und die Zielbranches. Wenn ein anfälliges oder veraltetes npm-Paket erkannt wird, wird ein Pull Request zur Aktualisierung erstellt. package.json kombiniert mit einem nachhaltigen Materialprofil. package-lock.json, oft mit Links zu Warnhinweisen.
Gepaart mit npm auditSo entsteht ein effektiver Feedback-Kreislauf: Das Audit identifiziert Probleme, und Dependabot (oder Renovate) schlägt kontinuierlich Verbesserungen zur Behebung dieser Probleme vor. Ihre Aufgabe beschränkt sich dann auf die Überprüfung und das Testen dieser Pull Requests, anstatt jede einzelne Versionsänderung manuell zu suchen.
Über die Automatisierung hinaus bietet npm selbst Hilfsbefehle wie zum Beispiel npm outdated um Pakete mit neueren Versionen aufzulisten und npm update Um innerhalb der zulässigen Versionsbereiche zu aktualisieren, sollten Sie regelmäßig Upgrades durchführen. Dadurch verringert sich das Risiko, dass Sie den Anschluss verlieren und mehrere Hauptversionen auf einmal überspringen müssen.
Sicherheitsprüfungen in CI/CD-Pipelines durchführen
Eine sichere npm-Konfiguration endet nicht auf Ihrem Laptop; Ihre CI/CD-Pipelines müssen ebenfalls Sicherheitsprüfungen durchführen, um zu verhindern, dass anfälliger oder schädlicher Code in die Produktionsumgebung gelangt. Jede Phase – Quellcode, Build, Test, Deployment – sollte über entsprechende Kontrollmechanismen verfügen.
Es ist üblich zu laufen npm audit automatisch während der Build- oder Vorbereitungsphase, oft mit dem --json Dieses Kennzeichen dient der einfacheren Integration mit Überwachungstools. Wenn der Scan Schwachstellen oberhalb Ihres Risikoschwellenwerts erkennt, kann die Pipeline fehlschlagen und die Veröffentlichung blockieren.
Erweiterte Tools wie Snyk Sie können als Sicherheitswächter in CI/CD fungieren, indem sie Abhängigkeiten scannen und Builds bei schwerwiegenden oder kritischen Problemen abbrechen. In Kombination mit Qualitätsanalysetools wie SonarQube oder SonarCloud erhalten Sie ein umfassenderes Bild der Codequalität, der Sicherheitsrisiken und der technischen Schulden.
Während der Entwicklung werden statische Analysetools wie ESLint mit Plugins wie eslint-plugin-security kombiniert mit einem nachhaltigen Materialprofil. eslint-plugin-node Sie hilft Ihnen, unsichere Muster frühzeitig in Ihrem eigenen Code zu erkennen. Dies ergänzt die Abhängigkeitsprüfung, die sich auf Drittanbieterkomponenten anstatt auf Ihre Geschäftslogik konzentriert.
Absicherung von CI/CD-Pipelines über npm-Audit hinaus
Automatisierte Scans sind zwar leistungsstark, doch eine sichere Pipeline benötigt auch ein solides Geheimnismanagement, robuste Zugriffskontrolle und eine gute Repository-Pflege. Falsch konfigurierte Geheimnisse oder zu permissive Rollen können aus einer kleineren Sicherheitslücke einen schwerwiegenden Vorfall machen.
Verwenden Sie spezielle Geheimnismanager wie z. B. HashiCorp-Tresor Alternativ kann AWS Secrets Manager verwendet werden, anstatt Token oder Schlüssel in Konfigurationsdateien oder Umgebungsvariablen einzubetten, die in die Quellcodeverwaltung eingecheckt werden. Dadurch wird das Risiko verringert, dass ein Angreifer oder auch nur ein neugieriger Mitwirkender auf sensible Daten in Ihrem Repository stößt.
Rollenbasierte Zugriffskontrolle (RBAC) nach dem Prinzip der minimalen Berechtigungen ist für GitHub, npm und jede CI/CD-Plattform unerlässlich. Entwickler und Servicekonten sollten nur die unbedingt notwendigen Berechtigungen besitzen – nicht mehr.
Pre-Commit-Hooks und Tools zum Scannen geheimer Daten verhindern, dass API-Schlüssel, Token oder Passwörter überhaupt erst in Ihre Repositories gelangen. In Kombination mit strukturierten GitOps-Workflows und geschützten Branches bieten sie eine lückenlose Nachverfolgung und reduzieren das Risiko, dass ungeprüfte Änderungen zusammengeführt werden.
Benachrichtigungen Ihrer Sicherheitstools sollten in Echtzeitkanäle wie Slack, Microsoft Teams oder E-Mail integriert werden, jedoch sorgfältig abgestimmt sein, damit Ihr Team nicht mit unnötigen Warnmeldungen überlastet wird. Priorisierung nach Schweregrad und Kontext lenkt die Aufmerksamkeit auf das, was wirklich zählt.
Reale npm-Lieferkettenangriffe und was wir daraus lernen
In den letzten Jahren kam es bei npm zu mehreren aufsehenerregenden Lieferkettenvorfällen, bei denen Angreifer nicht einzelne Anwendungen, sondern die Entwickler oder Pakete ins Visier nahmen. Diese Angriffe verdeutlichen, wie sich ein einziges kompromittiertes Konto auf Millionen von nachgelagerten Installationen auswirken kann.
In einer Kampagne erhielt ein bekannter npm-Maintainer eine sorgfältig gestaltete Phishing-E-Mail von einer Domain, die der offiziellen npm-Website täuschend ähnlich sah. Die Nachricht drohte mit der Sperrung des Kontos, falls die Zwei-Faktor-Authentifizierung nicht „aktualisiert“ würde, und lockte das Opfer auf eine gefälschte Anmeldeseite, die die Zugangsdaten abfing.
Nachdem der Angreifer die Kontrolle über das npm-Konto des Entwicklers erlangt hatte, verbreitete er manipulierte Versionen von 18 extrem populären Paketen mit Milliarden von wöchentlichen Downloads. Da diese Pakete tief in die Abhängigkeitsstruktur des JavaScript-Ökosystems eingebunden waren, war das potenzielle Schadensausmaß enorm.
Der eingeschleuste Code verhielt sich wie ein browserseitiger Interceptor, der auf Kryptowährungs- und Web3-Aktivitäten abzielte: Er hakte sich in Browser-APIs ein, wie zum Beispiel fetch, XMLHttpRequest und Wallet-Schnittstellen wie window.ethereum oder Solana Wallet-APIs. Es durchsuchte Netzwerkantworten und Transaktionsnutzdaten nach allem, was wie eine Kryptoadresse oder -überweisung aussah.
Sobald die Schadsoftware eine Transaktion erkannte, ersetzte sie die legitime Empfängeradresse durch eine vom Angreifer kontrollierte Adresse. Dabei wählte sie häufig ähnlich aussehende Zeichenketten, um keinen Verdacht zu erregen. In vielen Fällen schien die Benutzeroberfläche weiterhin die „korrekte“ Adresse anzuzeigen, obwohl die zugrundeliegenden signierten Daten bereits so verändert worden waren, dass die Gelder an den Angreifer flossen.
Der Schadcode war stark verschleiert, mit Variablen wie _0x... und große, kodierte Zeichenkettenarrays, die zur Laufzeit dekodiert wurden, und manchmal wurden gefälschte Erfolgsmeldungen zurückgegeben, um zu verhindern, dass die Anwendung einen Fehler bemerkte. Nur bestimmte Apps waren tatsächlich angreifbar – insbesondere solche, die mit Wallets oder Kryptodiensten interagierten und die betroffenen Versionen innerhalb des kurzen Zeitfensters für die Kompromittierung installierten.
Lehren aus diesem Browser-Interceptor-Vorfall
Eine wichtige Lehre daraus ist, dass Entwickler bereit sein sollten, bei Bekanntwerden einer Paketkompromittierung schnell auf bekannte, sichere Versionen zurückzugreifen. Selbst wenn die Registry schädliche Versionen entfernt, können Ihre Sperrdateien und Caches weiterhin darauf verweisen, bis Sie explizit ein Downgrade oder Upgrade durchführen.
Eine gründliche Inspektion von package.json kombiniert mit einem nachhaltigen Materialprofil. package-lock.json (oder yarn.lockEs ist unerlässlich zu überprüfen, ob Ihr Projekt jemals die schädlichen Versionen installiert hat. Hier erweisen sich deterministische Installationen und versionsgebundene Sperrdateien als äußerst hilfreich und erleichtern die forensische Arbeit erheblich.
Wenn Ihre Anwendung mit Krypto-Wallets oder Web3-APIs interagiert, sollten Sie die Transaktionsprotokolle genau auf anomale Ziele oder unerwartete Genehmigungen in dem Zeitraum überwachen, in dem kompromittierte Pakete vorhanden waren. Eine frühzeitige Erkennung kann den finanziellen Schaden begrenzen und dabei helfen, betroffene Nutzer zu identifizieren.
Die Erhöhung der Kontosicherheit durch Zwei-Faktor-Authentifizierung, idealerweise über Hardware-Schlüssel, ist für npm- und GitHub-Konten unerlässlich – insbesondere für die Betreuer populärer Pakete. Seien Sie dennoch stets skeptisch gegenüber E-Mails, die Sie auffordern, auf einen Link zu klicken, um Ihre Zugangsdaten zu „aktualisieren“. Rufen Sie stattdessen direkt die offizielle Website auf und prüfen Sie dort auf Warnmeldungen.
Organisationen, die kommerzielle SCA- und SBOM-Tools einsetzen, können ihre Bestände häufig anhand von Paketnamen und Versionen abfragen, um alle Systeme und Anwendungen zu finden, die von einer kompromittierten Bibliothek abhängen. Diese Transparenz verkürzt die Reaktionszeiten bei Lieferkettenvorfällen erheblich.
Der Shai-Hulud-Wurm: selbstreplizierende npm-Malware
Eine weitere bemerkenswerte Kampagne, die den Spitznamen „die“ trägt. Shai-Hulud-Kampagne, hob npm-Lieferkettenangriffe auf eine neue Ebene, indem es sich wie ein sich selbst replizierender Wurm über Pakete und Entwicklungsumgebungen hinweg verhielt. Es missbrauchte npm-Installationsskripte, um bösartigen Code auszuführen, sobald eine kompromittierte Version installiert war.
Die Malware durchsuchte die Umgebung nach sensiblen Anmeldeinformationen, einschließlich .npmrc Dateien mit npm-Tokens, persönlichen GitHub-Zugriffstokens, SSH-Schlüsseln und Cloud-Anbieter-API-Schlüsseln für AWS, GCP und Azure. Alles, was es fand, wurde exfiltriert. zur vom Angreifer kontrollierten Infrastruktur.
Mithilfe gestohlener npm-Tokens authentifizierte sich der Wurm als kompromittierte Paketbetreuer, listete weitere von ihnen verwaltete Pakete auf, injizierte seine Schadsoftware und veröffentlichte anschließend neue, bösartige Versionen. Diese Automatisierung ermöglichte eine schnelle Verbreitung, ohne dass der Angreifer jedes Paket manuell bearbeiten musste.
In vielen Fällen wurden die gestohlenen Geheimnisse in neu erstellten öffentlichen GitHub-Repositories unter dem Konto des Opfers veröffentlicht, mit Namen oder Beschreibungen, die auf Shai-Hulud Bezug nahmen. Dadurch wurde das Problem noch verschärft, da sensible Daten für jeden zugänglich waren, der zufällig auf diese Repositories stieß.
Sicherheitsforscher entdeckten verräterische Anzeichen (darunter merkwürdige Kommentare und sogar Emojis), die darauf hindeuten, dass Teile der schädlichen Bash-Skripte mithilfe großer Sprachmodelle generiert wurden. Dies ist ein drastisches Beispiel dafür, wie generative KI missbraucht werden kann, um die Entwicklung von Angriffswerkzeugen zu beschleunigen.
Shai-Hulud 2.0: Sabotage vor der Installation und destruktive Rückfallmechanismen
Eine spätere Welle, Shai-Hulud 2.0 genannt, änderte ihre Taktik und führte die Skripte während der Vorinstallationsphase anstatt nach der Installation aus, wodurch ihre Reichweite auf Entwicklerrechnern und CI/CD-Servern erheblich erweitert wurde. Vorinstallationsskripte werden noch früher im Lebenszyklus ausgeführt und können auf mehr Systemen aktiviert werden.
Einer der alarmierendsten Aspekte dieser Variante war ein Ausweichmechanismus: Wenn es der Schadsoftware nicht gelang, nützliche Zugangsdaten zu stehlen oder einen Kommunikationskanal herzustellen, versuchte sie destruktives Verhalten wie beispielsweise das Opfer abwischen home VerzeichnisDies geschah durch Überschreiben und sicheres Löschen aller beschreibbaren Dateien, die dem aktuellen Benutzer in diesem Verzeichnis gehörten.
Die Nutzlast war als hilfreiche Bun-Installationsskripte getarnt, wie zum Beispiel setup_bun.js und ein riesiges, stark verschleiertes bun_environment.js Die Datei war größer als 9 MB. Um keine Aufmerksamkeit zu erregen, wurde die Hauptlogik in einen Hintergrundprozess ausgegliedert, sodass die ursprüngliche Installation scheinbar normal abgeschlossen wurde.
Die im Rahmen dieser Kampagne gesammelten Zugangsdaten und Geheimnisse wurden erneut nach GitHub exfiltriert, diesmal in Repositories mit der Bezeichnung „Sha1-Hulud: The Second Coming“. Die Malware versuchte, sich durch die Erstellung von GitHub Actions-Workflows wie beispielsweise … dauerhaft einzunisten. discussion.yamlDiese Arbeitsabläufe registrierten infizierte Rechner als selbstgehostete Runner, wodurch Angreifer beliebige Befehle auslösen konnten, indem sie einfach Diskussionen eröffneten.
Das Ausmaß war enorm und betraf Zehntausende von Repositories sowie mehr als 25 schädliche Repositories auf Hunderten von GitHub-Konten, darunter auch beliebte Bibliotheken wie @ctrl/tinycolor mit Millionen von Downloads pro Woche. Da das Ziel auch den Diebstahl von Zugangsdaten für Cloud-Plattformen umfasste, könnten die Folgen von Datendiebstahl und Ransomware bis hin zu Kryptomining und weitreichenden Dienstausfällen reichen.
Sofortige Abwehrmaßnahmen gegen npm-Lieferkettenwürmer
Bei Kampagnen wie Shai-Hulud empfehlen Incident Responder, alle Anmeldeinformationen auf Entwicklerebene sofort zu rotieren – npm-Tokens, GitHub PATs, SSH-Schlüssel und alle Cloud-API-Schlüssel, die auf Entwicklerrechnern oder Build-Servern verwendet werden. Gehen Sie davon aus, dass alles, was sich auf einer kompromittierten Workstation befindet, möglicherweise ausgelaufen ist..
Eine vollständige Abhängigkeitsprüfung aller Projekte ist unerlässlich; hierfür können Tools wie beispielsweise … verwendet werden. npm audit, SBOM-Inventare oder kommerzielle SCA-Plattformen, um jegliche Verwendung der betroffenen Paketnamen und -versionen zu ermitteln. Sperrdateien (package-lock.json, yarn.lock) die tatsächliche Realität dessen zu ermitteln, was tatsächlich installiert wurde.
Entwickler sollten ihre GitHub-Konten auf ungewöhnliche öffentliche Repositories (insbesondere solche mit dem Namen Shai-Hulud), verdächtige Commits oder unerwartete Änderungen an GitHub Actions-Workflows überprüfen, die möglicherweise nicht autorisierte Runner registriert haben. Jegliche Anomalien sollten als Anzeichen einer Kompromittierung behandelt werden.
Die Durchsetzung der Multi-Faktor-Authentifizierung für alle Entwicklerkonten – nach Möglichkeit mit phishingresistenten Methoden – ist ein weiterer unabdingbarer Schritt. Sie beseitigt zwar nicht das Risiko, erhöht aber die Hürden für Angreifer, die versuchen, Zugangsdaten zu stehlen.
Organisationen, die fortschrittliche Plattformen zur Bedrohungsanalyse nutzen, können auch benutzerdefinierte Abfragen verwenden, um nach bekannten Indikatoren wie Anrufen bei bestimmten Diensten zu suchen. webhook.site URLs, Vorhandensein von Dateien wie shai-hulud-workflow.yml oder verdächtig groß bun_environment.js Dateien, die auf Entwicklerrechnern geschrieben werden. Eine frühzeitige Erkennung durch Telemetriedaten kann die Verweildauer drastisch reduzieren.
Wie die Anbieter reagieren: Erkennungs- und Präventionsfähigkeiten
Sicherheitsanbieter aktualisieren ihre Produkte, um npm-basierte Lieferkettenangriffe sowohl auf Endgeräten als auch im Netzwerk zu erkennen und zu blockieren. Dies umfasst Signaturen für bekannte Schadsoftware und Verhaltensmodelle für ungewöhnliche Prozess- oder Dateiaktivitäten während der Installation.
Fortschrittliche Sandboxing- und Malware-Analyse-Dienste können verschleierte JavaScript-Payloads, wie sie beispielsweise in den Shai-Hulud-Kampagnen verwendet wurden, erkennen. Wenn diese Tools verdächtige Skripte vor oder nach der Installation entdecken, die versuchen, Anmeldeinformationen abzufangen oder Dateien zu zerstören, geben sie Warnungen aus oder blockieren die Ausführung.
Firewalls der nächsten Generation mit fortschrittlicher Bedrohungsabwehr und URL-Filterung können helfen, indem sie den Zugriff auf schädliche Domains blockieren, die beim Phishing oder Datenexfiltration verwendet werden – beispielsweise gefälschte npm-Support-Domains oder bestimmte webhook.site Endpunkte sind fest in die Malware einprogrammiert. Durch die Einstufung dieser URLs als schädlich wird verhindert, dass die Nutzlast gestohlene Daten erfolgreich sendet..
Endpoint Detection and Response (EDR/XDR)-Agenten tragen dazu bei, indem sie das Prozessverhalten, die Skriptausführung und die Erstellung ungewöhnlicher Dateien (wie z. B. riesige Dateien) überwachen. bun_environment.js Dateien) und verdächtige Befehlszeilen. Sie können sowohl bekannte Hashes als auch bisher unbekannte Varianten anhand von Verhaltensregeln stoppen.
Cloud-native Anwendungssicherheitsplattformen integrieren zunehmend Funktionen mit Fokus auf die Lieferkette, wie z. B. Echtzeit-SBOM-Transparenz, Risikobewertung für Open-Source-Komponenten und CI/CD-Fehlkonfigurationsprüfungen (fehlende Sperrdateien, unsichere Konfigurationen). npm install Nutzung, Git-basierte Abhängigkeiten ohne festgelegte Commit-Hashes, ungenutzte Abhängigkeiten, die die Angriffsfläche vergrößern). Diese Kontrollen erschweren es, dass bösartige oder ungeprüfte Paketversionen in Produktions-Builds gelangen.
Praktische Gewohnheiten für Entwickler, die sich Sorgen um bösartige npm-Pakete machen
Wenn Sie neu in der Welt von JavaScript/TypeScript sind und sich bei der Installation von npm-Paketen jedes Mal unsicher fühlen, sind Sie nicht allein. Es gibt jedoch konkrete Gewohnheiten, die Sie sich aneignen können, um das Risiko zu minimieren, ohne Ihre Produktivität einzuschränken. Betrachten Sie sie als eine Art persönliche Sicherheitscheckliste.
Erstens, bevorzugen Sie Bewährte Softwarepakete mit einer soliden WartungshistorieEin aktives Issue-Tracking und die breite Anwendung, insbesondere für Kerninfrastruktur wie HTTP-Clients, Logging oder Kryptografie, garantieren zwar keine absolute Sicherheit, führen aber in der Regel zu mehr Kontrollen des Codes und einer schnelleren Fehlererkennung.
Bei kleinen oder wenig bekannten Paketen (insbesondere solchen mit kaum Downloads) sollten Sie genauer hinschauen: Prüfen Sie die npm-Seite, die Repository-Links, das Datum der letzten Veröffentlichung und ob der/die Verantwortliche eindeutig identifizierbar ist. Seien Sie vorsichtig, wenn das npm-Paket auf ein GitHub-Repository verlinkt, das nicht den veröffentlichten Code enthält oder noch auf ein nicht zugehöriges Upstream-Repository verweist.
Untersuchen Sie nach Möglichkeit das veröffentlichte Paketarchiv (Tarball) und nicht nur das Quellcode-Repository, da Angreifer eine andere Version an npm senden können als die, die auf GitHub erscheint. Tools wie npm pack In Kombination mit einer manuellen Überprüfung (selbst wenn der Code transpiliert oder minimiert wurde) können offensichtliche Warnsignale wie seltsame Installationsskripte, verschleierte Blobs oder unerwartete Netzwerkaufrufe aufgedeckt werden.
Bei TypeScript-Bibliotheken, die lediglich Typdefinitionen und minimierten JavaScript-Code ausliefern, ist eine schnelle manuelle Prüfung schwieriger. Daher empfiehlt es sich, diese nur in einer strikten Sandbox zu verwenden oder sie, falls sie für den eigenen Stack kritisch werden, zu forken und aus dem Quellcode neu zu kompilieren. In manchen sicherheitskritischen Umgebungen entscheiden sich Teams nach gründlicher Prüfung tatsächlich dafür, Abhängigkeiten in private Registries auszulagern.
Machen Sie npm-Sicherheit zu einer Routine und nicht zu einer Notfallübung: Führen Sie aus npm audit Bereinigen Sie regelmäßig nicht benötigte Abhängigkeiten, halten Sie Ihre Sperrdateien aktiv und integrieren Sie SCA/SAST-Prüfungen in Ihre CI/CD-Pipeline. In Kombination mit sorgfältiger Kontoverwaltung und einem verantwortungsvollen Umgang mit Geheimnissen bieten diese Maßnahmen zwar keinen absoluten Schutz, reduzieren aber das Risiko, dass eine zufällige npm-Installation Ihre Systeme unbemerkt kompromittiert, drastisch.
