In JavaScript-Registries liegt mehr Malware als gedacht. (Grafik: Shutterstock)
Bei Faker.js und Colors.js ging es vergleichsweise schnell. Die vom Entwickler zu nutzlosen Bibliotheken umgebauten Javascript-Tools fielen praktisch sofort auf. Was aber ist mit Javascript, das zwar Schadcode enthält, dabei jedoch weniger offensichtlich zu Werke geht?
Davon gibt es offenbar mehr als typischerweise öffentlich bekannt wird. Whitesource, eine in Israel ansässige Sicherheitsfirma, hat nach eigenen Angaben im Jahr 2021 1.300 bösartige NPM-Pakete entdeckt. Sie meldete sie an die Registry, die die Malware daraufhin ohne großes Aufsehen entfernte.
Schadenspotenzial ist beträchtlich
Die NPM-Registry ist ein Online-Dienst für die Verteilung von Code-Paketen, der Entwickelnden, die Javascript und verwandte Sprachen verwenden, fertige Funktionen zur Verfügung stellt. Da der Dienst für jedermann zugänglich ist und das Hochladen von Code ohne strenge Prüfung erlaubt, taucht immer mal wieder bösartiger Code auf. Es ist dann an jenen, die die Registry betreuen, den Code zu finden und zu entfernen, um potenziellen Schaden zu minimieren.
Das Schadenspotenzial wiederum ist beträchtlich. Denn Pakete in der NPM enthalten oft andere Pakete als Abhängigkeiten. Dadurch kann eine Anwendung mehrere Ebenen potenzieller Angriffsflächen haben. Wie eine Studie aus dem Jahr 2019 (PDF) herausfand, „führt die Installation eines durchschnittlichen NPM-Pakets zu einem impliziten Vertrauen in 79 Drittanbieter-Pakete und 39 Betreuer“.
Das sollten die gefundenen Malware-Tools tun
Dabei ist die NPM-Registry mit 1,8 Millionen Paketen, von denen jedes im Durchschnitt rund zwölf verschiedene Versionen hat, größer als ihre Konkurrenten. An Rang 2 folgt Javas Maven Central mit derzeit etwa 457.000 Paketen. Täglich werden bis zu 17.000 neue Pakete auf die NPM-Registry geladen. Es ließe sich also in Relation konstatieren, dass ein Volumen von jährlich 1.300 schadhaften Anwendungen ein eher kleines Problem ist. Das ist sicherlich richtig, solange es sich nicht um Pakete mit großer Reichweite handelt. Man denke etwa an die Log4Shell-Katastrophe.
„Eine besorgniserregende Tatsache ist, dass fast 14 Prozent aller entdeckten Pakete darauf ausgelegt waren, sensible Informationen wie Zugangsdaten und andere Daten in Umgebungsvariablen zu stehlen“, heißt es in dem Whitesource-Bericht. Insgesamt beschäftigte sich mit 82 Prozent sogar der weitaus größte Teil der entdeckten Schad-Software mit dem Sammeln von Informationen, die für künftige Angriffe nützlich sein könnten – ohne dabei indes bereits ein konkretes Ziel erkennen zu lassen. Nur etwas mehr als zwei Prozent der Malware wurden für die Remote-Code-Ausführung entwickelt.
Github reagiert
Whitesource formuliert eine Reihe von Empfehlungen, die im Wesentlichen darin bestehen, Paketen nicht blind zu vertrauen, auf Änderungen zu achten und generell angemessene Vorsichtsmaßnahmen zu treffen. Registry-Betreiber GitHub beabsichtigt, sich des Problems aber nun auch von der Wurzel her anzunehmen.
Am Dienstag kündigte GitHub-Manager Myles Borins die obligatorische Verwendung der Zwei-Faktor-Authentifizierung (2FA) zunächst für die Betreuer der nach Abhängigkeiten gemessen 100 wichtigsten NPM-Pakete an. Später soll 2FA für alle erforderlich werden, die Pakete über NPM veröffentlichen wollen. Zudem arbeitet GitHub an der Implementierung von Webauthn für Hardware-Sicherheitsschlüssel.
„Wir sind bestrebt, die Sicherheit von JavaScript und der gesamten Open-Source-Lieferkette zu verbessern“, erklärte Borins. „Während wir bei größeren Initiativen wie Webauth und der zwingenden Verwendung von 2FA für alle wichtigen Paketbetreuer Fortschritte machen, werden wir weiterhin kleinere, iterative Verbesserungen in der Registry vornehmen.“
Das Problem ist nicht auf GitHubs NPM-Registry beschränkt, sondern betrifft ebenso alle anderen Registries sowie die Paketregistrierungen für andere Sprachen wie den Python Package Index (PyPI), rubygems.org und das Comprehensive Perl Archive Network (CPAN) – wenn auch weniger ausgeprägt.
Nicht immer 100%ige Sicherheit und Zuverlässigkeit sind der Grund, warum ich lieber die 20 Zeilen Code selbst schreibe, als dafür ein Paket mit schier unendlich verschachtelten Abhängigkeiten zu verwenden. Mir sind diese Verzweigungen und Intransparenz und so ggf. gar unvorteilhafte Lizenzierung der Xten Abhängigkeit einfach zu gefährlich.
Deshalb nehme ich mir nur die wirklich allernötigsten Pakete ins Projekt.