Nós realmente evitamos uma grande ameaça

• O recente ataque à cadeia de suprimentos no ecossistema de pacotes NPM poderia, na prática, ter causado danos muito maiores
• O invasor usou o código malicioso apenas para alterar endereços de carteiras de criptomoedas ao explorar bibliotecas populares
• O ataque foi realizado por meio de e-mails de phishing sofisticados para roubar as credenciais de autenticação em dois fatores de desenvolvedores
• Se tivesse sido usado de forma mais letal, como para roubo de chaves de API, havia potencial para danos massivos
• O caso reforça a percepção de que todas as dependências são potencialmente arriscadas e destaca a importância de entender toda a árvore de dependências

---

Visão geral do ataque e preocupações

• Recentemente, pacotes populares no NPM, um dos maiores ecossistemas de pacotes, foram expostos a um ataque
  • Exemplos de função: tratamento de cores no terminal, mapeamento de nomes de cor para RGB, decoradores de depuração de funções, utilitários para identificar valores semelhantes a arrays etc.
• Essas dependências comuns são amplamente usadas e, quando código entra nelas, há grande chance de ele ser implantado imediatamente em ambientes de produção
• Se tivessem incluído proxy malicioso, roubo de chaves de API ou outros ataques graves, o resultado poderia ter sido muito pior
• Na prática, esse malware apenas adulterava endereços de pagamento em carteiras online (como a MetaMask)

A sofisticação do ataque de phishing

• O ponto de partida do ataque foi um e-mail de phishing muito bem elaborado
  • Usava o nome de usuário do NPM para passar uma impressão personalizada
  • Induzia confiança com a mensagem de que era preciso “alterar a senha e as credenciais de autenticação de dois fatores por segurança”
  • O conteúdo foi montado de forma que um usuário comum poderia cair facilmente, em combinação com particularidades da operação do NPM
  • Indicava um prazo específico para criar urgência e levar a pessoa, em meio à correria, a clicar no link de phishing sem atenção
  • Usava um domínio .help semelhante ao domínio oficial do NPM
• A parte mais perceptível era o uso de "npmjs.help" em vez do domínio oficial
  • Hoje em dia, vários novos gTLDs (Generic Top Level Domains) são amplamente usados em blogs e documentações, então isso também pode parecer natural

Danos potenciais do ataque

• O e-mail de phishing podia roubar as credenciais de autenticação em dois fatores do usuário e, depois, permitir a publicação de novos pacotes com código malicioso inserido
• Bibliotecas muito usadas como is-arrayish, color-string, color-name estavam entre os alvos
  • Se o malware tivesse ido além de simplesmente interceptar criptomoedas e evoluído para roubo de chaves de API, poderia ter causado consequências fatais
  • Por exemplo, poderia haver exposição em massa de chaves de API da OpenAI, AWS etc., gerando danos duradouros e em larga escala
• Na prática, a maioria das bibliotecas infectadas era usada principalmente em ferramentas de linha de comando, então o objetivo de roubo de criptomoedas era relativamente limitado

Alvo no ecossistema Web3 e estratégia do invasor

• Este ataque parece ter tido como alvo principal usuários de Web3 (como quem faz pagamentos pelo navegador)
  • Ao mirar bibliotecas genéricas sem relação direta com Web3, o invasor evitou a rápida identificação e bloqueio por parte do ecossistema Web3
  • Ex.: mesmo inspecionando cuidadosamente bibliotecas integradas ao MetaMask, seria difícil prever um ataque vindo de um utilitário relacionado à cor de texto

Lições para o ecossistema de desenvolvimento

• Este caso reforça que qualquer pacote de dependência pode, de fato, ser malicioso
  • Há limites práticos para controlar ou monitorar totalmente a árvore de dependências o tempo todo
  • Também sugere que, sob fluxos rápidos de deploy em produção e pressão de tempo, a revisão de segurança pode inevitavelmente ficar em segundo plano
