L'EIP-7702 conferisce agli indirizzi capacità e flessibilità simili a quelle dei contratti intelligenti, e sempre più applicazioni 7702 vengono continuamente create, il che è fondamentale per far entrare più persone nel Web3 e migliorare l'esperienza dell'utente.

Tuttavia, la flessibilità del 7702 e la maggioranza degli utenti che non sono ancora familiari con il 7702 stanno venendo sfruttati dai gruppi di frode; recentemente abbiamo osservato che alcuni utenti, a causa della capacità di esecuzione in blocco di Metamask 7702, sono stati indotti a combinare interazioni che richiedevano originariamente decine di autorizzazioni in un'unica transazione, portando al furto di beni.

Nota: MetaMask non ha problemi di sicurezza; MetaMask mette la sicurezza dell'utente al primo posto quando fornisce capacità relative al 7702 e ha adottato molte misure di sicurezza. Gli utenti devono saperne di più sulle capacità e sui rischi associati al 7702 per prevenire eventi di sicurezza simili in futuro.

Uno, Principi di autorizzazione della firma del Metamask 7702 Delagator e progettazione della sicurezza

1. Analisi tecnica

  • Autorizzato dall'utente il contratto Delegator già distribuito, il campo di codice dell'account dell'utente punta a quel contratto. L'attuale indirizzo del contratto Delegator ufficiale di MetaMask è: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B

  • Struttura di autorizzazione: (chainId, delegatorAddress, nonce, signature) scritta in authorization_list

  • Metodo di firma: MetaMask utilizza una logica di firma unificata per le transazioni di autorizzazione relative all'EIP-7702, ovvero il metodo signEIP7702Authorization, firmando i dati di autorizzazione digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) utilizzando ECDSA, generando la struttura di firma (v, r, s) e allegandola alla successiva transazione di Tipo-4, per realizzare l'autorizzazione e l'aggiornamento dell'account, vedi implementazione specifica: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts

  • Metodo di verifica: il layer di consenso completa la verifica tramite ecrecover(digest7702, sig) == tx.from.

  • Progettazione della sicurezza: il lato web non può indurre l'utente a autorizzare arbitrary Delegator, poiché il metodo signEIP7702Authorization è implementato solo all'interno del portafoglio MetaMask, non aperto per la chiamata tramite window.ethereum sul lato web. I metodi di firma accessibili dalla pagina web, come eth_signTypedData_v4, non sono adatti per la firma di autorizzazione EIP-7702, il cui formato di sintesi della firma è il seguente:

E il formato di firma richiesto dalla specifica EIP-7702 è:

Poiché eth_signTypedData_v4 include sempre il prefisso 0x1901 e il processo di calcolo del digest è completamente diverso dal 7702, anche se si costruiscono clever domainSeparator, primaryType e message, è quasi impossibile fare in modo che digest712 == digest7702.

Pertanto, il lato web non può falsificare legalmente la firma autorizzativa 7702 tramite questo metodo. Inoltre, MetaMask implementa un meccanismo di whitelist per gli indirizzi Delegator, consentendo per impostazione predefinita solo l'autorizzazione del Delegator ufficiale (0x63c0...32B), vietando ai DApp di iniettare indirizzi, per prevenire ulteriormente che gli utenti siano indotti a firmare dati di autorizzazione malevoli dei Delegator. L'EIP-7702 conferisce agli indirizzi capacità e flessibilità simili a quelle dei contratti intelligenti, e sempre più applicazioni 7702 vengono continuamente create, il che è fondamentale per far entrare più persone nel Web3 e migliorare l'esperienza dell'utente.

Tuttavia, la flessibilità del 7702 e la maggioranza degli utenti che non sono ancora familiari con il 7702 stanno venendo sfruttati dai gruppi di frode; recentemente abbiamo osservato che alcuni utenti, a causa della capacità di esecuzione in blocco di Metamask 7702, sono stati indotti a combinare interazioni che richiedevano originariamente decine di autorizzazioni in un'unica transazione, portando al furto di beni.

Nota: MetaMask non ha problemi di sicurezza; MetaMask mette la sicurezza dell'utente al primo posto quando fornisce capacità relative al 7702 e ha adottato molte misure di sicurezza. Gli utenti devono saperne di più sulle capacità e sui rischi associati al 7702 per prevenire eventi di sicurezza simili in futuro.

