Infizierte NPM Pakete und was zu tun ist

Daraufhin habe ich natürlich direkt meinen ganzen PC nach den genannten Packages durchsucht und konnte kein Paket in der infizierten Version finden. Der erste Schock war somit zunächst weg und ich konnte mir genauer anschauen was hier passiert ist.

Was ist passiert?

Ein Maintainer Account von NPM, der die 2-Faktor Authentifizierung nicht aktiviert hatte, wurde kompromittiert. Daraufhin wird über diesen Account für zwei NPM Pakete Versionen hochgeladen, die die Malware beinhalten. Die package.json des Paketes wurde so geändert, dass im preinstall des Paketes eine Schadsoftware ausgeführt wird.

Der Befehl preinstall ist ein Hook in NPM und wird immer ausgeführt, wenn das Paket installiert wird. Bedeutet, wenn ich das Paket als Abhängigkeit in einer package.json habe und die Abhängigkeiten dann über npm install installiere, wird die Schadsoftware ausgeführt.

Beide Pakete enthalten die Schadsoftware DanaBot. Dieser Bot liest vorhandene Passwörter aus, schneidet Passworteingaben mit und sendet diese an einen Server. Da es sich aber um eine BAT Datei handelt, sind momentan nur Windows Systeme betroffen.

Die Betroffenen Pakete sind in den folgenden Versionen infiziert:

Nur wer die Pakete in dieser Version installiert hatte, hat die Schadsoftware ausgeführt.

Diese Versionen wurden aber inzwischen gelöscht und sind auch nicht mehr in NPM zu finden.

Zusätzlich gab es vor diesem Vorfall noch einen Fund in einem anderen NPM Paket:

In diesen Versionen startet die Installation des Pakets einen DanaBot und installiert einen Miner. Hiervon sind Linux wie Windows Systeme betroffen.

Um dies zu beheben sind Patches in folgenden Versionen verfügbar:

0.7.30, 0.8.1, 1.0.1

Wann ist es passiert?

Am 4.11.21 um 14:13 MEZ wurde folgender Issue erstellt:

https://github.com/veged/coa/issues/99

Dort wurde von einem Nutzer berichtet, dass sein Projekt nicht mehr kompiliert, da die Version vom coa Projekt geändert hatte.

Daraufhin wurde das Paket analysiert und festgestellt, dass es sich um eine Malware handelt. Die Versionen wurden gelöscht und das Paket in der Version war insgesamt eine Stunde online.

Am gleichen Tag um 20:27 MEZ wurde ein Issue eingestellt auf Github beim Paket rc:

https://github.com/dominictarr/rc/issues/131#issue-1045123557

Dort wurde von einem Nutzer direkt berichtet, dass die letzte Version eine Malware enthält. Die infizierten Versionen des Paketes wurden um 15:30 MEZ hochgeladen. Laut Aussagen aus dem Issue auf Github wurden diese Version recht zeitnah entfernt aber leider konnte ich bei meiner Recherche keine Werte finden. Ich vermute deshalb, dass die Versionen weniger als eine Stunde online waren.

Bei ua-parser-js waren die infizierten Versionen am 24.10.21 von 00:21 MET – 04:25 MET verfügbar. Danach wurden die besagten Versionen gelöscht und neue Versionen hochgeladen.

Wie relevant ist das für mich?

Die infizierten Versionen der coa und rc Pakete, verwenden Bat Dateien um den DanaBot zu starten. Das bedeutet, die infizierten Versionen sind nur auf Windows Systemen schädlich gewesen. Beim ua-parser-js konnte der Bot auf Windows Systemen und Unix System gestartet werden, der deshalb für beide Systeme schädlich war. Des Weiteren wurde ein Miner installiert. Dieser benutzt aber nur die Rechenleistung des Rechners.

