Écrit par : imToken
Un bot MEV qui chassait depuis longtemps les traders ordinaires sur Ethereum est finalement tombé dans un piège « sur mesure » d'une valeur de 7,5 millions de dollars.
Le 21 juin, le célèbre bot d'arbitrage de type "sandwich" sur Ethereum, Jaredfromsubway.eth, a été attaqué. Les actifs du portefeuille, tels que le WETH et l'USDC, ont été transférés, avec des pertes initialement estimées à plus de 7,5 millions de dollars (bien que les chiffres publics des pertes varient encore).
Ce qui est intéressant, c'est que cette attaque n'impliquait ni la fuite d'une clé privée, ni l'exploitation d'une vulnérabilité classique de contrat intelligent. Au lieu de cela, l'attaquant a déployé à l'avance un grand nombre de faux jetons, de pools de liquidités et de contrats auxiliaires, les présentant comme des chemins de transaction potentiellement arbitrables. Cela a incité le bot, lors de son exécution automatisée, à accorder une Approbation (Approval) ERC-20 à un contrat malveillant, permettant finalement le transfert « légal » des actifs du bot MEV.
Au moment de la publication, Jaredfromsubway.eth avait déjà adressé un message sur la chaîne à l'attaquant, déclarant : « Si 2150 ETH sont restitués dans les 48 heures, nous sommes prêts à payer une prime de chapeau blanc de 50%. Sinon, nous prendrons toutes les mesures juridiques et d'application de la loi possibles pour engager des poursuites. »
Cependant, le fait qu'un bot MEV hautement spécialisé et piloté par du code puisse lui aussi trébucher sur une Approbation nous amène à reconsidérer le niveau de danger caché dans cette action d'« Approval » que nous utilisons quotidiennement.
1. Une chasse à l'homme inversée conçue spécifiquement pour les bots MEV
En analysant sérieusement cet incident, on se rend compte qu'il ne s'agit pas d'une vulnérabilité déclenchée par hasard, mais d'une chasse à l'homme de longue haleine, conçue pour cibler la logique de trading de Jaredfromsubway.eth.
Jaredfromsubway.eth a toujours été l'un des bots d'arbitrage de type "sandwich" les plus connus sur Ethereum. En termes simples, une attaque par sandwich consiste pour le bot, après avoir détecté une transaction sur le point de se produire sur la chaîne, à acheter avant l'utilisateur pour faire monter le prix ; puis, une fois que l'utilisateur a effectué sa transaction à un prix moins favorable, à vendre immédiatement pour réaliser un profit sur la différence.
C'est précisément pourquoi cette stratégie exige que le bot surveille en permanence les transactions sur la chaîne, évalue les opportunités d'arbitrage à une vitesse extrême et organise des chemins de transaction en faisant appel à différents jetons et contrats. Cela signifie également que plus la vitesse est rapide et plus les actifs et protocoles couverts sont nombreux, plus le bot peut capter d'opportunités.
Mais c'est exactement ce point qui est devenu la faille exploitée lors de cet incident.
D'après les analyses post-mortem, l'attaquant n'a pas directement attaqué le contrat de fonds du bot. Au lieu de cela, il a passé plusieurs semaines à construire un environnement de transaction qui semblait pouvoir générer des profits :
- Première étape : déployer un grand nombre de faux jetons et de pools de liquidités. Ces jetons imitaient le nom, l'interface et le comportement transactionnel d'actifs courants comme le WETH, l'USDC, l'USDT, etc., trompant le système de reconnaissance automatique du bot pour qu'il pense avoir découvert un chemin de transaction normal ;
- Deuxième étape : gagner progressivement la confiance du bot. Lors des tests initiaux, les autorisations accordées par le bot étaient utilisées normalement au cours des transactions. Une fois que le système du bot a commencé à exécuter de manière répétée des chemins similaires, l'attaquant a alors ajusté la logique du contrat. Cela a fait que certaines autorisations générées par le bot n'étaient plus réellement consommées et n'étaient pas remises à zéro après la transaction, laissant ces autorisations actives ;
- Enfin, l'attaquant a appelé de manière groupée les limites d'autorisation encore valides pour transférer les vrais WETH, USDC et USDT du contrat du bot.
En clair, toute l'attaque ciblait précisément les caractéristiques opérationnelles des bots MEV : créer d'abord un environnement conforme à leurs règles de décision de profit, puis exploiter leur mécanisme de recherche d'exécution automatique des chemins de transaction pour que le système donne activement le droit d'utiliser les actifs.
Cela explique également pourquoi même un bot MEV hautement spécialisé a pu être piégé.
Il sait calculer les écarts de prix, les coûts en Gas et l'ordre des transactions, mais il ne vérifie pas nécessairement l'identité de chaque nouveau contrat de manière approfondie. Sous cet angle, le problème de l'utilisateur ordinaire est de « cliquer sur confirmer sans comprendre », tandis que le problème du bot automatisé est de « exécuter automatiquement sans confirmation ».
En apparence, les deux sont complètement différents, mais le risque sous-jacent est très similaire, car tous deux considèrent l'autorisation comme une étape ordinaire avant de finaliser une transaction, sans prendre clairement conscience du niveau de risque qu'elle comporte.
2. Pourquoi l'Approval est-il toujours sous-estimé ?
Comme on le sait, dans la norme ERC-20 d'Ethereum et des chaînes compatibles EVM, l'Approve (Autorisation) est une conception assez fondamentale.
Cependant, lorsqu'un utilisateur effectue un transfert direct depuis son portefeuille, il utilise généralement `transfer`, sans impliquer d'Approve. Ce n'est que dans des scénarios impliquant des contrats intelligents comme les DEX, le prêt, le staking ou l'ajout de liquidités, où l'utilisateur a besoin que le contrat intelligent agisse en son nom pour utiliser des jetons, que l'Approval entre en jeu.
Par exemple, lorsque nous voulons échanger des USDT contre de l'ETH sur Uniswap, le contrat intelligent d'Uniswap ne peut pas directement prendre les USDT de votre portefeuille. Il doit d'abord exécuter un Approve pour indiquer au système : « J'autorise Uniswap à prélever X USDT de mon portefeuille. »
Une fois l'autorisation accordée, le contrat ayant obtenu la permission peut, via `transferFrom`, utiliser les USDT de l'utilisateur dans la limite du montant autorisé, et l'échange (Swap) suivant peut alors se terminer avec succès.
Autrement dit, l'Approval en soi n'est pas une vulnérabilité, mais une base essentielle au fonctionnement normal du DeFi. Le problème, c'est qu'il ressemble un peu aux autorisations de prélèvement automatique d'Alipay/WeChat :
L'utilisateur ne donne pas son mot de passe de compte au commerçant, mais autorise le commerçant à effectuer des prélèvements actifs dans une certaine limite. Tant que l'autorisation reste valide, les prélèvements ultérieurs ne nécessitent pas que l'utilisateur saisisse à nouveau son mot de passe ou confirme chaque transaction. Cela pose naturellement quelques problèmes.
Premièrement, il y a le problème de l'autorisation infinie (unlimited approval), où les gens transforment souvent une transaction unique en une permission à long terme. Principalement pour réduire les opérations et les coûts en Gas liés aux autorisations répétées, de nombreuses DApp demandent par défaut un montant d'autorisation très élevé, ce qu'on appelle communément « l'autorisation infinie ».
Un utilisateur qui ne souhaitait initialement utiliser que 100 USDC pour une transaction peut finir par autoriser le contrat à utiliser à l'avenir la totalité des USDC de son adresse. Tant que cette autorisation n'est pas révoquée, même si le portefeuille de l'utilisateur ne contenait à l'origine qu'un petit montant, les USDC réapprovisionnés plus tard pourront continuer à être affectés.
Deuxièmement, l'autorisation n'expire pas par défaut lorsque l'on quitte la DApp. De nombreux utilisateurs confondent « déconnecter le portefeuille » et « révoquer l'autorisation ». En réalité, se déconnecter signifie seulement que la page web ne peut temporairement plus lire ou demander le portefeuille actuel, cela ne modifie pas l'Approval déjà écrit sur la blockchain.
Fermer l'onglet, supprimer la DApp, effacer le cache du navigateur, voire changer d'application de portefeuille ne la rendront pas automatiquement invalide.
Enfin, même un contrat normal peut devenir dangereux à l'avenir. En effet, de nombreux risques liés aux autorisations ne proviennent pas seulement de sites de phishing malveillants dès le départ, comme lors de cette chasse à l'homme. Un utilisateur peut accorder une autorisation à un protocole qui était normal à l'époque, mais dont le contrat est ensuite attaqué, la clé de l'administrateur fuitée, la logique de mise à jour remplacée, ou dont le contrat de routage appelé rencontre un problème.
Pour l'utilisateur, les actifs restent dans son adresse, mais du point de vue des permissions, un autre contrat a toujours la capacité d'utiliser ces actifs. Par conséquent, le risque d'Approval ne se limite pas à « ai-je autorisé une mauvaise personne ? », mais inclut également « l'entité que j'ai autorisée rencontrera-t-elle des problèmes plus tard ? ».
3. Comment gérer le risque d'Approval ?
Face au risque d'Approval, la recommandation la plus simple est « de ne pas accorder d'autorisation infinie ».
Mais dans l'environnement réel d'utilisation du DeFi, refuser complètement les autorisations n'est pas réaliste. Comme mentionné précédemment, l'autorisation en soi n'est pas une vulnérabilité, c'est la manière fondamentale dont les applications sur la chaîne utilisent les actifs.
Ce qui doit vraiment changer, c'est de faire passer l'Approval d'une action de confirmation ponctuelle à un mécanisme de gestion des permissions continu.
Pour les utilisateurs ordinaires, il faut d'abord développer quelques habitudes de base :
- Premièrement, suivre le principe du « privilège minimum ». Lorsque le portefeuille affiche une demande d'autorisation, essayez de définir le montant en fonction des besoins réels de l'interaction actuelle. Par exemple, si vous prévoyez d'utiliser seulement 100 USDT, accordez un montant aussi proche que possible de 100 USDT, plutôt que d'ouvrir directement une autorisation infinie ;
- Deuxièmement, distinguer le portefeuille de stockage et le portefieuille d'interaction. Une adresse utilisée pour stocker à long terme des actifs importants ne doit pas être connectée fréquemment à des DApp inconnues. Pour participer à des airdrops, des Mint, à de nouveaux projets et à des interactions DeFi à haut risque, utilisez une adresse séparée pour limiter les pertes potentielles à une petite échelle ;
- Troisièmement, vérifier régulièrement et révoquer les autorisations qui ne sont plus nécessaires. Les utilisateurs peuvent utiliser des outils comme Revoke.cash, ou dans imToken, aller sur la page du jeton concerné, cliquer sur « Fonction du jeton » en bas à gauche, puis choisir « Gestion des autorisations » pour consulter les entités autorisées, les jetons et les montants pour cette adresse, et initier la révocation des permissions qui ne sont plus utilisées ou dont la provenance est inconnue (lecture complémentaire : « Guide pas à pas pour utiliser Revoke.cash pour la gestion des autorisations ») ;
Bien sûr, après tous ces conseils, face aux attaques par autorisation imprévisibles, compter uniquement sur la vigilance des utilisateurs et des vérifications périodiques ne suffit pas. Après tout, la plupart des utilisateurs ont du mal à distinguer à qui appartient une série d'adresses de contrat, ou à juger si un certain montant d'autorisation est raisonnable.
En tant que première ligne de défense pour les utilisateurs entrant dans le Web3, les portefeuilles doivent fournir une protection active au niveau des capacités produit.
Par exemple, imToken marque ou bloque les jetons, adresses et DApp identifiés comme risqués. Lorsqu'un utilisateur accorde une autorisation sur un jeton à un compte externe ordinaire, ou effectue un transfert direct vers une adresse de contrat, des avertissements de risque spécifiques sont également fournis. Ces avertissements ne peuvent remplacer le jugement de l'utilisateur, mais ils ajoutent au moins un tampon de sécurité nécessaire avant la véritable signature.
De plus, imToken, lors des étapes clés comme la connexion à une DApp, les transferts, les échanges de jetons et les autorisations, analyse de manière structurée et présente de façon lisible le contenu à signer, aidant autant que possible l'utilisateur à comprendre ce qu'il est en train d'accepter avant de confirmer, garantissant que le contenu signé par l'utilisateur doit correspondre à l'action qu'il voit, et non être compressé en une série de données de hachage difficiles à identifier.
Avec la promotion de normes comme l'ERC-7730 (Clear Signing), cette présentation lisible « Ce que vous voyez est ce que vous signez (What You See Is What You Sign) » pourrait progressivement passer d'une capacité produit individuelle du portefeuille à une norme industrielle partagée entre les portefeuilles, les DApp et les contrats intelligents.
Pour résumer, la clé privée détermine qui possède le compte, tandis que l'Approval détermine qui peut encore utiliser les actifs du compte. Ce sont deux choses différentes, mais tout aussi importantes.
Cela signifie également que la sécurité du portefeuille ne peut pas se limiter à « la clé privée a-t-elle fuité ? ». Cela nécessite des efforts conjoints, des utilisateurs aux portefeuilles : Pour les utilisateurs, il faut voir clairement l'entité et le montant avant d'autoriser, et nettoyer les permissions inutiles après l'interaction. Pour les portefeuilles, il faut rendre ces permissions, habituellement cachées dans les contrats, plus visibles, plus compréhensibles et plus faciles à limiter et à révoquer.
Après tout, ce qui est vraiment dangereux n'est pas forcément le transfert qui vient de se produire, mais peut-être une autorisation oubliée depuis longtemps, mais qui n'a jamais expiré.