Uno, Principi di autorizzazione della firma del Metamask 7702 Delagator e progettazione della sicurezza

1. Analisi tecnica

  • Autorizzato dall'utente il contratto Delegator già distribuito, il campo di codice dell'account dell'utente punta a quel contratto. L'attuale indirizzo del contratto Delegator ufficiale di MetaMask è: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B

  • Struttura di autorizzazione: (chainId, delegatorAddress, nonce, signature) scritta in authorization_list

  • Metodo di firma: MetaMask utilizza una logica di firma unificata per le transazioni di autorizzazione relative all'EIP-7702, ovvero il metodo signEIP7702Authorization, firmando i dati di autorizzazione digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) utilizzando ECDSA, generando la struttura di firma (v, r, s) e allegandola alla successiva transazione di Tipo-4, per realizzare l'autorizzazione e l'aggiornamento dell'account, vedi implementazione specifica: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts

  • Metodo di verifica: il layer di consenso completa la verifica tramite ecrecover(digest7702, sig) == tx.from.

  • Progettazione della sicurezza: il lato web non può indurre l'utente a autorizzare arbitrarie Delegator, poiché il metodo signEIP7702Authorization è implementato solo all'interno del portafoglio MetaMask, non aperto per la chiamata tramite window.ethereum sul lato web. I metodi di firma accessibili dalla pagina web, come eth_signTypedData_v4, non sono adatti per la firma di autorizzazione EIP-7702, il cui formato di sintesi della firma è il seguente:

E il formato di firma richiesto dalla specifica EIP-7702 è:

Poiché eth_signTypedData_v4 include sempre il prefisso 0x1901 e il processo di calcolo del digest è completamente diverso dal 7702, anche se si costruiscono clever domainSeparator, primaryType e message, è quasi impossibile fare in modo che digest712 == digest7702.

Pertanto, il lato web non può falsificare legalmente la firma autorizzativa 7702 tramite questo metodo. Inoltre, MetaMask implementa un meccanismo di whitelist per gli indirizzi Delegator, consentendo per impostazione predefinita solo l'autorizzazione del Delegator ufficiale (0x63c0...32B), vietando ai DApp di iniettare indirizzi, per prevenire ulteriormente che gli utenti siano indotti a firmare dati di autorizzazione malevoli dei Delegator.

2. Modalità d'uso

Attualmente in MetaMask, l'aggiornamento degli EOA esistenti a conti intelligenti 7702 (Smart Account) è principalmente suddiviso in due categorie: aggiornamento attivo e aggiornamento passivo.

L'aggiornamento attivo si riferisce all'azione in cui l'utente fa clic attivamente sul pulsante "Cambia" nell'interfaccia del portafoglio, autorizzando un contratto Delegator specifico.

L'aggiornamento passivo si verifica quando l'utente interagisce con alcuni DApp che supportano il 7702; MetaMask rileva l'operazione pertinente e mostrerà automaticamente un avviso, suggerendo all'utente di completare l'aggiornamento.

2.1 Aggiornamento attivo:

  • Contenuto della transazione: include solo l'azione di aggiornamento del conto, ovvero l'autorizzazione di un contratto Delegator specifico.

  • Procedura di aggiornamento: accedi alla schermata dei dettagli dell'account nel portafoglio, fai clic sul pulsante di cambio nell'immagine sottostante e potrai aggiornare il tuo account in Ethereum Mainnet a un account intelligente. Dopo aver fatto clic su cambia, apparirà la finestra di firma della transazione di aggiornamento corrente:

  • Registro delle autorizzazioni: dopo la conferma, attendi che la transazione venga registrata sulla blockchain; la registrazione riuscita significa che l'utente ha aggiornato con successo a un account intelligente e può visualizzare le informazioni specifiche sulle transazioni di autorizzazione nella pagina dell'indirizzo attuale su etherscan nella sezione **Autorizzazioni (EIP-7702)**.


2. Modalità d'uso

Attualmente in MetaMask, l'aggiornamento degli EOA esistenti a conti intelligenti 7702 (Smart Account) è principalmente suddiviso in due categorie: aggiornamento attivo e aggiornamento passivo.

L'aggiornamento attivo si riferisce all'azione in cui l'utente fa clic attivamente sul pulsante "Cambia" nell'interfaccia del portafoglio, autorizzando un contratto Delegator specifico.

