Este é o tipo de bug que mantém as equipas de protocolo acordadas à noite.
Um exploit de $5M no ZKSwap, possibilitado por uma única declaração deixada no lugar errado.
Aqui está uma análise aprofundada de como isso aconteceu e como a monitorização onchain poderia tê-lo impedido.
🧵
1/ No dia 9 de julho, o GMX foi hackeado por $42M.
Mas algo mais aconteceu nesse dia e quase ninguém notou: a ponte do ZKSwap foi silenciosamente drenada por $5M.
A parte interessante? Não houve nenhuma exploração sofisticada envolvida. Apenas uma função crítica que não fez... nada.
2/ ZKSwap é um zk-rollup construído na Ethereum.
Como muitos rollups, utiliza uma ponte para mover ativos entre L1 e L2.
Como medida de segurança, a ponte inclui um "Modo Exodus", uma forma para os usuários recuperarem fundos sem precisar do operador.
Em teoria, essa é uma ótima ideia. Na prática…
3/ O Modo Exodus permite que os usuários provem manualmente que possuíam tokens no último estado L2 verificado.
É um mecanismo de fallback: sem confiança, auto-custodial, não interativo.
Mas a implementação do ZKSwap tinha um erro fatal: A função responsável por verificar as provas não verificava nada.
Literalmente.
4/ Aqui está o código que deveria ter parado o ataque 👇
À primeira vista, parece um verdadeiro verificador de zk-proof.
Mas olhe de perto a primeira linha: return true;
É isso. Nada mais é executado.
5/ O resultado? Cada "prova" de retirada (não importa quão falsa) passou na validação.
O contrato aceitou reivindicações arbitrárias sobre saldos de tokens... e os creditou como se fossem reais.
Transformou um mecanismo de fallback sem confiança em uma torneira desprotegida.
6/ O atacante não precisava de exploits sofisticados - apenas chamadas repetidas para exit() com dados falsos.
Eles contornaram as verificações de saldo, retiraram através de múltiplos tokens e abusaram da lógica fraca de nulificadores para evitar a detecção.
Tudo isso enquanto o contrato dizia: ✅
7/ Isto não foi um caso obscuro.
Esta era a lógica central para a recuperação de ativos, deixada completamente aberta.
E como o Modo Exodus raramente é ativado, o caminho quebrado passou despercebido... durante meses.
8/ Aqui está o que deveria ter acionado alarmes:
• Modo Exodus sendo ativado após uma longa inatividade
• Dezenas de chamadas de retirada acontecendo todas ao mesmo tempo
• Aumento repentino nas mudanças de balancesToWithdraw
Tudo isso era visível e poderia ter sido interrompido com monitoramento onchain em tempo real.
9/ Qual é a lição?
• O código de emergência ainda é código de produção
• Caminhos de fallback não ajudam se não funcionarem
• Monitorização em tempo real não é opcional, é crítica para a sobrevivência
37,85 mil
422
O conteúdo apresentado nesta página é fornecido por terceiros. Salvo indicação em contrário, a OKX não é o autor dos artigos citados e não reivindica quaisquer direitos de autor nos materiais. O conteúdo é fornecido apenas para fins informativos e não representa a opinião da OKX. Não se destina a ser um endosso de qualquer tipo e não deve ser considerado conselho de investimento ou uma solicitação para comprar ou vender ativos digitais. Na medida em que a IA generativa é utilizada para fornecer resumos ou outras informações, esse mesmo conteúdo gerado por IA pode ser impreciso ou inconsistente. Leia o artigo associado para obter mais detalhes e informações. A OKX não é responsável pelo conteúdo apresentado nos sites de terceiros. As detenções de ativos digitais, incluindo criptomoedas estáveis e NFTs, envolvem um nível de risco elevado e podem sofrer grandes flutuações. Deve considerar cuidadosamente se o trading ou a detenção de ativos digitais é adequado para si à luz da sua condição financeira.