• Daqui para frente, cresce a importância de entender a composição completa das dependências do projeto e gerenciá-las com mais cautela

Encerramento e aviso

• Este conteúdo não busca culpar nem responsabilizar ninguém em particular; o importante é reconhecer que qualquer pessoa pode ser exposta a ataques de phishing
• Como a situação pode mudar após a publicação deste post, se houver dúvidas ou possível erro no conteúdo, é necessário verificar diretamente

Tags:

[GN⁺]

Comentário no Hacker News

• O ataque à cadeia de suprimentos do nx no npm foi uma bala que muitas empresas não conseguiram desviar; bastava instalar o plugin nx do VS Code para ele verificar automaticamente a versão mais recente do nx no npm, e, se houvesse credenciais importantes em uma sessão do GitHub (por exemplo, login na conta corporativa pelo GH CLI) ou em arquivos .env, tudo teria sido vazado; isso era algo impossível de evitar mesmo com bom controle de pinagem de dependências ou atualizações de segurança; mudanças mais profundas são necessárias nesse ecossistema; para mais detalhes, veja o aviso oficial de segurança

  • Estou evitando tudo relacionado a NPM; a única exceção é o compilador TypeScript, mas, se ele for reescrito em Go, pretendo remover até isso; no caso do Go, a possibilidade de especificar versão mínima é excelente, e o fato de nunca executar o que foi baixado nem mesmo durante o processo de compilação também; no NPM, muitas vezes o código-fonte difere do GitHub, e eu o considero não confiável
  • Extensões de editor são alvos muito atraentes de ataque porque são instaladas e atualizadas automaticamente em ambientes de desenvolvimento de alto risco; fico me perguntando por que ainda não houve algo como as aquisições em massa maliciosas que vemos com extensões de navegador; ouvi dizer que a equipe do VSCode dedica muito esforço à detecção de malware, mas tenho curiosidade se todos os editores, como o Sublime, têm algum processo de verificação desse tipo
  • Eu mantenho todos os pacotes e bancos de dados localmente e trabalho na máquina de desenvolvimento em modo avião; só ligo a internet na hora de fazer git push

• Escapamos por muito pouco de uma situação realmente crítica; é difícil acreditar que um atacante com acesso a esses pacotes tenha colocado apenas uma ferramenta para roubo de criptomoedas; se fosse uma oportunidade dessas, eu imagino que valeria a pena investir mais uma semana e embutir exploits mais sofisticados; há API keys, adição de chaves públicas SSH, vazamento de IPs de servidores, perfis de navegador ou tokens de sessão no dispositivo do desenvolvedor, até mesmo dados de cartão da Amazon no meu desktop; há coisa demais para roubar; mesmo que o invasor não use isso diretamente, tudo poderia ser facilmente vendido em fóruns da dark web; às vezes me pergunto se os cibercriminosos realmente competentes já não estão empregados em empresas de tecnologia estáveis e bem remuneradas, e por isso só sobram ataques simples como esse

  • Como esse tipo de ataque certamente seria descoberto rápido, parece que a estratégia não era ser furtivo, mas dominar completamente a conta, ou seja, fazer um ataque rápido e sair logo; era preciso uma forma de arrancar o máximo de dinheiro possível com automação em poucas horas, e criptomoeda é a resposta óbvia; se não fosse algo capaz de esconder um backdoor mesmo com metade do mundo inspecionando o código, não havia motivo para preparar algo por mais tempo
  • Criptomoedas roubadas são recursos que, na prática, você certamente consegue manter, porque não dá para estornar, reembolsar nem recuperar a transação; já APIs de desenvolvedor ou chaves SSH quase não têm valor e, mesmo com sorte, no fim também precisam ser convertidas em dinheiro, o que acaba levando de volta a criptomoedas
  • Entrar rápido, roubar centenas de milhares de dólares, sair e repetir a mesma coisa meses depois; se conseguir evitar a polícia, dá para viver sem preocupação pelo resto da vida; até roubar chaves da AWS não rende tanto assim; também há criminosos que miram senhas ou bancos de dados de gerenciadores de senha, mas, no fim, eles frequentemente acabam mirando sites ligados a criptomoedas; certamente há criminosos esperando o momento certo para se infiltrar cuidadosamente em empresas, e eles ficarão escondidos até conseguirem sucesso sem se expor
  • Isso não é uma oportunidade única na vida; daqui para frente, criminosos vão perceber cada vez mais que basta mirar em alguns poucos "desenvolvedores" para ter acesso fácil a milhões de dólares, e métodos mais ousados vão continuar surgindo; se você mantém código open source, já chegou o ponto de pensar seriamente o quanto está escondendo sua identidade física na internet

