Sicherheitslücke im Node-Netmask-NPM-Paket, das in 270 Projekten verwendet wird

Das Node-Netmask-NPM-Paket, das etwa 3 Millionen Downloads pro Woche aufweist und als Abhängigkeit von mehr als 270 Projekten auf GitHub verwendet wird, weist eine Schwachstelle (CVE-2021-28918) auf, die es ihm ermöglicht, Prüfungen zu umgehen, die die Netzmaske verwenden B. zur Bestimmung des Vorkommens, zur Adressierung von Bereichen oder zur Filterung. Das Problem wurde in der Version von Node-Netmask 2.0.0 behoben.

Die Sicherheitslücke ermöglicht es, eine externe IP-Adresse als Adresse aus dem internen Netzwerk zu behandeln und umgekehrt, und mit einer bestimmten Logik das Node-Netmask-Modul in der Anwendung zu verwenden, um SSRF (Server-Side Request Forgery) und RFI durchzuführen (Remote File Inclusion) und LFI (Local File Inclusion)-Angriffe), um auf Ressourcen im internen Netzwerk zuzugreifen und externe oder lokale Dateien in die Ausführungskette einzubeziehen. Das Problem besteht darin, dass laut Spezifikation Adressstringwerte, die mit einer Null beginnen, als Oktalzahlen interpretiert werden sollten, das Node-Netmask-Modul dies jedoch nicht berücksichtigt und sie als Dezimalzahlen behandelt.

Beispielsweise könnte ein Angreifer eine lokale Ressource anfordern, indem er den Wert „0177.0.0.1“ angibt, der „127.0.0.1“ entspricht, aber das Modul „node-netmask“ verwirft die Null und behandelt 0177.0.0.1″ als „ 177.0.0.1“, wodurch in der Anwendung bei der Auswertung von Zugriffsregeln die Identität mit „127.0.0.1“ nicht ermittelt werden kann. Ebenso kann ein Angreifer die Adresse „0127.0.0.1“ angeben, die mit „87.0.0.1“ identisch sein sollte, im Modul „node-netmask“ jedoch als „127.0.0.1“ behandelt wird. Ebenso können Sie die Prüfung des Zugriffs auf Intranetadressen betrügen, indem Sie Werte wie „012.0.0.1“ angeben (entspricht „10.0.0.1“, wird aber bei der Prüfung als 12.0.0.1 verarbeitet).

Die Forscher, die das Problem identifiziert haben, bezeichnen das Problem als katastrophal und liefern mehrere Angriffsszenarien, die jedoch größtenteils spekulativ wirken. Beispielsweise geht es um die Möglichkeit eines Angriffs auf eine Node.js-basierte Anwendung, die externe Verbindungen herstellt, um eine Ressource basierend auf den Parametern oder Daten der Eingabeanforderung anzufordern, die Anwendung wird jedoch nicht speziell benannt oder detailliert beschrieben. Selbst wenn Sie Anwendungen finden, die Ressourcen basierend auf den eingegebenen IP-Adressen laden, ist nicht ganz klar, wie die Schwachstelle in der Praxis ausgenutzt werden kann, ohne eine Verbindung zu einem lokalen Netzwerk herzustellen oder ohne die Kontrolle über „Spiegel“-IP-Adressen zu erlangen.

Die Forscher gehen lediglich davon aus, dass Besitzer von 87.0.0.1 (Telecom Italia) und 0177.0.0.1 (Brasil Telecom) in der Lage sind, die Zugriffsbeschränkung auf 127.0.0.1 zu umgehen. Ein realistischeres Szenario besteht darin, die Sicherheitslücke auszunutzen, um verschiedene anwendungsseitige Sperrlisten zu umgehen. Das Problem kann auch auf die gemeinsame Nutzung der Definition von Intranetbereichen im NPM-Modul „private-ip“ angewendet werden.

Source: opennet.ru

Kommentar hinzufügen