Explication des attaques de robots balayeurs EIP-7702
La mise à niveau Pectra d'Ethereum a apporté la révolution de l'EIP-7702, mais elle a également doté les pirates informatiques de l'arme ultime : des robots balayeurs financés par des sponsors qui drainent les portefeuilles compromis sans avoir besoin de gaz natif.
Attaques de robots balayeurs EIP-7702 : dans quelle mesure Portefeuilles Vidangez-vous lorsque le gaz arrive instantanément
- L’arrivée du hard fork Pectra d’Ethereum représente l’un des tournants les plus critiques de l’histoire de l’architecture de compte décentralisée. Au centre de cette avancée programmatique se trouve EIP-7702, une proposition conçue pour résoudre les frictions de longue date entre les comptes externes (EOA), les portefeuilles standard contrôlés par clé privée utilisés par la grande majorité des utilisateurs de détail, et Contrat intelligent Comptes (CA).
- En permettant à un EOA standard d'adopter temporairement ou de manière persistante les comportements de un contrat intelligent portefeuille, EIP-7702 apporte des utilitaires avancés, tels que le traitement par lots de transactions, le parrainage de gaz et une logique de récupération personnalisée, directement au paysage de portefeuille existant.
- Pourtant, dans l’écosystème conflictuel des blockchains publiques, chaque avancée technologique élargit inévitablement le terrain de jeu des acteurs malveillants. Alors que les développeurs Web3 célèbrent la démocratisation de l’abstraction des comptes, les cercles de sécurité black-hat se sont tranquillement adaptés. L'intégration de l'EIP-7702 a doté les fraudeurs d'un outil très dangereux : le robot balayeur financé par le sponsor.
- Historiquement, un portefeuille dont les clés privées ont été divulguées avait une chance de récupération s'il ne contenait aucun jeton de gaz natif (tel que l'ETH). Les équipes de sécurité pourraient coordonner le sauvetage des transactions privées avant qu’un script de surveillance automatisé d’un pirate informatique ne puisse accélérer le dépôt des frais d’essence. Dans le cadre de l'EIP-7702, l'ensemble de ce cadre défensif a été complètement démantelé.
1. La genèse : combler le fossé entre les comptes EOA et Smart
- Pour comprendre pourquoi l'EIP-7702 représente un changement si massif dans la mécanique des robots balayeurs, nous devons d'abord retracer le pipeline évolutif de l'abstraction des comptes. Depuis des années, la communauté Ethereum est aux prises avec les limites des EOA standards. Un EOA est une entité monolithique : elle s’appuie strictement sur une paire de clés ECDSA (Elliptic Curve Digital Signature Algorithm) pour autoriser les transactions. Cette architecture introduit des frictions importantes, en particulier le problème de l'amorçage du gaz, la fragilité de la signature unique et l'absence de regroupement atomique.
- Un tout nouvel EOA ne peut exécuter aucune action en chaîne tant qu'il n'a pas été financé avec des jetons de gaz natifs, ce qui crée un sérieux obstacle à l'intégration. De plus, si la clé privée d'un EOA est perdue ou volée, le compte est définitivement compromis ; il n'existe pas de mécanisme de récupération natif ni d'option multisig sans déplacer les fonds vers un contrat distinct. De plus, exécuter un échange décentralisé de base (DéFi) le swap nécessite deux transactions distinctes et séquentielles : une transaction d'approbation initiale ERC-20 suivie de l'exécution réelle du swap. Cela coûte plus d’essence et dégrade l’expérience utilisateur.
La route vers l'abstraction des comptes
- La première tentative structurelle majeure pour remédier à ces limitations a été l'ERC-4337. Cette norme a introduit un pool de transactions hors chaîne complètement distinct dans lequel les utilisateurs peuvent soumettre leurs opérations à des regroupeurs décentralisés. Ces bundlers regrouperaient plusieurs opérations dans une seule transaction Ethereum standard, les acheminant via un contrat EntryPoint central pour exécuter la logique du portefeuille de contrats intelligents.
- Bien que l'ERC-4337 ait réussi à prouver la viabilité de l'abstraction des comptes, il souffrait de deux limitations clés : il obligeait les utilisateurs à migrer entièrement leurs actifs de leurs EOA existants vers de tout nouveaux comptes de contrats intelligents, et il introduisait des coûts de gaz plus élevés en raison des couches complexes d'exécution des contrats intelligents.
- Pour contourner l'obstacle de la migration, les développeurs ont proposé EIP-3074. Cette proposition a introduit deux nouveaux opcodes EVM qui permettaient à un EOA de déléguer son autorité à un contrat d'invocateur externe, permettant à l'invocateur d'effectuer des transactions au nom de l'EOA. Cependant, les auditeurs de sécurité ont rapidement signalé de graves vulnérabilités : un seul contrat d'invocateur compromis ou malveillant pourrait obtenir un contrôle illimité et permanent sur tout EOA qui l'autorisait, ouvrant ainsi un vecteur dévastateur aux attaques de phishing.
Le compromis ultime
- En réponse à ces problèmes de sécurité, Vitalik Buterin a formulé l'EIP-7702. Plutôt que d'introduire des opcodes de délégation bruts de bas niveau, EIP-7702 introduit un type de transaction spécialisé qui permet à un EOA de définir temporairement ou de manière persistante son propre emplacement de code pour pointer vers un contrat externe. Lorsqu'une transaction EIP-7702 est exécutée, l'EOA spécifie une liste d'autorisations.
- Pour chaque entrée de cette liste, l'EVM écrit temporairement un préfixe de désignation de délégation directement dans l'emplacement de code de l'EOA. Cette désignation indique à l'EVM d'acheminer tous les appels de contrat ultérieurs ciblant cet EOA directement vers la logique de mise en œuvre du contrat délégué spécifié. Ce mécanisme permet aux EOA standard d'hériter instantanément de toutes les capacités des comptes intelligents (y compris le parrainage de gaz, les contrôles multi-signatures et le traitement par lots de transactions) tout en conservant une compatibilité ascendante totale et en laissant une voie claire pour annuler la délégation en pointant le compte vers l'adresse nulle.
2. L'ancien paradigme : comment fonctionnaient les robots balayeurs classiques
- Pour apprécier pleinement la façon dont EIP-7702 a optimisé l'efficacité des robots balayeurs malveillants, nous devons analyser les limites structurelles du paysage des robots balayeurs pré-Pectra. Historiquement, lorsque la clé privée ou la phrase de départ de récupération d'un utilisateur était compromise, l'attaquant déployait immédiatement un robot balayeur : un script automatisé s'exécutant sur un nœud RPC à haute vitesse qui analysait en permanence la mémoire publique à la recherche de toute transaction entrante ciblant l'adresse du portefeuille compromise.
- Le robot balayeur classique fonctionnait sous une contrainte rigide : chaque transaction changeant d'état sur le réseau Ethereum nécessite l'exécution de gaz natif. Si le portefeuille compromis contenait des jetons ERC-20 de grande valeur ou des NFT de valeur, mais ne contenait aucun gaz natif, le robot balayeur de l’attaquant était temporairement paralysé. Le robot n'a pas pu déplacer les jetons car il n'y avait pas de gaz à l'intérieur du portefeuille compromis pour payer les validateurs pour la transaction de transfert.
Par conséquent, le robot balayeur a dû attendre que la victime ou une équipe de secours au chapeau blanc dépose de l'ETH natif dans le portefeuille compromis pour faciliter une récupération, ou que la victime tente d'exécuter une transaction directement.
- Au moment où le robot balayeur a détecté une transaction en attente déposant des ETH à l'adresse compromise, il a calculé les frais de gaz exacts requis pour lancer toute transaction de sauvetage ultérieure. En utilisant les enchères prioritaires de gaz ou en acheminant les transactions directement vers les constructeurs de blocs publics, le robot balayeur soumettrait instantanément une transaction de transfert avec un prix du gaz extrêmement élevé. La transaction du robot serait regroupée tout en haut du bloc suivant, balayant avec succès les actifs de la victime et laissant la transaction de sauvetage entrante échouer en raison du manque de jetons restants.
La trappe d'évacuation White-Hat : Flashbots et MEV-Share
- Ce besoin en gaz a créé une niche hautement spécialisée pour les opérations de sauvetage en chapeau blanc. Lorsqu'un utilisateur se rendait compte que la clé de son portefeuille avait été divulguée, il pouvait contacter des experts en sécurité pour coordonner un sauvetage Flashbots. Étant donné que les pools de mémoire publics sont fortement surveillés par des robots pirates, les sauveteurs ont utilisé des points de terminaison RPC privés pour contourner complètement le pool de mémoire public.
- À l'aide d'outils comme Flashbots ou MEV-Share, les sauveteurs construiraient un ensemble de transactions atomiques contenant deux étapes distinctes. Premièrement, un portefeuille externe sécurisé appartenant à l’équipe de secours enverrait la quantité exacte d’ETH nécessaire au gaz au portefeuille compromis. Deuxièmement, le portefeuille compromis transférerait immédiatement ses précieux jetons ERC-20 ou NFT vers une adresse de destination sécurisée, en utilisant l'ETH nouvellement déposé pour couvrir le gaz.
- Étant donné que ces deux transactions étaient regroupées et envoyées directement aux constructeurs de blocs coopératifs, elles étaient garanties d'être exécutées exactement dans le même bloc, l'une après l'autre, sans aucun espace pour qu'un robot balayeur externe puisse intervenir. Le public n’a jamais vu le gisement de gaz entrant jusqu’à ce que le bloc soit déjà exploité et finalisé, sauvant avec succès des millions de dollars en richesse numérique.
3. Sweeper Bot : déballage de l'exploit de parrainage
- L'intégration d'EIP-7702 a complètement démantelé les garanties de sécurité du pack de sauvetage Flashbots classique en introduisant le parrainage de gaz. Sous EIP-7702, une transaction peut être soumise par un tiers (appelé relais ou sponsor) qui paie les frais de gaz au nom de l'EOA cible. Cette seule modification a éliminé le plus grand goulot d'étranglement du robot balayeur classique : la nécessité pour le portefeuille de la victime de contenir du gaz natif.
- Lorsqu'un attaquant accède à une clé privée compromise dans l'ère post-Pectra, il n'a plus besoin de déployer un script passif qui attend un dépôt ETH entrant. Au lieu de cela, l’attaquant peut configurer son robot balayeur pour qu’il agisse en tant que son propre sponsor de gaz. Le robot construit une transaction EIP-7702 contenant une charge utile d'autorisation signée par l'EOA compromis. Cette charge utile met temporairement à niveau l'EOA de la victime vers un portefeuille de contrat intelligent contenant une routine de transfert par lots.
- L'attaquant diffuse ensuite cette transaction depuis son propre portefeuille externe entièrement financé. Étant donné que le portefeuille de l'attaquant est l'origine de la transaction, les frais de gaz sont déduits directement du solde de l'attaquant. L'EVM traite la transaction, installe temporairement la logique de transfert personnalisée sur l'EOA de la victime et exécute instantanément un transfert par lots de tous les jetons ERC-20 et NFT vers l'adresse sécurisée de l'attaquant : le tout en une seule étape atomique et payée par le sponsor. Le portefeuille de la victime est complètement vidé sans jamais contenir une seule goutte d’ETH natif.
Les deux vecteurs d'attaque majeurs
Cette nouvelle classe d'attaques de robots balayeurs opère via deux vecteurs d'entrée distincts :
La clé privée compromise : Si un pirate informatique vole une phrase de départ ou une clé privée via une fuite de fichier de configuration, une sauvegarde cloud compromise ou un logiciel malveillant du presse-papiers, il détient l'autorité ultime pour signer toute charge utile. Au lieu d'attendre le gaz, le robot balayeur de l'attaquant signe immédiatement une charge utile d'autorisation EIP-7702 au nom de la victime. Le robot soumet ensuite la transaction, paie l'essence et nettoie le compte instantanément. Les équipes de secours en chapeau blanc ne peuvent pas effectuer un sauvetage Flashbots classique car il n'y a aucune étape de financement à regrouper ; l'attaquant peut lancer le balayage à tout moment de son choix, totalement indépendamment des actions de la victime.
La signature de la délégation de phishing : Le deuxième vecteur, encore plus insidieux, ne nécessite pas que l'attaquant vole la clé privée de la victime. Au lieu de cela, il s’appuie sur des interfaces de phishing trompeuses. Lorsqu'un utilisateur visite un site Web malveillant (déguisé en réclamation de largage ou en tableau de bord d'optimisation de portefeuille), la dApp l'invite à signer un message hors chaîne. Pour un œil non averti, cela ressemble à une signature standard et inoffensive. En réalité, l'utilisateur signe un tuple d'autorisation EIP-7702.
- Une fois cette signature captée, la délégation est terminée. L'attaquant possède désormais une charge utile cryptographiquement valide qui lui permet de mettre à niveau l'EOA de la victime pour pointer à tout moment vers un contrat de mise en œuvre malveillant. Étant donné que les transactions EIP-7702 peuvent être soumises par n'importe qui, l'attaquant peut conserver cette signature en réserve, attendant des semaines ou des mois jusqu'à ce que la victime dépose une quantité importante d'actifs dans son portefeuille.
- Dès l'instant où un actif de grande valeur arrive, le robot balayeur de l'attaquant soumet la liste d'autorisations au réseau, met à niveau l'EOA et draine les actifs en utilisant son propre gaz sponsorisé.
Tableau 1 : Modèles de balayeuses
| Système | Besoin en gaz |
| Vieille balayeuse | Nécessite l'ETH de la victime |
| Nouvelle balayeuse | Utilise du gaz attaquant |
4. Modifications du flux d'exécution et de l'état au niveau EVM
- To understand how EIP-7702 alters the core behavior of the Ethereum Virtual Machine, we must look at the exact state-changing rules introduced by this transaction type. EIP-7702 introduit un nouveau type de transaction, formellement désigné par un emballage d'enveloppe spécialisé. La charge utile d'une transaction EIP-7702 comprend une structure de transaction standard ainsi qu'un ajout critique : la liste d'autorisations.
- La liste d'autorisation est représentée comme une liste de tuples sérialisés contenant des paramètres tels que l'identifiant de chaîne, l'adresse du contrat intelligent cible, le nom occasionnel du compte et les composants de signature (parité y, r et s) générés par la clé privée de l'EOA.
- L'identifiant de chaîne précise le réseau exact pour éviter chaîne croisée rejouer les attaques. L'adresse indique l'implémentation cible du contrat intelligent à laquelle le signataire souhaite déléguer son compte. Le nom occasionnel suit le nombre de transactions actuel de l'EOA du signataire pour empêcher la réutilisation de la signature ou une exécution dans le désordre. Enfin, les composants de signature sont générés en signant le hachage des données d'autorisation.
Le processus de transition de l'État
Lorsqu'une transaction EIP-7702 est regroupée dans un bloc, l'EVM traite la liste d'autorisations avant d'exécuter les charges utiles de transaction. Pour chaque tuple valide de la liste, l'EVM effectue plusieurs opérations :
Récupération de signature : L'EVM utilise l'algorithme standard de récupération de signature pour dériver la clé publique et identifier l'adresse de l'autorité de signature.
Vérification occasionnelle : L'EVM vérifie que le nom occasionnel en chaîne du signataire correspond au nom occasionnel spécifié dans le tuple. Si le nombre occasionnel sur la chaîne est supérieur, l'autorisation est rejetée comme non valide.
Rédaction du désignateur de délégation : Si la vérification réussit, l'EVM modifie l'état du compte d'autorité. Il écrit les octets de désignation de délégation directement dans l'emplacement de code du compte. Ce préfixe spécial indique à l'EVM que le compte n'est plus un EOA standard à des fins d'exécution. Tous les futurs appels externes ciblant l’adresse de l’autorité redirigeront immédiatement leur contexte d’exécution vers le code résidant à l’adresse déléguée.
Incrémentation du nom occasionnel : The on-chain nonce of the authority account is incremented by one to prevent the exact same authorization payload from being executed again.
5. La destruction de la compatibilité ascendante : l'erreur de l'EOA uniquement
- Au-delà de la menace immédiate des robots balayeurs sponsorisés, EIP-7702 introduit un risque systémique dans l'écosystème plus large des contrats intelligents en brisant une hypothèse fondamentale de la sécurité d'Ethereum : la vérification uniquement EOA. Depuis près d’une décennie, les développeurs de contrats intelligents utilisent un contrôle de sécurité spécifique et commun pour vérifier si un appel entrant provient d’un utilisateur standard ou d’un autre contrat intelligent.
- Historiquement, ce contrôle était considéré comme une garantie fiable. Étant donné que les transactions Ethereum standard ne pouvaient être initiées que par un EOA, la vérification que l'appelant immédiat correspondait à l'initiateur d'origine de la transaction garantissait que l'appelant n'était pas un contrat intelligent.
- Cette hypothèse a été largement utilisée pour se défendre contre plusieurs vulnérabilités critiques, telles que les exploits de prêt flash (empêchant les contrats intelligents d'interagir avec les fonctions d'un protocole au cours d'un seul bloc de transaction pour neutraliser les attaques de collecte de capitaux) et les attaques de réentrance (garantissant que le compte appelant ne puisse pas exécuter de fonctions de secours malveillantes pour détourner les boucles d'exécution).
La subversion EIP-7702
- EIP-7702 invalide complètement cette vérification. Étant donné qu'un EOA peut désormais déléguer son emplacement de code pour pointer vers un contrat externe, un EOA peut se comporter exactement comme un contrat intelligent tout en restant l'initiateur de la transaction. Lorsqu'un EOA délégué interagit avec un protocole, l'appelant et l'origine de la transaction correspondent toujours, mais l'emplacement de code de l'EOA contient un bytecode actif et exécutable qui peut exécuter une logique personnalisée et malveillante.
- Un exemple concret important de cette vulnérabilité s'est produit sur la chaîne BNB. Un attaquant a identifié un contrat DeFi non vérifié qui s'appuyait uniquement sur la vérification EOA pour restreindre l'accès à son pool de liquidité interne. L'attaquant a déployé un contrat de délégation malveillant, signé une charge utile d'autorisation EIP-7702 sur son propre EOA et initié une transaction.
- Étant donné que l'EOA transportait un code délégué, il a réussi à contourner la vérification EOA uniquement du contrat. Lorsque le protocole transférait les jetons natifs à l'EOA, il déclenchait instantanément la fonction de secours du contrat délégué, permettant à l'attaquant d'exécuter un exploit de réentrée récursive et de drainer le protocole.
Tableau 2 : Techniques de récupération
| Méthode | Mécanisme |
| Ancien sauvetage | Bundles de mémoire privée |
| Nouveau sauvetage | Réinitialisation de l'adresse zéro |
6. Opérations défensives : écrasement et purge des délégations malveillantes
- Si vous découvrez que votre portefeuille a été compromis via une signature de délégation EIP-7702 malveillante, les mesures de sécurité traditionnelles telles que la révocation des autorisations de jetons ERC-20 ne suffisent plus. Étant donné que le pointeur de délégation donne à l'attaquant un contrôle permanent de l'exécution de votre EOA, vous devez activement effacer la délégation pour récupérer la sécurité de votre compte.
Heureusement, les architectes de l'EIP-7702 ont construit un mécanisme natif pour réinitialiser l'emplacement de code d'un EOA : la délégation à l'adresse zéro.
- Lorsqu'un EOA autorise une délégation pointant vers l'adresse zéro, l'EVM l'intercepte comme une commande spéciale. Plutôt que d'écrire un préfixe de délégation, l'EVM efface complètement l'emplacement de code du compte et réinitialise son hachage de code à l'état vide par défaut. Cette action restaure instantanément le portefeuille à un EOA propre et standard, rompant ainsi le contrôle d'exécution de l'attaquant.
Le manuel de récupération : exécuter une purge sponsorisée
Étant donné qu'un portefeuille compromis est probablement surveillé par un robot balayeur actif, tenter de financer le portefeuille avec ETH pour effacer la délégation est extrêmement risqué. Pour récupérer le compte en toute sécurité, vous devez exécuter une purge financée par le sponsor en utilisant une adresse secondaire sécurisée pour payer les frais d'essence.
Étape 1 : Isolez l'EOA compromis. Arrêtez de déposer des actifs ou d'exécuter des transactions à partir du portefeuille compromis. Assurez-vous de disposer d'un portefeuille secondaire sécurisé (avec suffisamment d'ETH pour payer l'essence) pour agir en tant que sponsor ou relais.
Étape 2 : générez la charge utile de réinitialisation. Rédigez une charge utile d'autorisation EIP-7702 où le champ d'adresse cible est défini sur l'adresse zéro. La charge utile doit faire référence au nonce actuel sur la chaîne de l'EOA compromis. Signez cette charge utile à l’aide de la clé privée de l’EOA compromis.
Étape 3 : Diffusion via le portefeuille du sponsor. À l'aide d'un outil de développement en ligne de commande ou d'un framework de développement vérifié, regroupez la charge utile d'autorisation signée dans une transaction EIP-7702. Configurez les paramètres de transaction pour déduire les frais de gaz directement de votre portefeuille sécurisé de sponsor secondaire. Diffusez la transaction sur le réseau.
Étape 4 : Vérifiez la réinitialisation de l'état. Une fois la transaction extraite, l'EVM incrémentera le nonce de l'EOA compromis et effacera complètement le pointeur de délégation de son emplacement de code. Vous pouvez vérifier la réinitialisation en exécutant une vérification du solde et du code sur l'adresse à l'aide d'un outil de ligne de commande de développement.
7. Télémétrie en temps réel et sécurité en chaîne via DEXTools
- Dans l'écosystème post-Pectra très fragmenté, où les cumuls modulaires, les jetons de gaz personnalisés et les comptes de contrats intelligents délégués se développent rapidement, maintenir une visibilité absolue sur vos actifs est une nécessité. Lorsque les utilisateurs interagissent avec de nouveaux protocoles DeFi, des pools de rendement ou des cadres de restauration de liquides, il leur est régulièrement demandé de signer des transactions qui pourraient, si elles étaient malveillantes, contenir des charges utiles d'autorisation EIP-7702 cachées.
- Pour protéger votre portefeuille de ces tactiques de phishing avancées, vous devez pratiquer une vérification proactive en chaîne. Se fier aux alertes de base du navigateur n’est plus suffisant ; vous avez besoin de données en temps réel pour auditer la sécurité des pools et des contrats intelligents avec lesquels vous interagissez.
- DEXTools fournit l'infrastructure analytique critique nécessaire pour effectuer ces vérifications avant d'autoriser toute signature sur votre portefeuille. En saisissant l'adresse contractuelle de n'importe quel token directement dans le formulaire avancé Explorateur de paires DEXTools, vous pouvez surveiller instantanément l'historique des transactions en direct, analyser l'état de vérification du code source du contrat, vérifier les verrous du pool de liquidité et auditer les scores de confiance de sécurité globaux.
- Cette télémétrie transparente garantit que vous n'interagissez qu'avec des protocoles vérifiés et de haute intégrité, protégeant ainsi vos actifs numériques des pièges précalculés des réseaux draineurs modernes.
Vous pouvez accéder à DEXTools ici et commencez à trader dès aujourd'hui !
Avertissement : Cet article est à titre informatif uniquement et ne constitue pas un conseil en investissement, un conseil financier, un conseil commercial ou tout autre type de conseil. DEXTools ne recommande pas d'acheter, de vendre ou de détenir une crypto-monnaie ou un jeton. Les utilisateurs doivent effectuer leurs propres recherches et consulter un conseiller financier qualifié avant de prendre toute décision d'investissement. Les investissements en crypto-monnaie sont volatils et à haut risque. DEXTools n'est pas responsable des pertes subies.