O pacote NPM node-netmask, que tem cerca de 3 milhões de downloads por semana e é usado como dependência de mais de 270 mil projetos no GitHub, possui uma vulnerabilidade (CVE-2021-28918) que permite contornar verificações que usam a máscara de rede para determinar a ocorrência para intervalos de endereços ou para filtragem. O problema foi corrigido no lançamento do node-netmask 2.0.0.
A vulnerabilidade permite tratar um endereço IP externo como um endereço da rede interna e vice-versa, e com uma certa lógica de utilização do módulo node-netmask na aplicação para realizar SSRF (Server-side request forgery), RFI (ataques de inclusão remota de arquivos) e LFI (inclusão de arquivos locais) para acessar recursos na rede interna e incluir arquivos externos ou locais na cadeia de execução. O problema é que, de acordo com a especificação, os valores da string de endereço começando com zero devem ser interpretados como números octais, mas o módulo node-netmask não leva isso em consideração e os trata como números decimais.
Por exemplo, um invasor poderia solicitar um recurso local especificando o valor "0177.0.0.1", que corresponde a "127.0.0.1", mas o módulo "node-netmask" descartará o nulo e tratará 0177.0.0.1″ como " 177.0.0.1", que na aplicação ao avaliar regras de acesso não será possível determinar a identidade com “127.0.0.1”. Da mesma forma, um invasor pode especificar o endereço “0127.0.0.1”, que deve ser idêntico a “87.0.0.1”, mas será tratado como “127.0.0.1” no módulo “node-netmask”. Da mesma forma, você pode enganar a verificação de acesso a endereços de intranet especificando valores como “012.0.0.1” (equivalente a “10.0.0.1”, mas será processado como 12.0.0.1 durante a verificação).
Os pesquisadores que identificaram o problema consideram-no catastrófico e fornecem vários cenários de ataque, mas a maioria deles parece especulativa. Por exemplo, fala sobre a possibilidade de atacar uma aplicação baseada em Node.js que estabelece conexões externas para solicitar um recurso com base nos parâmetros ou dados da solicitação de entrada, mas a aplicação não é especificamente nomeada ou detalhada. Mesmo que você encontre aplicativos que carregam recursos com base nos endereços IP inseridos, não está totalmente claro como a vulnerabilidade pode ser explorada na prática sem se conectar a uma rede local ou sem obter controle de endereços IP “espelhos”.
Os pesquisadores presumem apenas que os proprietários de 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) conseguem contornar a restrição de acesso a 127.0.0.1. Um cenário mais realista é explorar a vulnerabilidade para contornar várias listas de bloqueio do aplicativo. A questão também pode ser aplicada ao compartilhamento da definição de intervalos de intranet no módulo NPM “private-ip”.
Fonte: opennet.ru