O Maior Ataque de Malware de Cadeia de Suprimentos (Até Agora) e Por Que Pode Não Ter Sido Tão Ruim
Um ataque de malware na cadeia de suprimentos, possivelmente um dos maiores já vistos, ocorreu recentemente. Estima-se que o malware tenha sido baixado até 50 milhões de vezes antes de ser detectado. Surpreendentemente, embora tenha sido massivo em potencial, talvez o dano real causado tenha sido mínimo. Mas como isso é possível? E como esse ataque foi distribuído?
A Distribuição Via NPM
A distribuição desse malware ocorreu através do **NPM** (Node Package Manager), que é um gerenciador de pacotes para JavaScript. Essencialmente, ele permite que desenvolvedores baixem ferramentas de código-fonte pré-prontas para incorporar em seus próprios softwares.
Por exemplo, se você está desenvolvendo um aplicativo e precisa de uma função específica, como a conversão de um tipo de arquivo ou formato de dados, em vez de codificar tudo manualmente, é provável que alguém já tenha criado um pacote para isso. O desenvolvedor então baixa esse pacote e o inclui em seu código. Qualquer pessoa pode criar um projeto e publicá-lo no NPM para que outros façam o download, geralmente utilizando uma conta para essa finalidade.
O Ataque de Phishing
O incidente começou quando o desenvolvedor responsável por muitos pacotes extremamente populares, que somavam cerca de **2,5 bilhões de downloads semanais**, sofreu um ataque de *phishing*. Tudo indica que foi um ataque de *spear phishing* direcionado.
Assim que os hackers obtiveram acesso à conta NPM do desenvolvedor, eles não perderam tempo. Eles publicaram versões maliciosas dos pacotes, promovendo-as como novas atualizações. Com a enorme popularidade desses pacotes, isso significava um volume altíssimo de downloads.
Estima-se que, a cada segundo em que essas versões maliciosas estiveram disponíveis, houve cerca de **4.000 downloads**. Como os pacotes ficaram ativos por aproximadamente duas a três horas, o número total de downloads pode ter chegado em torno de 45 milhões.
É crucial notar que o impacto não se restringiria apenas àqueles que baixaram diretamente os pacotes. Como esses pacotes são incorporados a softwares, os usuários finais desses aplicativos seriam os alvos finais. Além disso, o risco se espalha: se um aplicativo depende de um pacote, e outro pacote depende do pacote infectado, a instalação do segundo implicaria na instalação do código malicioso. Alguns pacotes populares tinham mais de 120.000 dependências (outros pacotes que dependiam deles), e outro tinha 55.000.
Felizmente, as versões maliciosas foram rapidamente identificadas e removidas (“nuked”). Isso impossibilitou a checagem exata de quantas vezes foram baixadas, pois as estatísticas do NPM podem demorar a ser atualizadas após a remoção.
O Que o Malware Fazia?
O objetivo principal desse malware era **roubar transações de criptomoedas**. Ele foi programado para detectar se estava sendo executado dentro de uma janela de navegador embutida. Se detectado, ele ativava dois modos de ataque diferentes.
É importante reconhecer que muitas aplicações utilizam janelas de navegador embutidas, não apenas navegadores web tradicionais. Exemplos incluem:
- Spotify
- Microsoft Teams
- Slack
- Discord
- Steam
- Extensões de navegador
- Aplicativos móveis
- Aplicativos de carteira (wallets)
Modo de Ataque 1: Substituição Direta de Endereços
Neste modo, o malware verificava se a página web exibida na janela do navegador continha um endereço de criptomoeda. Se encontrasse, ele **substituía esse endereço por um endereço pré-codificado** dentro do próprio malware. Assim, se um usuário fosse pagar seguindo um endereço de pagamento exibido em um site, ele estaria, sem saber, enviando os fundos para o hacker.
Modo de Ataque 2: Interceptação de Transações de Carteira
Este modo era mais sofisticado. Ele era projetado para detectar se estava rodando em conjunto com uma carteira de criptomoedas (talvez porque o pacote malicioso estivesse sendo usado em um projeto de carteira ou extensão).
Nesse cenário, o malware interceptava a solicitação de transação que passava entre o site e a extensão da carteira. Ele **substituía o endereço de destino** antes que a transação fosse assinada. O site poderia mostrar um endereço, mas a solicitação recebida pela carteira seria diferente. Se o usuário não verificasse cuidadosamente o endereço ao assinar, acabaria assinando uma transação maliciosa.
Para dificultar a detecção visual, o malware possuía cerca de 40 endereços pré-codificados para várias criptomoedas diferentes. Ele verificava qual criptomoeda na lista era a mais próxima da transação em andamento, tornando a manipulação mais sutil.
O Ataque Funcionou?
Apesar da escala da distribuição, o sucesso financeiro do ataque parece ter sido pequeno. O endereço de Ethereum associado a essas transações continha cerca de mil dólares no momento da análise, mas não está claro quanto disso veio de vítimas reais versus testes ou envio de tokens lixo.
Ainda assim, considerando a quantidade de malware distribuída, o resultado foi modesto. No entanto, há uma ressalva importante: embora o malware tenha sido detectado em poucas horas, se um desenvolvedor atualizou seus pacotes ou baixou um pacote infectado *durante* essa janela de poucas horas, e nunca mais atualizou o projeto, **teoricamente, esse projeto pode continuar infectado**.
Felizmente, espera-se que fabricantes de antivírus possam criar assinaturas para o arquivo malicioso, permitindo a detecção mesmo se ele estiver incorporado em um aplicativo final.
Como o Desenvolvedor Foi Vítima do Phishing?
O método usado para comprometer a conta do desenvolvedor não foi particularmente complexo. Ele admitiu ter caído em um e-mail de *phishing* que parecia legítimo enquanto estava usando o celular.
A mensagem pedia para que ele redefina sua autenticação de dois fatores. Em vez de navegar diretamente para o site oficial do NPM para realizar o procedimento, ele clicou no link contido no e-mail. O link não apontava para o domínio oficial do NPM, mas sim para um domínio **.help**, o que ele não percebeu imediatamente.
É importante notar que os hackers comprometeram apenas a conta **NPM**. A conta GitHub do desenvolvedor não foi acessada, o que significa que o código malicioso foi carregado diretamente no gerenciador de pacotes, e não através de *commits* ou lançamentos no GitHub.
Precauções a Tomar
Para usuários de criptomoedas, o uso de uma carteira de hardware é sempre recomendado. Em relação a este ataque específico, a proteção dependeria do modo de ataque:
1. **Modo 2 (Interceptação):** Era possível detectar a fraude inspecionando o endereço cuidadosamente antes de assinar, algo que os usuários já deveriam fazer.
2. **Modo 1 (Substituição Direta):** Neste caso, o usuário não teria como saber que o endereço exibido já havia sido substituído pelo malware.
Em resumo, o ataque foi detectado muito rapidamente e provavelmente não infectou muitas pessoas com sucesso. Ataques de cadeia de suprimentos como este tendem a se tornar mais comuns. Eles lembram ataques anteriores, como o *malware* de compressão XZ, que foi extremamente sorrateiro, com o hacker contribuindo cautelosamente para um projeto por um ano apenas para introduzir o código malicioso. Felizmente, esse também foi detectado, embora o XZ visasse uma gama muito mais ampla de softwares, e não apenas carteiras de criptomoedas.
