No pacote NPM node-netmask, que tem cerca de 3 milhões de downloads por semana e é usado como dependência em mais de 270 mil projetos no GitHub, foi identificada uma vulnerabilidade (CVE-2021-28918) que permite contornar verificações onde a máscara de rede é usada para determinar a inclusão em intervalos de endereços ou para filtragem. O problema foi corrigido na versão node-netmask 2.0.0.
A vulnerabilidade permite tratar endereços IP externos como endereços de rede interna e vice-versa, e com uma lógica específica de uso do módulo node-netmask em uma aplicação, possibilitar ataques SSRF (Server-side request forgery), RFI (Remote File Inclusion) e LFI (Local File Inclusion) para acessar recursos na rede interna e incluir na cadeia de execução arquivos externos ou locais. O problema está no fato de que, de acordo com a especificação, valores de string de endereços que começam com zero devem ser interpretados como números octais, mas o módulo 'node-netmask' não leva essa particularidade em conta e os trata como números decimais.
Por exemplo, um atacante pode solicitar um recurso local informando o valor '0177.0.0.1', que corresponde a '127.0.0.1', mas o módulo 'node-netmask' descartará o zero e tratará '0177.0.0.1' como '177.0.0.1', o que na aplicação, ao avaliar as regras de acesso, não permitirá a identificação com '127.0.0.1'. Da mesma forma, o atacante pode apontar o endereço '0127.0.0.1', que deveria corresponder a '87.0.0.1', mas será tratado no módulo 'node-netmask' como '127.0.0.1'. De maneira similar, é possível enganar a verificação de acessos a endereços intranet, informando valores como '012.0.0.1' (equivalente a '10.0.0.1', mas que será tratado como '12.0.0.1' na verificação).
Os pesquisadores que identificaram o problema o consideram catastrófico e apresentam vários cenários de ataques, embora a maioria deles pareça especulativa. Por exemplo, menciona-se a possibilidade de atacar aplicações baseadas em Node.js que estabelecem conexões externas para solicitar recursos com base em parâmetros ou dados da requisição de entrada, mas a aplicação específica não é nomeada nem detalhada. Mesmo que se encontrem aplicações que realizem o download de recursos com base em IPs inseridos. endereços IP, não está muito claro como a vulnerabilidade pode ser aplicada na prática sem conexão à rede local ou sem obter controle sobre os IPs "espelhados".
Pesquisadores suspeitam que os proprietários de 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) têm a capacidade de contornar a restrição de acesso a 127.0.0.1. Um cenário mais realista seria usar a vulnerabilidade para contornar várias listas de bloqueio implementadas no lado da aplicação. O problema também pode ser aplicado para trocar definições de intervalos de intranet no módulo NPM "private-ip".
Fonte: opennet.ru
