Das npm CLI (npm Command-Line Interface) verfügt über eine sehr praktische und bekannte Sicherheitsfunktion bei der Installation eines npm-Pakets – es überprüft das Paket und alle seine Abhängigkeiten auf bekannte Schwachstellen.
Die Prüfung wird bei der Paketinstallation initiiert (wenn „npm install“ ausgeführt wird), kann aber auch manuell durch „npm audit“ ausgelöst werden. Dabei handelt es sich um eine wichtige Sicherheitsmaßnahme, die Entwickler vor der Verwendung von Paketen mit bekannten Sicherheitslücken warnt.
Kürzlich haben die Sicherheitsforscher von JFrog ein unerwartetes Verhalten der npm-Werkzeuge entdeckt, das Auswirkungen auf die Sicherheit hat. Sowohl „npm install“ als auch „npm audit“ zeigen keine sicherheitsrelevanten Hinweise für Pakete mit bestimmten Versionsformaten an. Aus diesem Grund sind Entwickler, die diese Pakete verwenden, dem Risiko ausgesetzt, kritische Sicherheitslücken oder Malware in ihre Systeme und/oder als indirekte Abhängigkeiten zu ihren npm-Paketen einzubringen.
Technische Hintergründe
Bei der Arbeit mit einigen npm-Paketen fiel eine interessante Diskrepanz zwischen den Sicherheitslücken ins Auge, die von der npm CLI und von JFrog Xray gemeldet wurden.Bei der Installation eines bestimmten Pakets, nämlich „cruddl 2.0.0-update.2“, erhielten die Forscher unterschiedliche Hinweise auf Sicherheitslücken.Für dasselbe Paket fanden die Scanner von npm nichts, im Gegensatz dazu fand JFrog Xray eine Schwachstelle (CVE-2022-36084). Nach mehreren Versuchen und Paketinstallationen konnte festgestellt werden, dass diese Diskrepanz nur auftritt, wenn die installierte Paketversion einen Bindestrich enthält (z. B. 1.2.3-a).
Der Code der npm-Applikation ist Closed-Source, daher ist es sehr schwierig herauszufinden, was ursächlich für diese Problematik ist. Jedes Advisory besitzt ein entsprechendes Feld, das logische Ausdrücke (z.B. > 6.6.0) enthält, um den Bereich der betroffenen Versionen zu beschreiben. Wenn eine bestimmte Version einen der logischen Ausdrücke erfüllt, wird sie als verwundbar angesehen.
Wie können Angreifer die Schwachstelle ausnutzen?
Bedrohungsakteure können sich dieses Verhalten zu Nutze machen, indem sie absichtlich Malware-Code in ihre scheinbar regulären Pakete einbauen. Diese werden dann von Entwicklern herangezogen, die an der Funktionalität der Pakete interessiert sind. Außerdem können Pakete versehentlich herangezogen werden, wenn Angriffsszenarien wie typosquatting oder dependency confusion verwendet werden. Ein perfektes Einfallstor für die Kompromittierung über diese Angriffsfläche. Das birgt ein großes Bedrohunspotenzial für alle Entwickler, die sich von dem manipulierten Paket täuschen lassen, da sie in diesem Fall nicht benachrichtigt werden. Das npm CLI berichtet nämlich nicht über die Existenz solcher Advisories, wenn die Versionsnummer zu einer Vorabversion gehört.
Was können Entwickler zur Vermeidung dieser Sicherheitslücke tun?
Die Empfehlung für Entwickler und DevOps-Ingenieure lautet, niemals npm-Pakete mit einer Vorabversion zu installieren, es sei denn, es kann gewährleistet werden, dass das Paket zweifelsfrei von einer seriösen Quelle stammt.
Nutzer können die folgende Befehlszeile verwenden, um festzustellen, ob sie derzeit ein npm-Paket mit einer potenziell gefährdeten Vorabversion installiert haben:
- Für Linux: npm list -a | grep -E @[0-9]+\.[0-9]+\.[0-9]+-Copy Command
- Für Windows: npm list -a | findstr -r @[0-9]*\.[0-9]*\.[0-9]*-Copy Command
www.jfrog.com