In den letzten Tagen wurden mehrere Supply-Chain-Angriffe auf npm-Packages bekannt. Dabei wurden bösartige Versionen so in den Software-Lieferweg eingeschleust, dass sie Entwicklungs- und IT-Umgebungen von Organisationen beeinträchtigen können. Besonders kritisch: Es geht nicht nur um npm, sondern auch um kompromittierte Python-Packages, auf die Angreifer im Anschluss abzielen können.
Wenn Ihre Organisation Software entwickelt und dabei externe npm- oder Python-Bibliotheken nutzt, sollten Sie jetzt prüfen, reagieren und zukünftige Risiken aktiv reduzieren. Im Folgenden finden Sie die wichtigsten Punkte aus der Warnung und praxisnahe Handlungsoptionen.
Was sind gecompromittierte npm- und Python-Packages?
Bei einem Supply-Chain-Angriff versuchen Angreifer, sich über legitime Software-Komponenten Zugang zu verschaffen. In diesem Fall wurden npm-Pakete manipuliert, sodass eine scheinbar normale Aktualisierung oder Installation in Wahrheit schädlichen Code mitbringt. Sobald eine Organisation eine solche Version übernimmt, können Angreifer in der Folge Authentifizierungsdaten aus Entwicklungsumgebungen auslesen oder weiterverwenden.
Der Alarm umfasst dabei sowohl direkt betroffene npm-Bausteine als auch die anschließende Kompromittierung von Python-Packages. Dadurch entsteht eine Kettenreaktion: Ein Einstieg über den JavaScript-/Node.js-Ökosystemweg kann später auch den Python-Bereich erreichen.
Wie laufen solche Angriffe typischerweise ab?
Ein wiederkehrendes Muster ist, dass Angreifer eine legitime Komponente missbrauchen. Statt ihre Software offen zu verbreiten, integrieren sie die schädliche Funktion in Pakete, die Entwicklerinnen und Entwickler gewöhnlich installieren.
In der Warnung werden zwei zentrale Beispiele genannt:
- Angriff über ein Security-Tool (Trivy): Angreifer sollen unbefugten Zugriff auf die Entwicklungsumgebung einer Komponente erlangt haben, die unter anderem für Security-Scans genutzt wird. Anschließend wurde eine bösartige Version verteilt, die Zugriff auf sensible Authentifizierungsdaten ermöglicht. Zudem wurden Backdoors installiert, um entfernte Kommandos auszuführen.
- Angriff über die HTTP-Bibliothek (axios): Zusätzlich wurde bekannt, dass das npm-Paket axios kompromittiert war. Auch hier galt: schädlicher Code wurde in eine legitime Package-Änderung eingebettet, die dann als Update weitergegeben wurde.
In Kombination damit wird beschrieben, dass nach dem initialen Zugriff malware Daten exfiltrieren und anschließend weitere Pakete kompromittieren kann. Dadurch kann sich die Reichweite erhöhen, selbst wenn zunächst nur wenige Bibliotheken im Blick waren.
Welche konkreten Beispiele werden genannt?
Trivy: bösartige Versionen und Zugriff auf Auth-Daten
Für Trivy wird berichtet, dass Angreifer auf eine unautorisierte Weise auf die Entwicklungsumgebung zugreifen konnten und danach eine manipulierte Version verbreiteten. Ziel war es, Zugriff auf authentifizierungsbezogene Informationen zu erlangen. Außerdem wurden Mechanismen eingesetzt, mit denen sich auf kompromittierten Systemen entfernte Kommandos ausführen lassen.
Im Anschluss wird außerdem ein Vorgehen erwähnt, bei dem über erlangte Authentifizierungsdaten weitere Komponenten angegriffen bzw. verteilt werden.
CanisterWorm: Exfiltration und Ausbreitung über weitere Pakete
Die Warnung beschreibt eine Malware, die eigenständig Authentifizierungsdaten aus Entwicklungsumgebungen extrahiert. Danach versucht sie, zusätzliche npm- und PyPI-Komponenten zu kompromittieren. Laut den genannten Informationen wurden dabei in einem Zeitraum mindestens dutzende npm-Packages so beeinflusst; die tatsächliche Zahl dürfte sogar deutlich höher liegen.
Zusätzlich werden Python-Packages wie LiteLLM und Telnyx als mögliche betroffene Beispiele im gleichen Kontext erwähnt.
axios: Manipulierte Versionen mit Fernzugriff
Für axios wird beschrieben, dass bestimmte Versionen kompromittiert waren. Auch hier ist das Prinzip entscheidend: Schadcode wurde als Bestandteil einer scheinbar normalen Bibliotheksaktualisierung ausgeliefert, sodass Updates wie gewohnt weiterverbreitet werden.
Warum ist das Risiko so hoch?
Wenn in Ihrer Software gecompromittierte npm- oder Python-Packages eingesetzt werden, können Angreifer an Authentifizierungsdaten gelangen. Mit diesen Informationen erhalten sie typischerweise Zugang zu weiteren (Entwicklungs-)Umgebungen oder Systemen im Netzwerk.
Doch die Gefahr endet nicht beim Backend: Auch Nutzerinnen und Nutzer der resultierenden Software können betroffen sein, etwa wenn Backdoors oder andere schädliche Funktionen in die veröffentlichte Anwendung gelangen.
Das NCSC nennt außerdem Indikationen, dass die gewonnenen Zugriffe zur Exfiltration von (sensiblen) Daten genutzt werden. Damit steigt das Risiko für Folgeangriffe wie Erpressung oder das Weiterverkaufen kompromittierter Daten an andere Kriminelle, die anschließend die darin enthaltenen Zugangsdaten für neue Angriffe missbrauchen können.
Woran sollten Sie Ihre Umgebung prüfen?
Die Warnung enthält konkrete Hinweise, mit denen Sie zumindest einen ersten Abgleich durchführen können. Wichtig: Auch wenn Sie die genannten Pakete nicht verwenden, kann es sein, dass Angreifer über andere kompromittierte Abhängigkeiten Zugang erhalten haben.
Prüfen Sie auf die genannten Pakete und Versionen
Kontrollieren Sie Ihre Entwicklungsumgebung auf das Vorhandensein folgender Pakete:
- Trivy Version 0.69.4
- axios Versionen 1.14.1 und 0.30.4
Wenn diese Versionen bei Ihnen vorkommen, kann das ein Hinweis auf eine mögliche Kompromittierung sein.
Achten Sie auch auf Indicators of Compromise (IOCs)
Zusätzlich sollten Sie nach Indicators of Compromise (IOCs) in Ihrer Umgebung suchen. Verschiedene Sicherheitsanbieter haben dazu Informationen veröffentlicht. Das Auftreten solcher IOCs kann ein starkes Signal für eine mögliche Beeinträchtigung sein – auch dann, wenn die oben genannten Pakete nicht unmittelbar genutzt werden.
Was tun, wenn Sie Hinweise auf eine Kompromittierung finden?
Wenn Sie Indizien entdecken, sollten Sie nicht abwarten. Starten Sie stattdessen ein strukturiertes Vorgehen, um Ausmaß und Impact zu klären.
- Incident-Response-Prozess starten: Aktivieren Sie Ihr IR-Verfahren. Falls nötig, ziehen Sie eine spezialisierte Dienstleistung hinzu, um Umfang und Auswirkungen zu untersuchen.
- Credentials rotieren: Ersetzen Sie alle Authentifizierungsdaten, Tokens und weiteren Geheimnisse, auf die Angreifer möglicherweise Zugriff hatten.
- Kunden informieren (falls relevant): Wenn Ihre Software Auswirkungen auf externe Parteien haben könnte, informieren Sie Ihre Kundschaft, damit diese ebenfalls geeignete Schritte einleiten kann.
Diese Maßnahmen reduzieren die Wahrscheinlichkeit, dass gestohlene Zugänge weiter missbraucht werden, und helfen, die Verbreitung von Schadwirkungen einzudämmen.
So beugen Sie zukünftigen Angriffen vor
Neben der unmittelbaren Reaktion empfiehlt die Warnung mehrere technische und organisatorische Maßnahmen. Ziel ist, die Chancen für das Nachladen manipulierte Komponenten zu verringern und verdächtige Aktivitäten früh zu erkennen.
Schützen Sie die Abhängigkeitskette
- Versionen fixieren (Version Pinning): Verwenden Sie Version-Pinning, wenn Sie externe Libraries nutzen. Wo möglich, sollten Hashes statt nur Versionsnummern verwendet werden, um die Integrität besser zu prüfen.
- Dependency-Cooldown einführen: Führen Sie kritische Sicherheitsupdates zügig ein. Für reguläre Dependency-Updates kann eine kurze Abkühlphase helfen, um Risiken durch frisch kompromittierte Releases zu senken.
Installationsmechanismen absichern
- Postinstall-Skripte reduzieren oder deaktivieren: Nutzen Sie Optionen, um Installationsskripte zu unterdrücken (beispielsweise über geeignete Parameter beim npm-Zugriff).
In CI/CD gezielt scannen
- Scannen in CI/CD-Umgebungen: Setzen Sie geeignete Prüflösungen ein, die Updates und Pakete auf verdächtige Inhalte oder unerwartete Änderungen untersuchen.
Nur vertrauenswürdige Quellen verwenden
- Trusted Publishers nutzen: Beziehen Sie Pakete vorzugsweise über vertrauenswürdige Veröffentlichungsmechanismen.
- npm audit verwenden: Prüfen Sie mithilfe von npm audit die Authentizität und Sicherheitslage von Paketen.
Publishing-Authentisierung modernisieren
- npm Trusted Publishing mit OpenID Connect (OIDC): Die Warnung empfiehlt, statt eines fest verwendeten Publish-Tokens einen OIDC-basierten Ansatz zu nutzen. Das reduziert das Risiko, dass langfristige Tokens gestohlen oder missbraucht werden.
Fazit: Jetzt prüfen, dann härten
Supply-Chain-Angriffe über gecompromittierte npm- und Python-Packages können weitreichende Folgen haben: von der Kompromittierung von Authentifizierungsdaten bis zur möglichen Exfiltration sensibler Daten und Folgeschäden in Entwicklung, Infrastruktur und bei Endnutzern.
Handeln Sie daher in zwei Schritten: prüfen Sie Ihre Umgebung anhand der genannten Pakete und möglicher IOCs, reagieren Sie bei Hinweisen sofort mit Incident-Response und Credential-Rotation. Parallel sollten Sie Ihre Lieferkette durch Version Pinning, sichere Installationspraktiken, Scans in CI/CD und vertrauenswürdiges Publishing nachhaltig absichern.
Quelle: https://www.ncsc.nl/alerts/ontwikkelaars-opgelet-gecompromitteerde-npm-en-python-packages
