L'EIP-7702 confère aux adresses des capacités et de la flexibilité similaires à celles des contrats intelligents, de plus en plus d'applications 7702 continuent d'être créées, ce qui est crucial pour permettre à un plus grand nombre de personnes d'entrer dans le Web3 et d'améliorer l'expérience utilisateur.
Cependant, la flexibilité de 7702 et la situation actuelle où la plupart des utilisateurs ne sont pas encore familiers avec 7702 sont exploitées par des groupes de fraude. Récemment, nous avons observé que des utilisateurs, en raison de la capacité d'exécution de masse de Metamask 7702, ont été victimes de groupes de phishing comme #InfernoDrainer, qui ont combiné des interactions nécessitant normalement plusieurs autorisations en une seule transaction, entraînant le vol d'actifs.
Remarque : MetaMask lui-même n'a pas de problème de sécurité. MetaMask place la sécurité des utilisateurs au premier plan tout en fournissant des capacités relatives à 7702 et a mis en œuvre de nombreuses mesures de sécurité. Les utilisateurs doivent en savoir plus sur les capacités et les risques associés à 7702 pour éviter que ce type d'incident de sécurité ne se reproduise.
Un, principe de signature d'autorisation et conception de sécurité du 7702 Delegator de Metamask
1. Analyse technique
L'utilisateur autorise le contrat Delegator déjà déployé, pointant le champ de code du compte utilisateur vers ce contrat. L'adresse actuelle du contrat Delegator officiel de MetaMask : 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Structure d'autorisation : (chainId, delegatorAddress, nonce, signature) écrite dans authorization_list
Méthode de signature : MetaMask utilise une logique de signature unifiée pour les transactions d'autorisation liées à l'EIP-7702, c'est-à-dire la méthode signEIP7702Authorization, signant les données d'autorisation digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) avec ECDSA pour générer une structure de signature (v, r, s) qui est jointe à la transaction de type 4 suivante, permettant l'autorisation et la mise à niveau du compte. Pour plus de détails, voir : https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Méthode de vérification : la couche de consensus vérifie en utilisant ecrecover(digest7702, sig) == tx.from.
Conception de sécurité : l'interface web ne peut pas induire les utilisateurs à autoriser n'importe quel Delegator, car la méthode signEIP7702Authorization est uniquement implémentée à l'intérieur du portefeuille MetaMask, sans appel ouvert via window.ethereum à l'interface web. Les méthodes de signature accessibles par le web, telles que eth_signTypedData_v4, ne sont pas applicables aux signatures d'autorisation EIP-7702, dont le format de résumé est comme suit :
Tandis que le format de signature requis par la norme EIP-7702 est :
En raison de ce que eth_signTypedData_v4 inclut systématiquement le préfixe 0x1901 et que le processus de calcul du résumé est totalement différent de celui de 7702, il est pratiquement impossible d'obtenir digest712 == digest7702, même en construisant habilement le domainSeparator, le primaryType et le message.
Par conséquent, l'interface web ne peut pas falsifier une signature d'autorisation 7702 légitime par cette méthode. De plus, MetaMask applique un mécanisme de liste blanche pour les adresses des Delegators, n'autorisant par défaut que l'autorisation du Delegator officiel (0x63c0...32B) et interdisant aux DApps d'injecter des adresses, afin d'empêcher davantage les utilisateurs d'être induits en erreur pour signer des données d'autorisation malveillantes des Delegators. L'EIP-7702 confère aux adresses des capacités et de la flexibilité similaires à celles des contrats intelligents, de plus en plus d'applications 7702 continuent d'être créées, ce qui est crucial pour permettre à un plus grand nombre de personnes d'entrer dans le Web3 et d'améliorer l'expérience utilisateur.
Cependant, la flexibilité de 7702 et la situation actuelle où la plupart des utilisateurs ne sont pas encore familiers avec 7702 sont exploitées par des groupes de fraude. Récemment, nous avons observé que des utilisateurs, en raison de la capacité d'exécution de masse de Metamask 7702, ont été victimes de groupes de phishing comme #InfernoDrainer, qui ont combiné des interactions nécessitant normalement plusieurs autorisations en une seule transaction, entraînant le vol d'actifs.
Remarque : MetaMask lui-même n'a pas de problème de sécurité. MetaMask place la sécurité des utilisateurs au premier plan tout en fournissant des capacités relatives à 7702 et a mis en œuvre de nombreuses mesures de sécurité. Les utilisateurs doivent en savoir plus sur les capacités et les risques associés à 7702 pour éviter que ce type d'incident de sécurité ne se reproduise.
Un, principe de signature d'autorisation et conception de sécurité du 7702 Delegator de Metamask
1. Analyse technique
L'utilisateur autorise le contrat Delegator déjà déployé, pointant le champ de code du compte utilisateur vers ce contrat. L'adresse actuelle du contrat Delegator officiel de MetaMask : 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Structure d'autorisation : (chainId, delegatorAddress, nonce, signature) écrite dans authorization_list
Méthode de signature : MetaMask utilise une logique de signature unifiée pour les transactions d'autorisation liées à l'EIP-7702, c'est-à-dire la méthode signEIP7702Authorization, signant les données d'autorisation digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) avec ECDSA pour générer une structure de signature (v, r, s) qui est jointe à la transaction de type 4 suivante, permettant l'autorisation et la mise à niveau du compte. Pour plus de détails, voir : https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Méthode de vérification : la couche de consensus vérifie en utilisant ecrecover(digest7702, sig) == tx.from.
Conception de sécurité : l'interface web ne peut pas induire les utilisateurs à autoriser n'importe quel Delegator, car la méthode signEIP7702Authorization est uniquement implémentée à l'intérieur du portefeuille MetaMask, sans appel ouvert via window.ethereum à l'interface web. Les méthodes de signature accessibles par le web, telles que eth_signTypedData_v4, ne sont pas applicables aux signatures d'autorisation EIP-7702, dont le format de résumé est comme suit :
Tandis que le format de signature requis par la norme EIP-7702 est :
En raison de ce que eth_signTypedData_v4 inclut systématiquement le préfixe 0x1901 et que le processus de calcul du résumé est totalement différent de celui de 7702, il est pratiquement impossible d'obtenir digest712 == digest7702, même en construisant habilement le domainSeparator, le primaryType et le message.
Par conséquent, l'interface web ne peut pas falsifier une signature d'autorisation 7702 légitime par cette méthode. De plus, MetaMask applique un mécanisme de liste blanche pour les adresses des Delegators, n'autorisant par défaut que l'autorisation du Delegator officiel (0x63c0...32B) et interdisant aux DApps d'injecter des adresses, afin d'empêcher davantage les utilisateurs d'être induits en erreur pour signer des données d'autorisation malveillantes des Delegators.
2. Méthode d'utilisation
Actuellement dans Metamask, la méthode de mise à niveau des EOA existants en comptes intelligents 7702 (Smart Account) se divise principalement en deux catégories : mise à niveau active et mise à niveau passive.
La mise à niveau active signifie que l'utilisateur clique activement sur le bouton « Changer » dans l'interface de son portefeuille, autorisant un contrat Delegator spécifique.
La mise à niveau passive se produit lorsque l'utilisateur interagit avec certains DApps prenant en charge 7702. MetaMask détecte l'opération concernée et affiche automatiquement une invite, suggérant à l'utilisateur de procéder à la mise à niveau.
2.1 Mise à niveau active :
Contenu de la transaction : comprend uniquement l'action de mise à niveau du compte, c'est-à-dire l'autorisation d'un contrat Delegator spécifique.
Processus de mise à niveau : accédez à l'interface de détails du compte dans le portefeuille, cliquez sur le bouton de changement dans l'image ci-dessous pour mettre à niveau l'utilisateur sur Ethereum Mainnet en un compte intelligent. Après avoir cliqué sur changer, une fenêtre s'ouvre pour que l'utilisateur signe la transaction de mise à niveau actuelle :
Enregistrements d'autorisation : après confirmation, attendez que la transaction soit ajoutée à la chaîne. Un ajout réussi signifie que l'utilisateur a réussi à mettre à niveau vers un compte intelligent, et il peut consulter les informations spécifiques sur les transactions d'autorisation sur la page d'adresse actuelle dans etherscan sous **Autorisations (EIP-7702)**.
2. Méthode d'utilisation
Actuellement dans Metamask, la méthode de mise à niveau des EOA existants en comptes intelligents 7702 (Smart Account) se divise principalement en deux catégories : mise à niveau active et mise à niveau passive.
La mise à niveau active signifie que l'utilisateur clique activement sur le bouton « Changer » dans l'interface de son portefeuille, autorisant un contrat Delegator spécifique.
La mise à niveau passive se produit lorsque l'utilisateur interagit avec certains DApps prenant en charge 7702. MetaMask détecte l'opération concernée et affiche automatiquement une invite, suggérant à l'utilisateur de procéder à la mise à niveau.
2.1 Mise à niveau active :
Contenu de la transaction : comprend uniquement l'action de mise à niveau du compte, c'est-à-dire l'autorisation d'un contrat Delegator spécifique.
Processus de mise à niveau : accédez à l'interface de détails du compte dans le portefeuille, cliquez sur le bouton de changement dans l'image ci-dessous pour mettre à niveau l'utilisateur sur Ethereum Mainnet en un compte intelligent. Après avoir cliqué sur changer, une fenêtre s'ouvre pour que l'utilisateur signe la transaction de mise à niveau actuelle :
Enregistrements d'autorisation : après confirmation, attendez que la transaction soit ajoutée à la chaîne. Une réussite signifie que l'utilisateur a réussi à mettre à niveau vers un compte intelligent, et il peut consulter les informations spécifiques sur les transactions d'autorisation sur la page d'adresse actuelle dans etherscan sous **Autorisations (EIP-7702)**.
2.2 Mise à niveau passive
Contenu de la transaction : comprend l'action de mise à niveau du compte ainsi que les actions de masse interagissant avec le contrat sur la chaîne.
Processus de mise à niveau : lorsque l'utilisateur interagit avec certains DApps sur la chaîne, Metamask invite activement l'utilisateur à terminer la transaction actuelle par le biais d'une mise à niveau vers un compte intelligent en utilisant l'envoi de masse. Par exemple, lors de l'échange de certains tokens sur Uniswap, cliquez sur le bouton Utiliser un compte intelligent pour mettre à niveau vers un compte intelligent, après quoi l'autorisation de token et l'échange seront effectués en une seule transaction.
2.3 Retour à l'EOA normal
Que ce soit par mise à niveau active ou passive, l'adresse du contrat Delegator lié sera stockée de manière permanente sur la chaîne, représentant la logique d'exécution actuelle du compte.
Si l'utilisateur souhaite restaurer le compte en un EOA normal, il doit initier manuellement une opération de « retour à l'EOA ». L'essence de cette opération est : par le biais d'une autorisation EIP-7702, soumettre address(0) comme nouvelle adresse du contrat Delegator. Lorsque cette transaction est réussie sur la chaîne, le champ de code du compte sera vidé, la logique d'exécution reviendra au code vide par défaut, et le compte redeviendra un EOA normal.
Accédez à l'interface de détails du compte dans le portefeuille, cliquez sur le bouton de changement pour revenir à un compte EOA normal sur Ethereum Mainnet.
Après avoir cliqué sur confirmer, attendez que la transaction soit ajoutée à la chaîne. Un ajout réussi signifie que l'utilisateur est passé d'un compte intelligent à un compte EOA normal. Les informations spécifiques sur la transaction peuvent également être trouvées sur la page de l'adresse actuelle dans etherscan.
Deux, exemples d'attaques de phishing 7702
Le 24 mai, le groupe de phishing #InfernoDrainer a utilisé la fonctionnalité d'exécution de masse du contrat 7702-Delegator de Metamask pour tromper massivement l'utilisateur (0xc6D2…06DC) en autorisations de tokens, et a mené une attaque de phishing, avec une perte de plus de 146 000 dollars en $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Adresse frauduleuse
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Exemple de transaction de phishing
https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba
Raison du phishing
L'utilisateur (0xc6D2…06DC) a exécuté une transaction d'autorisation de masse malveillante :
Hash de transaction Ethereum : 0x1ddc8cecbc... | Etherscan
Appel 0xe9ae5c53 Méthode par 0xc6D289d5...0d2E606DC sur 0xc6D289d5...0d2E606DC | Succès | 23 mai 2025 14:31:35 (UTC)
etherscan.io
#InfernoDrainer et #PinkDrainer expérimentent des chaînes de phishing plus discrètes et plus impactantes utilisant 7702.
Selon notre recherche, les groupes de phishing #InfernoDrainer et #PinkDrainer explorent et expérimentent actuellement des chaînes de phishing plus discrètes et plus impactantes utilisant 7702. Les adresses concernées sont les suivantes, et nous publierons également un rapport plus détaillé par la suite :
Inferno Drainer：
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer：
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Trois, conseils de sécurité
Fournisseur de portefeuille :
Se référer à la mise en œuvre et à la gestion de la sécurité de MetaMask pour le 7702 Delegator, interdisant aux utilisateurs d'autoriser n'importe quel Delegator et ne permettant que les opérations dans l'application. Rappeler aux utilisateurs que toute opération permettant à l'utilisateur de signer une autorisation via le web est une attaque de phishing.
Vérifiez si la chaîne correspond au réseau actuel et avertissez les utilisateurs des risques de relecture lors de la signature avec un chainID égal à 0.
Lors de la signature d'autorisation par l'utilisateur, affichez le contrat cible, et lors de l'exécution de masse par le biais d'un Delegator, affichez le contenu spécifique de l'appel de fonction, réduisant ainsi les risques d'attaques de phishing sur le réseau.
Utilisateur :
La protection des clés privées est toujours la plus importante. Pas vos clés, pas vos pièces.
Ne jamais autoriser un Delegator sur la base d'une page web indépendante, les autorisations sécurisées sont généralement effectuées dans l'application, comme dans MetaMask.
Lors de l'utilisation de tout portefeuille pour signer, veuillez examiner attentivement le contenu de la signature pour éviter toute signature aveugle ou erronée. Après avoir cliqué sur confirmer, attendez que la transaction soit ajoutée à la chaîne. Un ajout réussi signifie que l'utilisateur est passé d'un compte intelligent à un compte EOA normal. Les informations spécifiques sur la transaction peuvent également être trouvées sur la page d'adresse actuelle dans etherscan.
Deux, exemples d'attaques de phishing 7702
Le 24 mai, le groupe de phishing #InfernoDrainer a utilisé la fonctionnalité d'exécution de masse du contrat 7702-Delegator de Metamask pour tromper massivement l'utilisateur (0xc6D2…06DC) en autorisations de tokens, et a mené une attaque de phishing, avec une perte de plus de 146 000 dollars en $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Adresse frauduleuse
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Exemple de transaction de phishing
Raison du phishing
L'utilisateur (0xc6D2…06DC) a exécuté une transaction d'autorisation de masse malveillante :
#InfernoDrainer et #PinkDrainer expérimentent des chaînes de phishing plus discrètes et plus impactantes utilisant 7702.
Selon notre recherche, les groupes de phishing #InfernoDrainer et #PinkDrainer explorent et expérimentent actuellement des chaînes de phishing plus discrètes et plus impactantes utilisant 7702. Les adresses concernées sont les suivantes, et nous publierons également un rapport plus détaillé par la suite :
Inferno Drainer：
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer：
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Trois, conseils de sécurité
Fournisseur de portefeuille :
Se référer à la mise en œuvre et à la gestion de la sécurité de MetaMask pour le 7702 Delegator, interdisant aux utilisateurs d'autoriser n'importe quel Delegator et ne permettant que les opérations dans l'application. Rappeler aux utilisateurs que toute opération permettant à l'utilisateur de signer une autorisation via le web est une attaque de phishing.
Vérifiez si la chaîne correspond au réseau actuel et avertissez les utilisateurs des risques de relecture lors de la signature avec un chainID égal à 0.
Lors de la signature d'autorisation par l'utilisateur, affichez le contrat cible, et lors de l'exécution de masse par le biais d'un Delegator, affichez le contenu spécifique de l'appel de fonction, réduisant ainsi les risques d'attaques de phishing sur le réseau.
Utilisateur :
La protection des clés privées est toujours la plus importante. Pas vos clés, pas vos pièces.
Ne jamais autoriser un Delegator sur la base d'une page web indépendante, les autorisations sécurisées sont généralement effectuées dans l'application, comme dans MetaMask.
Lors de l'utilisation de tout portefeuille pour signer, veuillez examiner attentivement le contenu de la signature pour éviter toute signature aveugle ou erronée.