• Para mim, procrastinar virou técnica de sobrevivência; como espero os outros fazerem o beta test primeiro, no passado usei só o Microsoft Office 2000 por 12 anos na empresa, e vivi 10 anos em paz sem problemas de upgrade nem retreinamento; e tenho o hábito de nunca clicar em links de email

  • Faço o mesmo com meu Honda e com Kubernetes; mantive um carro 2006 por muito tempo e, com isso, passei por cima de várias gerações de problemas grandes e pequenos na integração carro-celular; só recentemente, num carro 2023, a conexão com iPhone ficou realmente muito fluida; com Kubernetes foi parecido: como adiei por muito tempo a sugestão do meu chefe, só fui migrar agora, quando EKS, GKE etc. já amadureceram bastante, e isso reduziu muito o sofrimento da migração; se eu tivesse seguido a ideia imediatamente 6 ou 7 anos atrás, acho que teria passado por um inferno
  • No ecossistema npm, se você não atualiza a cada 54 segundos, já está muito atrasado
  • É eficaz contra novos pacotes maliciosos, mas não ajuda se um software já infectado ainda pegar um worm
  • Respondo amanhã
  • "Adiar por padrão o uso de uma nova versão por 2 semanas" é uma defesa muito eficaz contra ataques à cadeia de suprimentos

• Para startups pequenas isso pode ser difícil, mas acho que um player grande como o npm deveria registrar preventivamente o domínio npm em todas as versões de TLD, como "npm.io", "npm.sh", "npm.help" etc.; o fato de o atacante ter conseguido o domínio "npm.help" tornou esse ataque ainda mais eficaz

  • Acontece muito de empresas como a AWS alertarem os clientes para ficarem atentos a phishing e, ao mesmo tempo, mudarem o endereço oficial de email de cobrança de [e-mail] para [e-mail]; como é um endereço que você nunca viu antes, ele praticamente parece um phishing, mas dizem que é oficial, então a situação fica confusa; até o email de aviso prévio parece phishing, então eu não abro o PDF anexo até receber a fatura de verdade; as empresas dizem aos clientes para tomar cuidado com phishing, mas ao mesmo tempo criam confusão desnecessária
  • Existem mais de 1.500 TLDs e, ainda que alguns sejam restritos ou códigos de país, fico curioso sobre qual seria o custo anual real de registrar todos eles; deve até existir algum SaaS que faça isso
  • Olhando a lista de TLDs, há domínios demais; mesmo para empresas grandes, ainda que faça sentido tentar registrar TLDs parecidos para reduzir phishing, não acho que seja possível bloquear isso de forma perfeita
  • A primeira coisa é sempre verificar se o domínio é realmente oficial; se for um domínio registrado recentemente por um registrar barato ou com pouco tempo restante até expirar, eu desconfio na hora; especialmente se o link vier pressionando a pessoa com algo como "não há tempo", enfatizando prazo final e coisas do tipo; acho correto que comunicações oficiais usem apenas o domínio principal conhecido (ou um subdomínio dele)
  • Os nomes de domínio do npm e parecidos têm variações sem fim, então é inviável bloquear isso na prática apenas registrando tudo; só de olhar o nome do domínio já dá para suspeitar de phishing, mas a realidade é que até um domínio como npmjs.help pode acabar sendo clicado por engano

