JavaScript: Sicherheitslücke im Node.js-Paketmanager NPM
Bereits im Januar hat Google-Mitarbeiter Sam Saccone eine Schwachstelle im Paketmanager NPM entdeckt, die eine Verbreitung von Schadcode ermöglicht. Kurz darauf informierte er das NPM-Team, das jetzt eine Stellungnahme veröffentlichte.
![JavaScript: Sicherheitslücke im Node.js-Paketmanager NPM](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/1/7/7/9/3/9/7/hb-06e2664cd1a070f7.jpeg)
NPM ist der Standardpaketmanager für Node.js. Entwickler installieren darüber eigene und fremde Skriptpakete. Die nachinstallierten Module können nicht nur JavaScript, sondern auch beliebigen anderen Code ausführen und besitzen dabei dieselbe Berechtigung wie der aktuelle Benutzer. Das ist durchaus gewollt und sinnvoll, wenn beispielsweise ein Compiler angestoßen werden soll. Gleichzeitig ermöglicht es bösartigen Skriptautoren jedoch das Öffnen von Hintertüren und das Installieren eines Wurms.
Drei Faktoren tragen nach dem Beitrag von Sam Saccone, der als Software Engineer bei Google tätig ist, zu der Verwundbarkeit bei:
- NPM ermutigt die Nutzer auf semantische Versionierung zu setzen, statt Abhängigkeiten an eine bestimme Version zu binden. Somit können Pakete auf verbundene Skripte zurückgreifen, die in einer aktuelleren Version vorliegen und damit unbekannten Code enthalten.
- Wenn Nutzer in NPM eingeloggt sind, müssen sie sich manuell abmelden. Sobald sie also npm install eingeben und angemeldet sind, kann jedes Modul beliebige Befehle wie das Veröffentlichen unter dem Namen des Nutzers ausführen.
- Ein einzelner Registry-Server wird vom Großteil des Node.js-Ökosystems genutzt. Mit npm publish veröffentlichter Code steht danach zur Installation für alle Anwender in der Registry.
Social Engineering
Die Verbreitung von Schadcode über NPM erfordert jedoch zunächst einen gezielten Angriff auf ein bekanntes NPM-Paket, das von anderen verwendet wird. Sam Saccone sieht als ersten Schritt der Infizierung das Social Engineering eines Modulbetreibers. Dort installiert der Wurm dann ein eigenes NPM-Modul, das zum einen bei jedem Start wieder den Wurm ausführt, zum anderen unter dem Account des Betreibers in der Registry landet. Anschließend erhalten alle Module des Besitzers die Abhängigkeit zu dem neuen Modul, die als Bugfix versioniert werden.
Im Beitrag weißt Saccone noch auf die vielzähligen Abhängigkeiten der Projekte hin, die es Endanwendern unmöglich macht, alle Module nachzuvollziehen. Als Beispiel führt er Phonegap an, das Abhängigkeiten zu 276 individuellen NPM-Accounts hat. Social-Engineering-Maßnahmen, die auf nur einen Account-Betreiber zielen, genügen, um das Gesamtprojekt zu infizieren.
Antwort von NPM
NPM hat auf die Veröffentlichung der Schwachstelle mit einer Stellungnahme reagiert. Darin steht, dass das Unternehmen die Sicherheit der Registry nicht garantieren kann. Gleichzeitig weisen sie darauf hin, dass jeder, der Schadcode entdeckt, ihn umgehend melden soll, damit das NPM-Team ihn entfernen kann. Zudem empfiehlt das Team die Verwendung der --ignore-scripts-Option beim Installieren von Paketen mit npm install. Alternativ sollen Nutzer, die nie Skripts beim Installieren verwenden, die Ausführung dauerhaft über folgenden Befehl deaktivieren:
npm config set ignore-scripts true
Das NPM-Team arbeitet wohl auch mit Herstellern von Sicherheitssoftware zusammen, um Skripte auf Angriffsstellen zu testen. Zudem will es Möglichkeiten zur Zwei-Faktor-Authentifizierung integrieren, die bereits für die kommerzielle Installation npm On-site existiert.
Wackelige Abhängigkeiten
Wie bei ähnlichen Sicherheitsproblemen muss sich NPM die Frage gefallen lassen, warum nicht die höheren Sicherheitsvorkehrungen als Standard gelten und Nutzer das Ausführen von Befehlen umgekehrt über eine Option explizit erlauben müssen. Wie wackelig die Abhängigkeiten sein können zeigte sich erst vor Kurzem, als das Entfernen eines winzigen Pakets aus NPM den Build mehrerer Projekte verhinderte. Da der Grund die Verärgerung des Autors über NPM selbst war, hätte er potenziell stattdessen auch sein eigenes Modul auf die oben genannte Weise manipulieren können.
[Update 29.3. 12:00]
In der ersten Fassung der Meldung stand, dass NPM für die Sicherheit der Registry garantiert, was aber in der Stellungnahme umgekehrt gekennzeichnet ist. Die entsprechende Passage wurde korrigiert. (rme)