Neben dem System spielt hier die Zeit auch eine Rolle. Nur wer ein Paket über npm install in den jeweiligen Versionen heruntergeladen hat, konnte sein System infizieren. Falls eins der Pakete keine direkte Abhängigkeit hat, muss geschaut werden, ob es möglich ist mit npm install die infizierte Version zu installieren.

Allgemein sollten aber auch alle Systeme kontrolliert werden, die NPM installiert haben.

Wann bestand eine reale Gefahr?

ua-parser-js:

• npm i zwischen 00:21 Uhr und 04:25 Uhr MET, 24.10.2021
• Windows oder Unix Systeme sind betroffen vom DanaBot

coa:

• npm i zwischen ca. 14:02 Uhr und 15:02 Uhr MET, 04.11.2021
• Windows Systeme sind vom DanaBot betroffen

rc:

• npm i zwischen 15:30 Uhr und (vermutlich) 16:30 Uhr MET, 04.11.2021
• Windows Systeme sind vom DanaBot betroffen

Wie kann geprüft werden?

Mit diesem Befehl kann man überprüfen, ob die Pakete installiert sind und in welcher Version:

• Global
  • npm ls coa -g –all
  • npm ls rc -g –all
  • npm ls ua-parser-js -g –all
• Projektordner (auf Höhe der package.json)
  • npm ls coa –all
  • npm ls rc –all
  • npm ls ua-parser-js

Wer yarn benutzt, kann folgende Befehle im Projektordner nutzen (auf Höhe der package.json):

• yarn list coa
• yarn list rc
• yarn list ua-parser-js

Falls Sie ein Projekt überprüfen möchten, aber dieses nicht auf Ihr System laden möchten, können Sie in der package-lock.json nach den Paketen suchen. In der package-lock.json stehen alle Abhängigkeiten des Projektes drinnen.

Wenn Sie ein Paket in einer infizierten Version installiert haben, empfiehlt es sich ihre Passwörter zu ändern und den Rechner (oder den Server) neu aufzusetzen.

Wie schütze ich mich in Zukunft vor so etwas?

Anhand der Fakten zu dem Vorfall schlage ich hier drei Absicherungen vor:

1. Bewusst Versionen setzen
   • NPM bietet zwar an, die Versionen mit ^ oder ~ (Erklärung zu ^ und ~ in npm) zu versehen, um bei jedem npm install die neusten Versionen herunterzuladen, doch meistens ist dies nicht notwendig, weswegen die Versionen auch bewusst gesetzt werden sollten und auf die ^ oder ~ verzichtet werden kann.

2. npm ci
   • NPM bietet neben dem npm install Befehl auch den npm ci Befehl an. Dieser Befehl unterscheidet sich von npm install indem er neben der package.json auch die package-lock.json zu Rate zieht beim Installieren. Die package-lock.json enthält alle Pakete und alle Versionen die beim letzten npm install installiert wurden. Wenn man nun mit npm ci installiert, werden keine neue Versionen installiert, es sei denn die package-lock.json verändert sich. Der npm ci Befehl gehört in jede Pipeline. Niemals der npm i Befehl.

3. OWASP Dependecy Check
   • Der OWASP Dependency Check kann auch im Frontend installierte Abhängigkeiten prüfen. Beim Ausführen des Dependency Checks prüft dieser die package-lock.json und vergleicht die Pakete und Versionen gegen eine riesige Datenbank mit allen möglichen Security findings. Ein report wird in Form von HTML erstellt und dort kann eingesehen werden, welche evtl. Sicherheitslücken es momentan in den installierten Paketen gibt.

4. Dependabot
   • Dieser Bot lässt sich direkt in GitHub oder GitLab installieren und schaut sich im eingecheckten Source Code die Pakete und deren Versionen an und überprüft diese. Im Endeffekt das gleiche wie der OWASP Dependency Check, nur dass dies schon passiert, wenn der SourceCode in GIT eingecheckt wird (wenn der Bot über GITLab oder GitHub installiert wird).

Quellen: