A vulnerability (CVE-3-270) has been identified in the node-netmask NPM package, which has approximately 2021 million downloads per week and is used as a dependency on over 28918 projects on GitHub. into address ranges or for filtering. The issue has been fixed in the release of node-netmask 2.0.0.
The vulnerability allows to achieve the processing of an external IP address as an address from the internal network and vice versa, and with a certain logic of using the node-netmask module in an application, to perform SSRF (Server-side request forgery), RFI (Remote File Inclusion) and LFI (Local File Inclusion) attacks ) to access resources on the internal network and include external or local files in the execution chain. The problem is that, according to the specification, zero-based address strings should be interpreted as octal numbers, but the "node-netmask" module does not take this into account and treats them as decimal numbers.
For example, an attacker can request a local resource by specifying the value "0177.0.0.1", which corresponds to "127.0.0.1", but the "node-netmask" module will discard zero, and treat 0177.0.0.1" as "177.0.0.1", which in the application when evaluating the access rules, will not be able to determine the identity with "127.0.0.1". Similarly, an attacker can specify the address "0127.0.0.1", which should be identical to "87.0.0.1", but in the "node-netmask" module will be treated as "127.0.0.1". Similarly, it is possible to trick checking for access to intranet addresses by specifying values ββlike "012.0.0.1" (equivalent to "10.0.0.1", but will be treated as 12.0.0.1 during verification).
The researchers who identified the problem call the problem catastrophic and cite several attack scenarios, but most of them look speculative. For example, it talks about the ability to attack a Node.js-based application that establishes external connections to request a resource based on parameters or input request data, but the application is not specifically named or detailed. Even if you find applications that load resources based on entered IP addresses, it is not entirely clear how the vulnerability can be applied in practice without connecting to a local network or without gaining control over "mirror" IP addresses.
Researchers only assume that the owners of 87.0.0.1 (Telecom Italia) and 0177.0.0.1 (Brasil Telecom) have the ability to bypass the access restriction to 127.0.0.1. A more realistic scenario is to use the vulnerability to bypass various block lists implemented on the application side. The issue can also be applied to sharing the definition of intranet ranges in the "private-ip" NPM module.
Source: opennet.ru