El paquete NPM node-netmask, que tiene alrededor de 3 millones de descargas por semana y se utiliza como dependencia en más de 270 mil proyectos en GitHub, tiene una vulnerabilidad (CVE-2021-28918) que le permite eludir las comprobaciones que utilizan la máscara de red. para determinar la ocurrencia para abordar rangos o para filtrar. El problema se solucionó en la versión de node-netmask 2.0.0.
La vulnerabilidad permite tratar una dirección IP externa como una dirección de la red interna y viceversa, y con cierta lógica de utilizar el módulo node-netmask en la aplicación para realizar SSRF (Server-side request forgery), RFI (Ataques de inclusión remota de archivos) y LFI (inclusión de archivos locales) para acceder a recursos en la red interna e incluir archivos externos o locales en la cadena de ejecución. El problema es que, según la especificación, los valores de las cadenas de direcciones que comienzan con cero deben interpretarse como números octales, pero el módulo node-netmask no tiene esto en cuenta y los trata como números decimales.
Por ejemplo, un atacante podría solicitar un recurso local especificando el valor "0177.0.0.1", que corresponde a "127.0.0.1", pero el módulo "node-netmask" descartará el valor nulo y tratará 0177.0.0.1″ como " 177.0.0.1", que en la aplicación al evaluar reglas de acceso, no será posible determinar la identidad con “127.0.0.1”. De manera similar, un atacante puede especificar la dirección "0127.0.0.1", que debería ser idéntica a "87.0.0.1", pero será tratada como "127.0.0.1" en el módulo "node-netmask". De manera similar, puede engañar la verificación de acceso a direcciones de intranet especificando valores como "012.0.0.1" (equivalente a "10.0.0.1", pero se procesará como 12.0.0.1 durante la verificación).
Los investigadores que identificaron el problema lo califican de catastrófico y proporcionan varios escenarios de ataque, pero la mayoría de ellos parecen especulativos. Por ejemplo, se habla de la posibilidad de atacar una aplicación basada en Node.js que establece conexiones externas para solicitar un recurso en función de los parámetros o datos de la solicitud de entrada, pero no se nombra ni detalla específicamente la aplicación. Incluso si encuentra aplicaciones que cargan recursos basándose en las direcciones IP ingresadas, no está del todo claro cómo se puede explotar la vulnerabilidad en la práctica sin conectarse a una red local o sin obtener el control de las direcciones IP "espejo".
Los investigadores sólo suponen que los propietarios de 87.0.0.1 (Telecom Italia) y 0177.0.0.1 (Brasil Telecom) pueden evitar la restricción de acceso a 127.0.0.1. Un escenario más realista es explotar la vulnerabilidad para evitar varias listas de bloqueo del lado de la aplicación. El problema también se puede aplicar al compartir la definición de rangos de intranet en el módulo "private-ip" de NPM.
Fuente: opennet.ru