Em 21 de junho, um dos bots MEV mais ativos na rede Ethereum, Jaredfromsubway.eth, sofreu um ataque de "honeypot" cuidadosamente planejado, perdendo mais de US$ 7,5 milhões em ativos criptográficos. Abaixo está a análise da equipe de segurança da Beosin e o rastreamento do fluxo dos fundos roubados.
Análise do fluxo de ataque
Ataque à família de contratos
- Contrato coordenador (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): responsável por registrar se o bloco atual está no estado armed e, na fase final, chamar ciclicamente os contratos filhos para retirar os fundos. - Contrato gatilho (0x4de8c729a064ff6087cc84a4152969349e4feb98): responsável por definir, no mesmo bloco, o estado falso de pares de negociação, fazendo com que as rotas de arbitragem pareçam executáveis. - Contratos filhos / contratos de tokens falsos: disfarçam-se como tokens ERC-20 normais para obter autorizações reais. - Contrato Hub: responsável por pagar pequenos rendimentos reais, fazendo com que os bots MEV considerem a operação lucrativa. - Par Ring V2: par falso da Uniswap v2. - Contratos de tokens intermediários falsos: utilizados para construir rotas de arbitragem de múltiplos saltos, como fCAP, fUSDC.
O ponto-chave do ataque: enganar a autorização
Ao analisar transações na cadeia, o atacante criou vários conjuntos de transações isca:
- USDC de grande valor: o robô lucrou cerca de 36,997120 USDC, mas deixou 20 USDC autorizados. - USDT de grande valor: o robô lucrou cerca de 37,053440 USDT, mas deixou 20 USDT autorizados. - WETH de grande valor: o robô lucrou cerca de 0,0179 WETH, mas deixou 16 WETH autorizados. - As transações de pequeno valor funcionaram normalmente, com as autorizações sendo consumidas na mesma transação para reduzir suspeitas.
Em transações de pequeno valor, após o robô autorizar o crédito de tokens reais, o contrato filho transfere imediatamente os tokens reais, consumindo a autorização, o que parece totalmente normal.
Em transações de grande valor, o contrato filho não chama o transferFrom para transferir os tokens reais, mas sim cria tokens falsos diretamente por meio de transações falsificadas. O robô acredita ter concluído as etapas preliminares normais do swap, mas a autorização dos tokens reais ainda permanece válida.
Essa é a essência do ataque: transações de pequeno valor consomem normalmente a autorização, enquanto transações de grande valor mantêm a autorização.
Processo de ataque
Como exemplo de uma operação de ataque contra o USDC:
(1) O atacante chama o coordenador para definir o bloco atual como armed. (2) O atacante chama o gatilho para atualizar o estado de múltiplos pares Ring V2 falsificados. (3) O MEV Bot detecta uma oportunidade de arbitragem e executa a transação.
O fluxo interno da negociação do MEV Bot é aproximadamente o seguinte:
(1) O contrato MEV Bot autorizou um grande valor de USDC para um contrato filho. (2) O contrato MEV Bot chamou a função wrapTo/wrap do contrato filho. (3) Como o estado atual do contrato filho está em "armed", ele não consome USDC real, mas emite tokens falsos para o par, mantendo a autorização de USDC. (4) O contrato MEV Bot continua chamando o swap do par falsificado. (5) O segundo par de troca envia os tokens ao MEV Bot. (6) O contrato hub paga ao MEV Bot um pequeno lucro em USDC real.
exemplo de aprovação
hash da transação: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
Resultado visto pelo MEV Bot: uma operação de arbitragem bem-sucedida gerou lucro real em USDC. No entanto, a autorização do USDC foi mantida pelo subcontrato. Esse processo foi repetido separadamente para USDC, USDT e WETH, resultando em um grande número de autorizações.
O hash da transação atacada é:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
O atacante chama o loop de drenagem do contrato coordenador, com os dados de chamada contendo 66 endereços de contratos filhos e o endereço do contrato MEV Bot. Sempre que o contrato MEV Bot tiver previamente concedido autorização de limite aos contratos filhos, esses contratos filhos poderão transferir diretamente os tokens reais correspondentes para o atacante.
Resultado final:
- 20 autorizações de grande valor de USDC foram totalmente consumidas - 16 autorizações de grande valor de WETH foram totalmente consumidas - Ainda existe uma autorização parcial de USDT, mas o saldo de USDT é insuficiente
Análise de fluxo de fundos
Após o ataque bem-sucedido, o endereço do atacante (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) recebeu $2,87M USDC, $2,04M USDT e 1.474 WETH. Em seguida, o atacante trocou as stablecoins por ETH e transferiu para os seguintes 4 endereços:
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (aproximadamente 1.000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1.001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1.001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1.423 ETH)
Dos quais, 0xe3Da3 transferiu 1.000 ETH para o Tornado Cash, enquanto os outros três endereços não realizaram transferências adicionais de ETH. O fluxo de fundos é mostrado abaixo:
Conclusão
Este ataque demonstra um método altamente sofisticado: o atacante não ataca diretamente o código do contrato, mas, com base na lógica de negócios do MEV Bot, cria cenários de arbitragem específicos para induzir o MEV Bot a autorizar operações que parecem seguras, resultando finalmente na transferência de seus ativos. Para robôs de arbitragem e MEV Bots, não basta depender apenas da simulação de lucros para avaliar a segurança de uma rota; especialmente quando a rota de arbitragem inclui contratos desconhecidos, tokens falsificados ou wrappers personalizados, deve-se agir com cautela e considerar a verificação obrigatória das alterações no allowance após a transação.