En el paquete NPM node-netmask, que cuenta con alrededor de 3 millones de descargas semanales y se utiliza como dependencia en más de 270 mil proyectos en GitHub, se ha detectado una vulnerabilidad (CVE-2021-28918) que permite eludir las verificaciones donde se utiliza la máscara de red para determinar la inclusión en rangos de direcciones o para filtrado. El problema ha sido solucionado en la versión 2.0.0 de node-netmask.
La vulnerabilidad permite tratar una dirección IP externa como si fuera de una red interna y viceversa; dado un cierto uso del módulo node-netmask en la aplicación, se pueden llevar a cabo ataques de SSRF (Server-side request forgery), RFI (Remote File Inclusion) y LFI (Local File Inclusion) para acceder a recursos en la red interna e incluir en la cadena de ejecución archivos externos o locales. El problema radica en que, según la especificación, los valores de dirección que comienzan con cero deben interpretarse como números octales, pero el módulo 'node-netmask' no tiene en cuenta esta particularidad 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' eliminaría el cero y trataría '0177.0.0.1' como '177.0.0.1', lo que en la aplicación, al evaluar las reglas de acceso, no permitiría determinar la equivalencia con '127.0.0.1'. De manera similar, un atacante podría especificar la dirección '0127.0.0.1', que debería ser equivalente a '87.0.0.1', pero en el módulo 'node-netmask' sería procesado como '127.0.0.1'. Igualmente, se puede engañar la verificación de acceso a direcciones intranet especificando valores como '012.0.0.1' (equivalente a '10.0.0.1', pero se procesará como '12.0.0.1').
Los investigadores que han identificado el problema consideran que es catastrófico y proporcionan varios escenarios de ataque, aunque la mayoría parecen especulativos. Por ejemplo, se menciona la posibilidad de atacar aplicaciones basadas en Node.js que establecen conexiones externas para solicitar un recurso en función de parámetros o datos de la solicitud de entrada, pero la aplicación en concreto no se nombra ni detalla. Incluso si se encuentran aplicaciones que descargan recursos basándose en las entradas, direcciones IP, no está del todo claro cómo se podría aplicar la vulnerabilidad en la práctica sin conectarse a una red local o sin obtener control sobre direcciones IP 'espejo'.
Los investigadores solo suponen que los propietarios de 87.0.0.1 (Telecom Italia) y 0177.0.0.1 (Brasil Telecom) tienen la capacidad de eludir la restricción de acceso a 127.0.0.1. Un escenario más realista es utilizar la vulnerabilidad para evadir diversas listas de bloqueo implementadas del lado de la aplicación. El problema también puede aplicarse para intercambiar la definición de rangos de intranet en el módulo NPM "private-ip".
Fuente: opennet.ru