L'aggiornamento passivo si verifica quando l'utente interagisce con alcuni DApp che supportano il 7702; MetaMask rileva l'operazione pertinente e mostrerà automaticamente un avviso, suggerendo all'utente di completare l'aggiornamento.

2.1 Aggiornamento attivo:

  • Contenuto della transazione: include solo l'azione di aggiornamento del conto, ovvero l'autorizzazione di un contratto Delegator specifico.

  • Procedura di aggiornamento: accedi alla schermata dei dettagli dell'account nel portafoglio, fai clic sul pulsante di cambio nell'immagine sottostante e potrai aggiornare il tuo account in Ethereum Mainnet a un account intelligente. Dopo aver fatto clic su cambia, apparirà la finestra di firma della transazione di aggiornamento corrente:

  • Registro delle autorizzazioni: dopo la conferma, attendi che la transazione venga registrata sulla blockchain; la registrazione riuscita significa che l'utente ha aggiornato con successo a un account intelligente e può visualizzare le informazioni specifiche sulle transazioni di autorizzazione nella pagina dell'indirizzo attuale su etherscan nella sezione **Autorizzazioni (EIP-7702)**.

2.2 Aggiornamento passivo

  • Contenuto della transazione: include l'azione di aggiornamento dell'account e le azioni di invio in blocco in interazione con il contratto on-chain.

  • Procedura di aggiornamento: quando l'utente interagisce con alcuni DApp on-chain, MetaMask avviserà attivamente l'utente che la transazione corrente può essere completata utilizzando l'approccio di invio in blocco tramite l'aggiornamento a un account intelligente. Ad esempio, per effettuare uno swap di alcuni token su Uniswap, fai clic sul pulsante Usa account intelligente, aggiorna a un account intelligente e successivamente l'autorizzazione dei token e lo swap verranno completati in un'unica transazione.

2.3 Passa a EOA normale

Indipendentemente dal fatto che si utilizzi un aggiornamento attivo o passivo per convertire l'account corrente in un account intelligente, l'indirizzo del contratto Delegator associato sarà permanentemente memorizzato sulla blockchain, come logica di esecuzione corrente dell'account.

Se l'utente desidera ripristinare l'account a un normale EOA, deve avviare manualmente un'operazione di "cambio a EOA". L'essenza di questa operazione è: attraverso un'autorizzazione EIP-7702, inviare address(0) come nuovo indirizzo del contratto Delegator. Quando questa transazione viene registrata con successo sulla blockchain, il campo di codice dell'account verrà svuotato, la logica di esecuzione tornerà al codice vuoto predefinito e l'account tornerà allo stato normale di EOA.

Accedi alla schermata dei dettagli dell'account nel portafoglio, fai clic sul pulsante di cambio e potrai passare il tuo account da Ethereum Mainnet a un normale account EOA.

Dopo aver confermato, attendi che la transazione venga registrata sulla blockchain; la registrazione riuscita significa che l'utente è passato da un account intelligente a un normale account EOA, le informazioni dettagliate sulla transazione possono essere trovate anche nella pagina dell'indirizzo attuale su etherscan.

Due, Esempi di attacco di phishing 7702

Il 24 maggio, il gruppo di phishing #InfernoDrainer ha sfruttato la funzionalità di esecuzione in blocco del contratto Metamask 7702-Delagator per truffare in massa le autorizzazioni token dell'utente (0xc6D2…06DC) e ha attuato un attacco di phishing, con perdite superiori a 146.000 dollari in $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.

  • Indirizzo fraudolento

0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

  • Esempio di transazione di phishing

https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba

  • Motivo del phishing

L'utente (0xc6D2…06DC) ha eseguito una transazione di autorizzazione in blocco malevola:

Hash della transazione Ethereum: 0x1ddc8cecbc... | Etherscan

Chiamata 0xe9ae5c53 Metodo da 0xc6D289d5...0d2E606DC su 0xc6D289d5...0d2E606DC | Successo | 23 maggio 2025 14:31:35 PM (UTC)

etherscan.io

  • #InfernoDrainer e #PinkDrainer stanno sperimentando catene industriali di phishing più nascoste e impattanti che sfruttano il 7702.

Secondo la nostra ricerca, attualmente i gruppi di crimine informatico di phishing #InfernoDrainer e #PinkDrainer stanno studiando e sperimentando catene industriali di phishing più nascoste e impattanti che sfruttano il 7702; gli indirizzi pertinenti sono i seguenti e pubblicheremo un rapporto più dettagliato in seguito:

