Schadcode in npm-Paketen – Was tun?

Security-Stress in npm

Die npm Registry ist DIE öffentliche Registry der JavaScript-Sphäre. Die beiden wichtigsten Paketmanager npm und yarn setzen beide auf ihr auf. Dementsprechend groß war der Aufschrei, als Mitte Oktober 2021 bekannt wurde, dass im Paket ua-parser, einer Bibliothek mit wöchentlich mehreren Millionen Downloads, unbemerkt eine Schadsoftware eingeschleust wurde.

Nur zwei Wochen später wurde ein weiterer Fall bekannt, diesmal in den noch weiter verbreiteten Bibliotheken coa und rc . Die Schwachstellen sind inzwischen behoben, die betroffenen Systeme hoffentlich bekannt und der Schaden begrenzt. Doch die Verunsicherung war groß und die Häufung dieser Angriffsart („Supplychain Attack“) zeigt, dass schneller Umgang mit npm-Paketversionen auch in Zukunft wichtig werden kann. In diesem Artikel wollen wir erste Diagnose-Hilfestellung geben. Wir zeigen, wie es möglich ist, herauszufinden, ob Systeme betroffen sind, und geben Tipps, wie dann weiter vorzugehen ist.

Die Codebeispiele in diesem Artikel sind in bash-Syntax, können jedoch recht einfach auf andere Kommandozeileninterpreter adaptiert werden. Kommentiert gerne Übertragungen, oder schreibt auch einen Kommentar, wenn Unterstützung benötigt wird.

Was für Angriffe fanden statt?

Die Angriffe auf die npm-Pakete fanden zwar zu unterschiedlichen Zeitpunkten statt, aber verliefen nach ähnlichen Mustern: In den betroffenen Versionen wurden zusätzliche ausführbare Dateien zugefügt und über einen neuen Schritt im build-Skript installiert.

Auf den betroffenen Systemen wurde die Schadsoftware installiert. Für ua-parser ist inzwischen bekannt, dass Passwortdiebstahlsoftware und Crypto-Miner installiert wurden, ebenso für coa . Über diese Methode kann ein:e Angreifer:in allerdings quasi beliebige Schadsoftware installieren. Dies führt dazu, dass betroffene Systeme als vollständig kompromittiert zu betrachten sind. Das ist das gleiche Gefahrenlevel, als wäre ein Hacker direkt in das System eingebrochen. Es können Passwörter gestohlen worden sein, wichtige Geschäftsdaten, Kundendaten, … Der Angriff ist also sehr ernst zu nehmen.

Erste Hilfe: Bin ich betroffen?

Sowohl für die bekannten Schwachstellen als auch für zukünftige Schwachstellen sollte der erste Schritt sein, zu überprüfen, ob die eigenen Systeme betroffen sind. Dazu gibt es verschiedene Möglichkeiten.

Paket-Dependencies überprüfen

npm verfügt bereits über Möglichkeiten, installierte Pakete, inklusive aller Abhängigkeiten, anzeigen zu lassen. Der Befehl hierfür ist npm ls. Als Optionen für den Befehl können auch einzelne Pakete verwendet werden, also für eine Überprüfung der Installation von rc npm ls rc. Die globale Installation kann mit npm ls -g rc überprüft werden. Analog kann der Befehl auch für andere Pakete wie ua-parser, coa oder andere zukünftig betroffene Pakete verwendet werden.

Hier sehen wir eine Ausgabe für ein Projekt, das rc benutzt, allerdings eine der „guten“ Versionen.

Hier sehen wir eine Ausgabe für ein Projekt, in dem das Paket coa nicht installiert wurde. Die Ausgabe zeigt „empty“, also „leer“.

Besteht das Projekt aus vielen Repositories, kann auch einfach via Skript der Befehl in allen Unterordnern ausgeführt werden:

for d in */ ; do
    cd $d
    npm ls rc
    npm ls coa
    cd ..
done

Das Skript führt für alle Elemente in dem Ordner, die selbst Unterordner sind, die Befehle aus, in den Ordner zu springen, auf rc und goa zu prüfen und dann wieder in den Überordner zu wechseln.

