O npm lançou uma nova proteção esta semana para suas contas mais dependentes. Quando o npm detecta uma ação sensível em uma conta de alto impacto, como uma troca de e-mail ou o uso de um código de recuperação de 2FA, ele coloca essa conta em um estado somente leitura por 72 horas e envia um alerta para o endereço de e-mail anterior. As instalações e downloads de pacotes continuam funcionando normalmente durante esse período, e o bloqueio é removido automaticamente ao final do período de espera.
Esta atualização impede ações que afetam a segurança do registro ou da conta, como publicação, gerenciamento de tokens, alterações de visibilidade de pacotes e alterações de associação a organizações. É um controle em nível de registro para identificar rapidamente quando uma conta começa a escapar das mãos de seu proprietário.
Isso é ótimo, e é apenas a mais recente de uma série de melhorias de segurança do npm. Eles nos deram a publicação em etapas em maio e bloquearão scripts postinstall por padrão na v12 em julho. Os padrões estão lentamente se inclinando para a prevenção e se afastando da reação. A Microsoft tem trabalhado bastante em correções de segurança ultimamente, provavelmente inspirada por uma série de ataques de malware ocorrendo em suas plataformas (e às suas plataformas).
O npm não reafirmou um limite para este recurso, mas já usou o termo antes. Sua política de aplicação de 2FA define uma conta de alto impacto como aquela que gerencia pacotes com mais de 1 milhão de downloads semanais ou 500 dependentes, e o período de resfriamento provavelmente usa os mesmos critérios.
O ímpeto para esta mudança
O recente comprometimento do axios em março e o ataque Mastra na semana passada são os exemplos mais claros na memória recente sobre a necessidade disso. Esses ataques usaram campanhas de engenharia social contra as contas-alvo para obter acesso. No caso do axios, o atacante se passou por um fundador da empresa e atraiu um mantenedor líder para uma videochamada. O link da chamada continha um aviso de "seu sistema está desatualizado" que instalou um trojan de acesso remoto (RAT), entregando ao atacante o controle da máquina da vítima e uma sessão npm ativa. Eles alteraram o e-mail da conta e, em seguida, publicaram duas versões maliciosas do axios diretamente, evitando todo o sistema de CI. O axios tem cerca de 100 milhões de downloads por semana.
Este tipo de ataque é praticamente invisível para o registro, como os passos no Slack e a máquina comprometida. A mudança de e-mail é o único passo na sequência que o npm consegue visualizar. Os atacantes mudam os e-mails porque isso corta o caminho de recuperação do verdadeiro proprietário e redireciona os alertas de segurança para longe deles.
Como isso se encaixa com outras mudanças de segurança do npm
O período de resfriamento é ainda mais útil quando considerado em conjunto com as duas correções que o npm lançou no último ano ou mais.
A publicação confiável remove tokens de longa duração. A publicação autentica-se através de credenciais OIDC de curta duração, com escopo para um fluxo de trabalho de CI, de modo que não há um token de longa duração em uma máquina para um RAT roubar. No entanto, isso não faz nada quando um atacante detém uma sessão ativa e publica diretamente.
A publicação em etapas, que recebemos no mês passado, adiciona uma etapa de aprovação humana. Um pacote preparado a partir do CI não entra em produção até que um mantenedor o aprove com 2FA, de modo que um fluxo de trabalho automatizado sozinho não pode enviar um lançamento para o mundo. Um atacante que controla a conta pode contornar isso aprovando seu próprio pacote em etapas, se o pacote tiver essa opção habilitada.
Juntos, a publicação confiável lida com credenciais roubadas, a publicação em etapas lida com lançamentos automatizados não revisados, e o período de resfriamento lida com a tomada de conta que os outros dois contornam. Claro, isso não resolve tudo, mas se você tiver publicação confiável apenas em etapas e tokens desabilitados, você estará prevenindo uma boa parte dos caminhos de publicação que os atacantes têm usado.
O que fazer agora
Se você mantém um pacote popular, verifique se o e-mail da sua conta npm é um que você controla e realmente monitora (caso contrário, você perderá o alerta por e-mail). Mude para FIDO2 onde puder. Trate um aviso inesperado de mudança de e-mail como um incidente de segurança, e não como spam ou um bug. Se você publica a partir do CI, configure a publicação confiável apenas em etapas e desabilite os tokens, para que cada lançamento passe por uma aprovação humana, e não haja credenciais de longa duração para roubar. Se você receber um e-mail inesperado sobre uma alteração de conta, entre em contato com o suporte do npm.
Se você consome pacotes em vez de publicá-los, parabéns! Você se beneficia sem fazer nada. Ainda assim, alguns pacotes não terão todas as suas medidas de segurança ativadas (muitos ainda não têm essas configurações de segurança habilitadas). Safe Chain da Aikido é um wrapper gratuito e de código aberto para npm, npx e yarn que verifica cada pacote em busca de malware antes da instalação e impõe um período de espera para novas versões, o que detecta uma boa parte dos lançamentos comprometidos antes que cheguem à sua máquina.
Tem sido ótimo poder escrever sobre as mudanças positivas nos registros de pacotes ultimamente.