Inferno Drainer：

0x0000db5c8B030ae20308ac975898E09741e70000

Pink Drainer：

0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

Tre, Suggerimenti di sicurezza

Fornitore di portafoglio:

  • Riferimento all'implementazione e alla gestione della sicurezza di MetaMask per il Delegator 7702: vietare agli utenti di autorizzare arbitrarie Delegator e consentire solo operazioni interne all'app. Ricorda agli utenti che qualsiasi comportamento che fa firmare autorizzazioni agli utenti tramite una pagina web è un attacco di phishing.

  • Controlla se la catena corrisponde alla rete attuale e avvisa l'utente riguardo al rischio di ripetizione quando si firma utilizzando un chainID di 0.

  • Durante la firma dell'autorizzazione da parte dell'utente, mostra il contratto di destinazione; durante l'esecuzione in blocco tramite Delegator, mostra il contenuto della chiamata di funzione specifica per ridurre il rischio di attacchi di phishing online.

Utente：

  • La protezione della chiave privata è sempre la cosa più importante. Non sono le tue chiavi, non sono le tue monete.

  • Non autorizzare Delegator basandosi su alcuna pagina web indipendente; autorizzazioni sicure vengono generalmente effettuate all'interno dell'app come in MetaMask.

  • Quando utilizzi qualsiasi portafoglio per firmare, fai attenzione al contenuto della firma per evitare firme cieche o errate. Dopo aver cliccato su conferma, attendi che la transazione venga registrata sulla blockchain; la registrazione riuscita significa che l'utente è passato da un account intelligente a un normale account EOA, le informazioni dettagliate sulla transazione possono essere trovate anche nella pagina dell'indirizzo attuale su etherscan.

    Due, Esempi di attacco di phishing 7702

    Il 24 maggio, il gruppo di phishing #InfernoDrainer ha sfruttato la funzionalità di esecuzione in blocco del contratto Metamask 7702-Delagator per truffare in massa le autorizzazioni token dell'utente (0xc6D2…06DC) e ha attuato un attacco di phishing, con perdite superiori a 146.000 dollari in $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.

    • Indirizzo fraudolento

    0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

    • Esempio di transazione di phishing

    • Motivo del phishing

    L'utente (0xc6D2…06DC) ha eseguito una transazione di autorizzazione in blocco malevola:

    • #InfernoDrainer e #PinkDrainer stanno sperimentando catene industriali di phishing più nascoste e impattanti che sfruttano il 7702.

    Secondo la nostra ricerca, attualmente i gruppi di crimine informatico di phishing #InfernoDrainer e #PinkDrainer stanno studiando e sperimentando catene industriali di phishing più nascoste e impattanti che sfruttano il 7702; gli indirizzi pertinenti sono i seguenti e pubblicheremo un rapporto più dettagliato in seguito:

    Inferno Drainer：

    0x0000db5c8B030ae20308ac975898E09741e70000

    Pink Drainer：

    0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

    Tre, Suggerimenti di sicurezza

    Fornitore di portafoglio：

    • Riferimento all'implementazione e alla gestione della sicurezza di MetaMask per il Delegator 7702: vietare agli utenti di autorizzare arbitrarie Delegator e consentire solo operazioni interne all'app. Ricorda agli utenti che qualsiasi comportamento che fa firmare autorizzazioni agli utenti tramite una pagina web è un attacco di phishing.

    • Controlla se la catena corrisponde alla rete attuale e avvisa l'utente riguardo al rischio di ripetizione quando si firma utilizzando un chainID di 0.

    • Durante la firma dell'autorizzazione da parte dell'utente, mostra il contratto di destinazione; durante l'esecuzione in blocco tramite Delegator, mostra il contenuto della chiamata di funzione specifica per ridurre il rischio di attacchi di phishing online.

    Utente：

    • La protezione della chiave privata è sempre la cosa più importante. Non sono le tue chiavi, non sono le tue monete.

    • Non autorizzare Delegator basandosi su alcuna pagina web indipendente; autorizzazioni sicure vengono generalmente effettuate all'interno dell'app come in MetaMask.

    • Quando utilizzi qualsiasi portafoglio per firmare, fai attenzione al contenuto della firma per evitare firme cieche o errate.