yarn list verwendet unter der Haube npm list, deswegen können die Befehle auch für yarn verwendet werden.

Package lock nach den betroffenen Versionen scannen

Eine andere Möglichkeit ist es, die package-lock-Dateien auf dem System nach den betroffenen Versionen zu durchsuchen. Package-lock-Dateien sind automatisch generierte Dateien, die unter anderem den kompletten Abhängigkeitsbaum der Installation zeigen. So sind die Pakete auch zu finden, wenn sie nicht direkt verwendet wurden, aber als Abhängigkeit installiert wurden.

Für coa, rc und ua-parser überprüft das folgende Skript die bekannten schadhaften Versionen:

# coa
find . -name "package-lock.json" -exec grep --color -EHni "coa-(2.0.3|2.0.4|2.1.1|2.1.3|3.0.1|3.1.3)" {} \; 2>/dev/null
find . -name "yarn.lock" -exec grep --color -EHni "coa-(2.0.3|2.0.4|2.1.1|2.1.3|3.0.1|3.1.3)" {} \; 2>/dev/null

# rc
find . -name "package-lock.json" -exec grep --color -EHni "rc-(1.2.9|1.3.9|2.3.9)" {} \; 2>/dev/null
find . -name "yarn.lock" -exec grep --color -EHni "rc-(1.2.9|1.3.9|2.3.9)" {} \; 2>/dev/null

# ua-parser
find / -name "package-lock.json" -exec grep --color -EHni "ua-parser-js-(0.7.29|0.8.0|1.0.0)" {} \; 2>/dev/null
find / -name "yarn.lock" -exec grep --color -EHni "ua-parser-js-(0.7.29|0.8.0|1.0.0)" {} \; 2>/dev/null

Die Liste der Versionen kann sich natürlich ändern, wenn mehr über den Angriff bekannt wird.

npm audit

Länger bekannte Schwachstellen lassen sich auch gut über npm audit bzw. yarn audit aufspüren. Ein großer Vorteil dieser Variante ist, dass sie alle bekannten Schwachstellen abdeckt und nicht nur einzelne Pakete. Außerdem ist die Ausgabe übersichtlicher. Neben Anzahl und Ernsthaftigkeit der Schwachstellen gibt es für jede Angabe über die gepatchten Versionen und Abhängigkeiten eine Referenz auf den Eintrag in der GitHub-Advisory-Datenbank.

Nach Artefakten des Schadcodes durchsuchen

Sowohl im ua-parser als auch in coa und rc wurden zusätzliche Dateien und Befehle installiert. Auf Spuren dieser Zufügungen kannst du nun prüfen. Auch diese Variante bezieht sich auf bereits ausgeführte Installationen.

Diese Variante erkennt auch, ob die schadhaften Versionen in der Vergangenheit installiert waren. Zumindest wenn der Schadcode nicht gelöscht oder extra deinstalliert wurde, was auch durch einen Angreifer passiert sein könnte. Auch diese Methode gibt also keine absolute Sicherheit.

Die in ua-parser zugefügten Dateien heißen „jsextension“, folgender Befehl sucht danach (der Zusatz 2>/dev/null verwirft Fehlermeldungen wie, dass der Befehl nicht auf dem root Ordner ausgeführt werden kann – was wir auch nicht wollen oder erwarten):

find / -iname "jsextension" 2>/dev/null
ps -ef | grep -i jsextension 2>/dev/null

In rc wurde eine Datei namens compile.bat installiert . Auch danach kannst du suchen:

find / -iname "compile.bat"

Zukünftige Angriffe können natürlich ganz anders aussehen und vielleicht auch nicht über zusätzliche Softwarekomponenten („Payload“) so einfach identifizierbar sein.

Ein paar Hinweise für alle Varianten

Für alle Varianten achte darauf, dass du die aktuelle Version des Projekts überprüfst. Es könnte zum Beispiel sein, dass du lokal auf einer veralteten Version prüfst, während auf dem zentralen Repository der verwendeten Versionskontrolle vielleicht eine Version mit anderen Abhängigkeiten liegt.

