Vulnérabilité dans le package NPM node-netmask utilisé dans 270 XNUMX projets

Le package NPM node-netmask, qui compte environ 3 millions de téléchargements par semaine et est utilisé comme dépendance sur plus de 270 2021 projets sur GitHub, présente une vulnérabilité (CVE-28918-2.0.0) qui lui permet de contourner les contrôles qui utilisent le masque de réseau. pour déterminer l'occurrence pour adresser des plages ou pour le filtrage. Le problème est résolu dans la version de node-netmask XNUMX.

La vulnérabilité permet de traiter une adresse IP externe comme une adresse du réseau interne et vice versa, et avec une certaine logique d'utilisation du module node-netmask dans l'application pour réaliser des SSRF (Server-side request forgery), RFI (Remote File Inclusion) et LFI (Local File Inclusion)) pour accéder aux ressources du réseau interne et inclure des fichiers externes ou locaux dans la chaîne d'exécution. Le problème est que selon la spécification, les valeurs de chaîne d'adresse commençant par un zéro doivent être interprétées comme des nombres octaux, mais le module node-netmask n'en tient pas compte et les traite comme des nombres décimaux.

Par exemple, un attaquant pourrait demander une ressource locale en spécifiant la valeur "0177.0.0.1", qui correspond à "127.0.0.1", mais le module "node-netmask" ignorera la valeur nulle et traitera 0177.0.0.1″ comme " 177.0.0.1", qui dans l'application lors de l'évaluation des règles d'accès, il ne sera pas possible de déterminer l'identité avec "127.0.0.1". De même, un attaquant peut spécifier l'adresse « 0127.0.0.1 », qui devrait être identique à « 87.0.0.1 », mais sera traitée comme « 127.0.0.1 » dans le module « node-netmask ». De même, vous pouvez tromper le contrôle d'accès aux adresses intranet en spécifiant des valeurs comme « 012.0.0.1 » (équivalent à « 10.0.0.1 », mais sera traité comme 12.0.0.1 lors du contrôle).

Les chercheurs qui ont identifié le problème le qualifient de catastrophique et proposent plusieurs scénarios d'attaque, mais la plupart d'entre eux semblent spéculatifs. Par exemple, il parle de la possibilité d'attaquer une application basée sur Node.js qui établit des connexions externes pour demander une ressource en fonction des paramètres ou des données de la demande d'entrée, mais l'application n'est pas spécifiquement nommée ou détaillée. Même si vous trouvez des applications qui chargent des ressources en fonction des adresses IP saisies, il n'est pas tout à fait clair comment la vulnérabilité peut être exploitée dans la pratique sans se connecter à un réseau local ou sans prendre le contrôle des adresses IP « miroir ».

Les chercheurs supposent uniquement que les propriétaires de 87.0.0.1 (Telecom Italia) et 0177.0.0.1 (Brasil Telecom) sont en mesure de contourner la restriction d'accès au 127.0.0.1. Un scénario plus réaliste consiste à exploiter la vulnérabilité pour contourner diverses listes de blocage côté application. Le problème peut également s'appliquer au partage des définitions de plages intranet dans le module NPM « private-ip ».

Source: opennet.ru

Ajouter un commentaire