Le 21 juin, l'un des MEV Bot les plus actifs sur le réseau Ethereum, Jaredfromsubway.eth, a été victime d'une attaque par "pot de miel" (honeypot attack) minutieusement conçue, entraînant la perte de plus de 7,5 millions de dollars d'actifs cryptographiques. Voici l'analyse de cette attaque par l'équipe de sécurité Beosin et le suivi de la circulation des fonds volés.
Analyse du déroulement de l'attaque
Famille de contrats d'attaque
- Contrat coordinateur (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52) : Responsable de l'enregistrement de l'état "armed" du bloc actuel et, à la phase finale, de l'appel en boucle des sous-contrats pour extraire les fonds.
- Contrat déclencheur (0x4de8c729a064ff6087cc84a4152969349e4feb98) : Responsable de la définition de faux états de paires d'échange dans le même bloc, rendant le chemin d'arbitrage apparemment exécutable.
- Sous-contrats / Contrats de faux jetons : Déguisés en jetons ERC-20 normaux, utilisés pour obtenir des autorisations réelles.
- Contrat Hub : Responsable du paiement d'un petit bénéfice réel, rendant le MEV Bot rentable.
- Ring V2 pair : Fausse paire d'échange Uniswap v2.
- Contrat de faux jeton intermédiaire : Utilisé pour construire des chemins d'arbitrage multi-sauts, comme fCAP, fUSDC.
La clé de l'attaque : Tromper l'autorisation
En analysant les transactions sur la chaîne, l'attaquant a construit plusieurs ensembles de transactions appâts :
- Gros montant USDC : Le robot a réalisé un bénéfice d'environ 36,997120 USDC, mais a laissé une autorisation de 20 USDC.
- Gros montant USDT : Le robot a réalisé un bénéfice d'environ 37,053440 USDT, mais a laissé une autorisation de 20 USDT.
- Gros montant WETH : Le robot a réalisé un bénéfice d'environ 0,0179 WETH, mais a laissé une autorisation de 16 WETH.
- Les transactions de petits montants apparaissaient normales, l'autorisation étant consommée dans la même transaction, afin de réduire les soupçons.
Dans les transactions de petits montants, après que le robot a accordé une autorisation pour un montant réel de jetons, le sous-contrat transférait immédiatement les vrais jetons, l'autorisation était consommée et tout semblait parfaitement normal.
Dans les transactions de gros montants, le sous-contrat n'appelait pas transferFrom pour déplacer les vrais jetons, mais frappait directement de faux jetons via la fausse paire d'échange. Le robot pensait avoir accompli les étapes préalables normales d'un swap, mais l'autorisation pour les vrais jetons était toujours conservée.
C'est le cœur de toute l'attaque : les transactions de petits montants consomment normalement l'autorisation, les transactions de gros montants la conservent.
Déroulement de l'attaque
Prenons l'exemple de la transaction d'attaque ciblant l'USDC :
(1) L'attaquant appelle le coordinateur pour définir le bloc actuel comme "armed".
(2) L'attaquant appelle le déclencheur pour mettre à jour l'état de plusieurs fausses paires Ring V2.
(3) Le MEV Bot détecte l'opportunité d'arbitrage et exécute la transaction.
Le processus interne approximatif de la transaction du MEV Bot est le suivant :
(1) Le contrat du MEV Bot accorde une autorisation importante en USDC à un sous-contrat.
(2) Le MEV Bot appelle la fonction wrapTo/wrap du sous-contrat.
(3) Le sous-contrat, en raison de l'état "armed" actuel, ne consomme pas les vrais USDC mais frappe de faux jetons vers la paire, l'autorisation USDC est conservée.
(4) Le MEV Bot continue d'appeler le swap de la fausse paire.
(5) La seconde paire envoie les jetons au MEV Bot.
(6) Le contrat hub paie un petit bénéfice réel en USDC au MEV Bot.
Exemple d'autorisation (approval)
Hash de transaction : 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
Ce que le MEV Bot a vu : une transaction d'arbitrage réussie, générant un bénéfice réel en USDC. Mais l'autorisation USDC a été conservée par le sous-contrat. Ce processus a été répété pour l'USDC, l'USDT et le WETH, aboutissant finalement à de nombreuses autorisations.
Le hash de la transaction d'attaque est :
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
L'attaquant appelle la boucle de drainage (drain loop) du contrat coordinateur, le calldata contenant 66 adresses de sous-contrats ainsi que l'adresse du contrat MEV Bot. Tant que le contrat MEV Bot avait laissé une autorisation de montant à ces sous-contrats auparavant, ceux-ci pouvaient directement transférer les vrais jetons correspondants à l'attaquant.
Résultat final :
- Les 20 autorisations importantes en USDC ont été entièrement consommées.
- Les 16 autorisations importantes en WETH ont été entièrement consommées.
- Une partie des autorisations USDT existe toujours, mais le solde USDT est désormais insuffisant.
Analyse du flux des fonds
Après le succès de l'attaque, l'adresse de l'attaquant (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) a reçu 2,87 M$ d'USDC, 2,04 M$ d'USDT et 1 474 WETH. Ensuite, l'attaquant a converti les stablecoins en ETH et les a transférés vers les 4 adresses suivantes :
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (environ 1 000 ETH)
- 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1 001 ETH)
- 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1 001 ETH)
- 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1 423 ETH)
Parmi elles, 0xe3Da3 a transféré 1 000 ETH vers Tornado Cash. Les ETH des trois autres adresses n'ont pas fait l'objet de transferts ultérieurs. Leur flux de fonds est illustré ci-dessous :
Conclusion
Cette attaque démontre un mode opératoire hautement sophistiqué : l'attaquant n'attaque pas directement le code du contrat, mais, en se basant sur la logique métier du MEV Bot, construit des scénarios d'arbitrage correspondants pour induire le MEV Bot à accorder des autorisations en apparence sans problème, avant de transférer ses actifs. Pour les robots d'arbitrage et les MEV Bots, il ne suffit pas de se fier uniquement à la simulation des bénéfices pour juger de la sécurité d'une route. Il convient d'être particulièrement prudent lorsque le chemin d'arbitrage contient des contrats inconnus, des faux jetons ou des wrappers personnalisés, et de prévoir éventuellement une vérification obligatoire des changements d'autorisation (allowance) après les transactions.
Voir l'article original









