Dans le paquet NPM node-netmask, qui compte environ 3 millions de téléchargements par semaine et est utilisé comme dépendance par plus de 270 000 projets sur GitHub, une vulnérabilité (CVE-2021-28918) a été identifiée, permettant de contourner les vérifications où le masque réseau est utilisé pour déterminer l'appartenance à des plages d'adresses ou pour le filtrage. Le problème a été résolu dans la version node-netmask 2.0.0.
La vulnérabilité permet de traiter une adresse IP externe comme une adresse appartenant à un réseau interne et vice versa, et, selon la logique d'utilisation du module node-netmask dans une application, de réaliser des attaques SSRF (Server-side request forgery), RFI (Remote File Inclusion) et LFI (Local File Inclusion) pour accéder à des ressources sur le réseau interne et inclure des fichiers externes ou locaux dans la chaîne d'exécution. Le problème réside dans le fait que selon la spécification, les valeurs d'adresse commençant par zéro doivent être interprétées comme des nombres octaux, mais le module « node-netmask » ne prend pas en compte cette particularité et les traite comme des nombres décimaux.
Par exemple, un attaquant peut demander une ressource locale en indiquant la valeur « 0177.0.0.1 », qui correspond à « 127.0.0.1 », mais le module « node-netmask » jettera le zéro et traitera « 0177.0.0.1 » comme « 177.0.0.1 », ce qui, lors de l'évaluation des règles d'accès dans l'application, ne permettra pas de définir l'équivalence avec « 127.0.0.1 ». De même, un attaquant peut indiquer l'adresse « 0127.0.0.1 », qui devrait correspondre à « 87.0.0.1 », mais dans le module « node-netmask », elle sera traitée comme « 127.0.0.1 ». De même, il est possible de contourner les vérifications d'accès aux adresses intranet en saisissant des valeurs telles que « 012.0.0.1 » (équivalent à « 10.0.0.1 », mais lors de la vérification elle sera traitée comme « 12.0.0.1 »).
Les chercheurs ayant découvert le problème qualifient celui-ci de catastrophique et présentent plusieurs scénarios d'attaques, mais la plupart semblent théoriques. Par exemple, il est question de la possibilité d'attaquer une application basée sur Node.js qui établit des connexions externes pour demander une ressource basée sur des paramètres ou des données d'une requête d'entrée, mais aucune application spécifique n'est nommée ni détaillée. Même si l'on trouve des applications effectuant le chargement de ressources en fonction des données fournies. adresses IP, il n'est pas tout à fait clair comment appliquer la vulnérabilité dans la pratique sans se connecter à un réseau local ou sans obtenir le contrôle des adresses IP « miroir ».
Les chercheurs supposent seulement que les propriétaires de 87.0.0.1 (Telecom Italia) et 0177.0.0.1 (Brasil Telecom) ont la possibilité de contourner la restriction d'accès à 127.0.0.1. Un scénario plus réaliste consiste à utiliser la vulnérabilité pour contourner diverses listes de blocage mises en œuvre côté application. Le problème pourrait également être utilisé pour échanger la définition des plages intranet dans le module NPM « private-ip ».
Source : opennet.ru
