O paquete node-netmask NPM, que ten uns 3 millóns de descargas por semana e úsase como dependencia de máis de 270 mil proxectos en GitHub, ten unha vulnerabilidade (CVE-2021-28918) que lle permite evitar as comprobacións que utilizan a máscara de rede. para determinar a aparición para abordar intervalos ou para filtrar. O problema solucionouse na versión de node-netmask 2.0.0.
A vulnerabilidade permite tratar un enderezo IP externo como un enderezo da rede interna e viceversa, e cunha certa lóxica de uso do módulo node-netmask na aplicación para realizar SSRF (Server-side request forgery), RFI. (Ataques de inclusión de ficheiros remotos) e LFI (inclusión de ficheiros locais) para acceder aos recursos da rede interna e incluír ficheiros externos ou locais na cadea de execución. O problema é que, segundo a especificación, os valores das cadeas de enderezos que comezan cun cero deben interpretarse como números octais, pero o módulo de máscara de rede de nodos non o ten en conta e trátaos como números decimais.
Por exemplo, un atacante podería solicitar un recurso local especificando o valor "0177.0.0.1", que corresponde a "127.0.0.1", pero o módulo "node-netmask" descartará o nulo e tratará 0177.0.0.1" como " 177.0.0.1”, que na aplicación á hora de avaliar as regras de acceso non se poderá determinar a identidade con “127.0.0.1”. Do mesmo xeito, un atacante pode especificar o enderezo "0127.0.0.1", que debería ser idéntico a "87.0.0.1", pero será tratado como "127.0.0.1" no módulo "node-netmask". Do mesmo xeito, pode ignorar a verificación de acceso aos enderezos da intranet especificando valores como "012.0.0.1" (equivalente a "10.0.0.1", pero procesarase como 12.0.0.1 durante a comprobación).
Os investigadores que identificaron o problema cualifican o problema de catastrófico e ofrecen varios escenarios de ataque, pero a maioría deles parecen especulativos. Por exemplo, fálase da posibilidade de atacar unha aplicación baseada en Node.js que establece conexións externas para solicitar un recurso en función dos parámetros ou datos da solicitude de entrada, pero a aplicación non está especificamente nomeada nin detallada. Aínda que atopes aplicacións que cargan recursos en función dos enderezos IP introducidos, non está do todo claro como se pode explotar a vulnerabilidade na práctica sen conectarse a unha rede local ou sen conseguir o control dos enderezos IP "espello".
Os investigadores só asumen que os propietarios de 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) poden eludir a restrición de acceso a 127.0.0.1. Un escenario máis realista é explotar a vulnerabilidade para evitar varias listas de bloqueo do lado das aplicacións. O problema tamén se pode aplicar para compartir definicións de intervalos de intranet no módulo NPM "private-ip".
Fonte: opennet.ru