O maior registro de software de pacotes Node.js, o npm, revelou várias falhas de segurança que foram identificadas e corrigidas recentemente. A primeira falha diz respeito ao vazamento de nomes de pacotes npm privados no servidor ‘réplica’ do npmjs.com – feeds dos quais são consumidos por serviços de terceiros. Portanto, o NPM corrige sério vazamento de nomes de pacotes privados.
A segunda falha permite que os invasores publiquem novas versões de qualquer pacote npm existente que eles não possuem ou não têm direitos, devido a verificações de autorização impróprias.
Nomes de pacotes npm privados vazados
Esta semana, a empresa controladora do npm, o GitHub, divulgou duas falhas de segurança que foram identificadas e resolvidas no registro do npm entre outubro e este mês.
O primeiro é um vazamento de dados no servidor de replicação do npmjs, causado por ‘manutenção de rotina’. O vazamento expôs uma lista de nomes de pacotes npm privados, mas não o conteúdo desses pacotes durante a janela de manutenção.
“Durante a manutenção do banco de dados que alimenta a réplica pública do npm em replicate.npmjs.com , foram criados registros que podem expor os nomes de pacotes privados”, afirma o diretor de segurança do GitHub, Mike Hanley em uma postagem no blog.
“Isso permitiu que os consumidores de replicate.npmjs.com identificassem potencialmente os nomes de pacotes privados devido aos registros publicados no feed de mudanças públicas. Nenhuma outra informação, incluindo o conteúdo desses pacotes privados, estava acessível a qualquer momento.”
NPM corrige sério vazamento de nomes de pacotes privados
Note, enquanto o conteúdo dos pacotes privados não foi exposto, o conhecimento dos nomes de pacotes privados é suficiente para atores ameaça para conduzir direcionados confusão dependência e typosquatting ataques de forma automatizada, como temos visto uma e outra vez.
O vazamento diz respeito especificamente a bibliotecas npm privadas com escopo definido que se parecem com “@ owner/package” e foram criadas antes de 20 de outubro. Os nomes dessas bibliotecas foram expostos “entre 21 de outubro 13: 12: 10Z UTC e 29 de outubro 15: 51: 00Z UTC”, de acordo com o GitHub.
O vazamento de dados foi identificado pelo GitHub em 26 de outubro e, no dia 29, todos os registros contendo nomes de pacotes privados foram excluídos do banco de dados de replicação do npm. Embora o GitHub avise que, apesar disso, o serviço replicate.npmjs.com é consumido por terceiros que podem, portanto, continuar a reter uma cópia ou “podem ter replicado os dados em outro lugar”.
Para evitar que esse problema se repita, o GitHub fez alterações em seu processo de geração do banco de dados de replicação público, o que deve eliminar a possibilidade de vazar nomes de pacotes privados no futuro.
A falha pode permitir a publicação não autorizada de novas versões
Além disso, o GitHub revelou um bug sério que poderia “permitir que um invasor publique novas versões de qualquer pacote npm usando uma conta sem a devida autorização”.
Esta vulnerabilidade resultou de verificações de autorização impróprias e validação de dados entre vários microsserviços que processam solicitações para o registro npm.
“Nessa arquitetura, o serviço de autorização estava validando adequadamente a autorização do usuário para pacotes com base nos dados passados ??em caminhos de URL de solicitação. No entanto, o serviço que executa atualizações subjacentes aos dados de registro determinou qual pacote publicar com base no conteúdo do arquivo de pacote carregado,” explica Hanley.
Essa discrepância forneceu um meio pelo qual as solicitações de publicação de novas versões de um pacote seriam autorizadas para um pacote, mas na verdade seriam realizadas para um pacote diferente e potencialmente não autorizado. Reduzimos esse problema garantindo a consistência em todo o serviço de publicação e serviço de autorização para garantir que o mesmo pacote está sendo usado para autorização e publicação.
Os pesquisadores Kajetan Grzybowski e Maciej Piechota foram creditados por relatar com responsabilidade a falha por meio do programa de recompensa de bug de segurança do GitHub.
E, até agora, parece que não há evidências de exploração. A vulnerabilidade existia no registro npm “além do período de tempo para o qual temos telemetria para determinar se ela já foi explorada de forma mal-intencionada”, mas há alguma garantia.
O GitHub declarou com alta confiança que a vulnerabilidade não foi explorada de forma mal-intencionada desde pelo menos setembro de 2020, época em que a telemetria se tornou disponível.
“Validamos rapidamente o relatório, iniciamos nossos processos de resposta a incidentes e corrigimos a vulnerabilidade seis horas após o recebimento do relatório”, afirma o GitHub.
npm vai exigir autenticação de dois fatores a partir de 2022
Ambos os anúncios vêm não muito tempo depois que as bibliotecas populares do npm, ‘ua-parser-js,’ ‘coa’ e ‘rc’ foram sequestradas em uma série de ataques com o objetivo de infectar consumidores de software de código aberto com cavalos de Troia e cripto-mineradores.
Esses ataques foram atribuídos ao comprometimento de contas npm pertencentes aos mantenedores por trás dessas bibliotecas. Nenhum dos mantenedores dessas bibliotecas populares tinha a autenticação de dois fatores (2FA) habilitada em suas contas, de acordo com o GitHub.
Os invasores que conseguem sequestrar contas npm dos mantenedores podem publicar novas versões desses pacotes legítimos de maneira trivial, após contaminá-los com malware.
Como tal, para minimizar a possibilidade de tais comprometimentos se repetirem em um futuro próximo, o GitHub começará a exigir que os mantenedores do npm habilitem o 2FA, em algum momento no primeiro trimestre de 2022.
Quanto aos casos em que o malware de typosquatting e de confusão de dependência é publicado no npm a partir de uma conta de propriedade do invasor, em vez de uma conta sequestrada, o GitHub continua a investir em recursos e melhorias de segurança para automatizar a detecção de malware em tempo real em versões recém-publicadas de pacotes npm.