Análise do maior ataque de Hacker na área do Web3

No dia 21 de fevereiro de 2025, a carteira fria de Ethereum de uma conhecida plataforma de negociação sofreu um ataque sério, com cerca de 401.346 ETH, 15.000 cmETH, 8.000 mETH, 90.375 stETH e 90 USDT transferidos para um endereço desconhecido, totalizando um valor de cerca de 1,46 mil milhões de dólares.

O atacante, através de métodos de phishing cuidadosamente elaborados, conseguiu induzir os signatários da carteira multisig da plataforma a aprovar transações maliciosas. O processo de ataque é o seguinte:

1. O atacante implanta antecipadamente um contrato malicioso que contém uma porta dos fundos para transferência de fundos.
2. Alterar a interface do front-end do Safe, de modo que as informações da transação vistas pelo signatário não correspondam aos dados realmente enviados para a carteira de hardware.
3. Obter três assinaturas válidas através de uma interface falsa, substituir o contrato de implementação da carteira multi-assinatura Safe por um contrato malicioso, e assim controlar a carteira fria e transferir fundos.

A plataforma vítima contratou a Sygnia para realizar uma investigação forense, a fim de determinar a causa raiz do ataque, identificar a extensão e a origem do ataque, e desenvolver estratégias de mitigação de riscos. Os resultados da investigação mostram:

• Os recursos no bucket AWS S3 do Safe foram injetados com código JavaScript malicioso.
• O tempo de modificação dos recursos e os históricos de rede indicam que o código malicioso foi diretamente injetado no bucket AWS S3 do Safe.
• O código JavaScript injetado visa manipular transações, alterando o conteúdo da transação durante o processo de assinatura.
• O código malicioso tem condições de ativação específicas e é executado apenas quando a origem da transação corresponde a um endereço de contrato específico.
• Dois minutos após a execução da transação maliciosa, uma versão atualizada dos recursos JavaScript foi carregada, removendo o código malicioso.
• As evidências iniciais apontam que o ataque se originou da infraestrutura AWS da Safe.
• Atualmente, não foram encontrados sinais de que a infraestrutura da plataforma afetada tenha sido invadida.

Este incidente expôs problemas profundos na gestão de segurança e na arquitetura técnica da indústria de criptomoedas. O principal problema foi a invasão do serviço de armazenamento AWS, que levou à alteração do JavaScript, resultando na modificação do conteúdo das transações iniciadas pelo front-end do Safe. Se o front-end do Safe tivesse implementado uma verificação básica de SRI, mesmo que o JavaScript tivesse sido alterado, esse tipo de incidente poderia ter sido evitado. Ao mesmo tempo, a plataforma afetada não validou adequadamente as informações da transação antes de confirmá-las ao usar carteiras de hardware, e essa confiança excessiva no front-end do Safe também é um problema chave.

As carteiras de hardware têm limitações ao lidar com transações complexas, não conseguindo analisar e exibir completamente os dados detalhados das transações de carteiras multi-assinatura, levando os signatários a realizar "assinaturas cegas" sem verificar completamente o conteúdo da transação.

Com o rápido desenvolvimento da tecnologia Web3, as fronteiras entre a segurança do front-end e a segurança da blockchain estão cada vez mais borradas. Vulnerabilidades tradicionais do front-end (como XSS, CSRF) apresentam novas dimensões de ataque no ambiente Web3, enquanto vulnerabilidades de contratos inteligentes, falhas na gestão de chaves privadas e outros problemas ampliam ainda mais os riscos.

Para enfrentar esses desafios, a indústria precisa adotar as seguintes medidas:

1. Implementar a verificação de assinatura estruturada EIP-712, garantindo que o frontend gere dados verificáveis e que o contrato inteligente verifique a assinatura.
2. Atualizar o firmware da carteira de hardware para suportar EIP-712 e forçar a correspondência semântica na cadeia.
3. Melhorar significativamente a segurança dos dispositivos, a verificação de transações e os mecanismos de controle de risco.
4. O desenvolvimento front-end deve realizar uma verificação rigorosa em etapas como acesso ao DApp, conexão de carteira, assinatura de mensagens, assinatura de transações e processamento pós-transação.
5. Realizar auditorias de segurança em contratos na blockchain regularmente.

Só através de medidas de segurança multilaterais e abrangentes é que é possível proteger efetivamente o valor e a confiança de cada transação no ambiente aberto do Web3, realizando a transição de "reparação passiva" para "imunidade ativa".