Javascript: GitHubs NPM-Registry enthielt 1.300 Malware-Pakete

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.
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“.
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.
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.
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
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.