Auch kann es sein, dass auf anderen Umgebungen bei einer Installation weitere Schritte gemacht werden. Das sollte überprüft werden, um sicherzustellen, dass nicht zum Beispiel die lokalen Versionen in Ordnung sind, aber durch ein automatisches Upgrade auf der Produktionsumgebung diese betroffen ist.

Schadecode in npm-Paketen: Nächste Schritte

Sind die eigenen Systeme nicht betroffen, ist erstmal alles gut. Gib trotzdem deinen Teams Bescheid, und zeige ihnen vielleicht auch, was du gemacht habst, um zu überprüfen, welche Versionen auf dem System sind. Den Vorfall zu nutzen, um mehr über Sicherheit in der Entwicklung zu reden, schadet auch nicht. 😉

Sind Systeme, für die du mitverantwortlich bist, betroffen, musst du handeln. Der beste und sicherste Umgang mit dieser Situation ist, sich so schnell wie möglich an die IT-Sicherheitsfachleute deiner Firma zu wenden. Es sind einige Tutorials im Umlauf, die erklären, wie man Paketversionen herabstufen und den Schadcode deinstallieren kann. Doch die Schadsoftware kann dritten Personen vollständige Kontrolle über das betroffene System gewährt haben, so dass eine einfache Deinstallation, oder sogar das Neuaufsetzen des Systems, in diesem Fall nicht ausreichen.

Keine Angst vor Sicherheits-Expert:innen!

Ähnlich wie bei einem gesundheitlichen Erste-Hilfe-Fall hilft es, wenn du klar und präzise die Randdaten kommunizieren kannst: Um welchen Vorfall geht es? Welche Systeme sind betroffen? Was hast du oder haben andere bereits unternommen?
Das gilt auch und besonders, wenn du glaubst, einen Fehler gemacht zu haben. Vielleicht hast du versehentlich das install-Skript ausgeführt, obwohl du gesehen hast, dass etwas nicht stimmt. Oder du hast „Spuren vernichtet“, indem du Daten gelöscht hast. Damit bist du sicher nicht alleine und je mehr die Expert:innen wissen, desto besser können sie die Situation einschätzen und in den Griff bekommen.

Das weitere Vorgehen werden die Expert:innen dann mit dir besprechen. Sie können verschiedene Maßnahmen vorschlagen, je nach eurem Setup. Für diesen Vorfall beinhalten die Maßnahmen vermutlich eine Neuinstallation der betroffenen Systeme, das Ändern aller Passwörter von einer nicht betroffenen Maschine aus sowie eine Analyse der Situation. Also welche Daten wurden eventuell gestohlen, und welche Systeme kompromittiert? So können sie die Schwere des Vorfalls einschätzen.

Ganz wichtig ist, dass du für diesen Prozess offen und ehrlich bist. Wahrscheinlich hast du nichts falsch gemacht, und es ist wichtig, IT-Spezialist:innen mit einzubeziehen, um den Schaden zu begrenzen.

Ein paar ermutigende Worte zum Abschluss

Security Incidents sind unangenehm, besonders wenn man sich zum ersten Mal tiefer damit auseinandersetzt. Hoffentlich konnte dieser Artikel dir ein paar erste Werkzeuge zur Hand geben und auch zeigen, dass zumindest „Erste Hilfe“ kein Hexenwerk ist.

An dieser Stelle sei auch nochmal erwähnt, dass es über die „Erste Hilfe“ hinaus wichtig ist, IT-Security-Expert:innen hinzuzuziehen. Dies gilt besonders im Zweifelsfall und wenn man mit einer Kompromittierung rechnet. Expert:innen sind darauf spezialisiert, die Auswirkungen einzuschätzen, die Angriffvektoren zu ermitteln (Digital Forensic and Incident Response) und geeignete Maßnahmen (Threat Hunting) zu ergreifen. So können sie die Situation angemessen handhaben.

Darüber hinaus sind Security Incidents auch immer eine Möglichkeit, etwas zu lernen und die Systeme zu verbessern. Vielleicht können wir dir mit diesem Artikel einen guten Einstieg bieten, sich weiter mit dem Thema auseinanderzusetzen? Viel Erfolg auf jeden Fall, du hast den ersten Schritt gemacht!