Faz alguns dias O GitHub revelou dois incidentes na infraestrutura do repositório de pacotes NPM, do qual detalha que em 2 de novembro, pesquisadores de segurança terceirizados como parte do programa Bug Bounty encontraram uma vulnerabilidade no repositório NPM que permite publicar uma nova versão de qualquer pacote usando mesmo que não seja autorizado para realizar essas atualizações.
A vulnerabilidade foi causada por verificações de autorização incorretas no código de microsserviços que processam solicitações ao NPM. O serviço de autorização executou uma verificação de permissão nos pacotes com base nos dados passados na solicitação, mas outro serviço que estava carregando a atualização para o repositório determinou que o pacote publicasse com base no conteúdo de metadados no pacote carregado.
Assim, um atacante poderia solicitar a publicação de uma atualização para seu pacote, ao qual ele tem acesso, mas indicar no próprio pacote informações sobre outro pacote, que eventualmente seria atualizado.
Nos últimos meses, a equipe do npm tem investido em melhorias de infraestrutura e segurança para automatizar o monitoramento e a análise de versões de pacotes lançadas recentemente para identificar malware e outros códigos maliciosos em tempo real.
Existem duas categorias principais de eventos de postagem de malware que ocorrem no ecossistema npm: malware postado devido ao sequestro de conta e malware postado por invasores por meio de suas próprias contas. Embora as aquisições de contas de alto impacto sejam relativamente raras, em comparação com o malware direto postado por invasores usando suas próprias contas, as aquisições de contas podem ser de longo alcance quando se destinam a mantenedores de pacotes populares. Embora nosso tempo de detecção e resposta para aquisições de pacotes populares tenha sido de apenas 10 minutos em incidentes recentes, continuamos a desenvolver nossos recursos de detecção de malware e estratégias de notificação em direção a um modelo de resposta mais proativo.
O problema foi corrigido 6 horas após a vulnerabilidade ser relatada, mas a vulnerabilidade estava presente no NPM por mais tempo do que os registros de telemetria cobrem. O GitHub afirma que não houve vestígios de ataques usando esta vulnerabilidade desde setembro de 2020, mas não há garantia de que o problema não tenha sido explorado antes.
O segundo incidente ocorreu em 26 de outubro. No decorrer do trabalho técnico com o banco de dados de serviço replicant.npmjs.com, apurou-se que existiam dados confidenciais na base de dados disponível para consulta externa, revelando informações sobre os nomes dos pacotes internos que foram mencionados no changelog.
Informações sobre esses nomes pode ser usado para realizar ataques de dependência em projetos internos (Em fevereiro, esse tipo de ataque permitiu que o código fosse executado nos servidores do PayPal, Microsoft, Apple, Netflix, Uber e 30 outras empresas.)
Além disso, em relação ao aumento da incidência de apreensão de repositórios de grandes projetos e a promoção de código malicioso através do comprometimento de contas de desenvolvedor, GitHub decidiu introduzir a autenticação obrigatória de dois fatores. A mudança entrará em vigor no primeiro trimestre de 2022 e se aplicará aos mantenedores e administradores dos pacotes incluídos na lista dos mais populares. Além disso, são fornecidas informações sobre a modernização da infraestrutura, na qual o monitoramento e análise automatizados de novas versões de pacotes serão introduzidos para a detecção precoce de alterações maliciosas.
Lembre-se que de acordo com um estudo realizado em 2020, apenas 9.27% dos gerenciadores de pacotes usam autenticação de dois fatores para proteger o acesso, e em 13.37% dos casos, ao registrar novas contas, os desenvolvedores tentaram reutilizar senhas comprometidas que aparecem em senhas conhecidas .
Durante a verificação da força das senhas utilizadas, 12% das contas no NPM (13% dos pacotes) foram acessadas devido ao uso de senhas previsíveis e triviais como "123456". Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas ao mês. Considerando a carga do módulo ao longo da cadeia de dependências, o comprometimento de contas não confiáveis pode afetar até 52% de todos os módulos no NPM no total.
Finalmente, se você estiver interessado em saber mais sobre isso você pode verificar os detalhes no link a seguir.