• E se alguém combinar algo extremamente meticuloso (no estilo Jia Tan) com a nossa segurança frouxa em plugins de editor, shell userland e afins? Ferramentas para desenvolvedores rodam com privilégios de superusuário, mas são justamente as menos auditadas; eu mesmo não consigo auditar uma por uma tudo de elisp, neovim, vscode e até ferramentas simples de userland; no melhor cenário, pego algo do nixpkgs; basta alguém lançar um plugin melhor para VSCode e esperar 1 ou 2 anos; GG

  • Espero que algum dia alguém realmente resolva o problema do xkcd 1200

• Carteiras como MetaMask foram alvo, mas ouvi dizer que o MetaMask é relativamente bem protegido contra esse tipo de ataque graças a um módulo de isolamento chamado LavaMoat; eu realmente gostaria de ver uma análise detalhada do nível real de proteção; pessoalmente não tenho relação com o MetaMask, mas tenho curiosidade sobre a eficácia desse tipo de resposta de segurança (que costuma ser mais lenta do que os ataques reais); deixo como referência este artigo relacionado

• Sobre a frase "a verdade é que, no fim, você vai cair em um ataque de phishing desses algum dia", eu acho que comigo provavelmente não; tenho o hábito de jamais inserir credenciais em links de emails que eu mesmo não solicitei (por exemplo, redefinição de senha); acho que é uma habilidade de segurança que todo mundo precisa dominar em 2025

  • Quando se fala "'desse tipo' de phishing", parece algo sofisticado, mas na prática foi só mais um caso de desenvolvedor caindo num email de phishing absolutamente comum; foi um erro muito básico e, às vezes, num nível que nem alguém do administrativo cairia; claro que qualquer um pode errar, mas acho que descuido evidente e erro amador são o que fazem esse tipo de coisa se repetir

• Ao contrário da descrição da matéria de que "todo o malware apenas trocava endereços de carteiras de criptomoedas", o motivo de o MetaMask não ter sido afetado foi:

1. o pacote não foi atualizado imediatamente no momento do ataque e
2. o MetaMask estava protegido com LavaMoat tanto na instalação quanto na execução; enquanto isso, esse payload malicioso tentava mirar páginas web usadas por outras carteiras que interagem com o MetaMask; para referência, eu participei do desenvolvimento do LavaMoat; para mais informações, veja o GitHub do LavaMoat

• Grandes repositórios abertos de pacotes precisam de soluções de segurança muito mais fortes, ou então de pelo menos um conjunto central de pacotes confiáveis e auditados; o mesmo vale para ecossistemas como Python e Rust, que também funcionam muito na base da confiança

  • O problema fundamental do npm é a ausência de namespaces obrigatórios; iniciantes em Java reclamam que "por que não é tão fácil quanto o npm", mas, com o passar do tempo, eu valorizo cada vez mais a obsessão do Maven por controle de qualidade, inclusive o sistema de namespaces; POM xml é incômodo, mas a gestão conservadora de mudanças transmite confiança; artigo relacionado: Por que namespaces importam em repositórios públicos open source
  • Em um caso como este, em que a própria conta do mantenedor do pacote é comprometida, medidas estruturais como namespace não têm utilidade; a única solução é impedir que novas releases sejam aplicadas imediatamente, introduzindo atraso
  • Distribuições Linux também são baseadas em confiança, mas, para conseguir permissão para publicar um pacote, é preciso "provar" essa confiança, e existe todo um sistema para verificá-la; o NPM parece um sistema livre em que qualquer um pode publicar

• A afirmação de que "não há como impedir isso" aparece sempre nos ecossistemas que sofrem invasões com mais frequência

  • Exatamente esse é o problema; é uma conclusão preguiçosa demais