EIP-7702 otorga a las direcciones capacidades y flexibilidad similares a las de un contrato inteligente, y cada vez se están creando más aplicaciones 7702, lo cual es crucial para atraer a más personas al Web3 y mejorar la experiencia del usuario.
Sin embargo, la flexibilidad de 7702 y la falta de familiaridad de la mayoría de los usuarios con 7702 están siendo aprovechadas por bandas de fraude. Recientemente hemos observado que algunos usuarios, debido a la capacidad de ejecución masiva de Metamask 7702, vieron interacciones que originalmente requerían múltiples autorizaciones ser combinadas en una sola transacción por la banda de phishing #InfernoDrainer, lo que resultó en el robo de activos.
Nota：MetaMask en sí no tiene problemas de seguridad; MetaMask prioriza la seguridad del usuario al proporcionar capacidades relacionadas con el 7702 y ha implementado muchas medidas de seguridad. Los usuarios necesitan comprender más sobre las capacidades y riesgos relacionados con el 7702 para evitar que ocurran eventos de seguridad similares en el futuro.
Uno, Principios de autorización de firma y diseño de seguridad del 7702 Delagator de Metamask
1. Análisis técnico
El usuario autoriza un contrato Delegator ya desplegado, señalando el campo de código de la cuenta del usuario a dicho contrato. La dirección actual del contrato Delegator oficial de MetaMask es：0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Estructura de autorización：(chainId, delegatorAddress, nonce, signature) se escribe en authorization_list
Método de firma：la lógica de firma unificada para las transacciones de autorización relacionadas con EIP-7702 en la capa base de Metamask es el método signEIP7702Authorization, que firma el resumen de autorización digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) utilizando ECDSA, generando la estructura de firma (v, r, s) y adjuntándola a la transacción de tipo 4 subsiguiente, permitiendo la autorización y actualización de la cuenta. Para más detalles, consulta: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Método de verificación：la capa de consenso verifica completando ecrecover(digest7702, sig) == tx.from.
Diseño de seguridad：la versión web no puede inducir a los usuarios a autorizar cualquier Delegator, ya que el método signEIP7702Authorization se implementa únicamente dentro de la billetera MetaMask, sin permitir llamadas desde window.ethereum a la versión web. Los métodos de firma accesibles desde la web, como eth_signTypedData_v4, no son aplicables a las firmas de autorización EIP-7702, y su formato de resumen de firma es el siguiente：
Mientras que el formato de firma requerido por la especificación EIP-7702 es：
Debido a que eth_signTypedData_v4 incluye un prefijo fijo de 0x1901 y el proceso de cálculo del resumen es completamente diferente al de 7702, incluso si se construyen clever domainSeparator, primaryType y message, es casi imposible que digest712 == digest7702.
Por lo tanto, la versión web no puede falsificar una firma de autorización 7702 legítima a través de este método. Además, MetaMask implementa un mecanismo de lista blanca para las direcciones Delegator, permitiendo por defecto y solo autorizando al Delegator oficial (0x63c0...32B), prohibiendo que las DApps inyecten direcciones, evitando así que los usuarios sean inducidos a firmar datos de autorización de Delegator maliciosos. EIP-7702 otorga a las direcciones capacidades y flexibilidad similares a las de un contrato inteligente, y cada vez se están creando más aplicaciones 7702, lo cual es crucial para atraer a más personas al Web3 y mejorar la experiencia del usuario.
Sin embargo, la flexibilidad de 7702 y la falta de familiaridad de la mayoría de los usuarios con 7702 están siendo aprovechadas por bandas de fraude. Recientemente hemos observado que algunos usuarios, debido a la capacidad de ejecución masiva de Metamask 7702, vieron interacciones que originalmente requerían múltiples autorizaciones ser combinadas en una sola transacción por la banda de phishing #InfernoDrainer, lo que resultó en el robo de activos.
Nota：MetaMask en sí no tiene problemas de seguridad; MetaMask prioriza la seguridad del usuario al proporcionar capacidades relacionadas con el 7702 y ha implementado muchas medidas de seguridad. Los usuarios necesitan comprender más sobre las capacidades y riesgos relacionados con el 7702 para evitar que ocurran eventos de seguridad similares en el futuro.
Uno, Principios de autorización de firma y diseño de seguridad del 7702 Delagator de Metamask
1. Análisis técnico
El usuario autoriza un contrato Delegator ya desplegado, señalando el campo de código de la cuenta del usuario a dicho contrato. La dirección actual del contrato Delegator oficial de MetaMask es：0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Estructura de autorización：(chainId, delegatorAddress, nonce, signature) se escribe en authorization_list
Método de firma：la lógica de firma unificada para las transacciones de autorización relacionadas con EIP-7702 en la capa base de Metamask es el método signEIP7702Authorization, que firma el resumen de autorización digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) utilizando ECDSA, generando la estructura de firma (v, r, s) y adjuntándola a la transacción de tipo 4 subsiguiente, permitiendo la autorización y actualización de la cuenta. Para más detalles, consulta: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Método de verificación：la capa de consenso verifica completando ecrecover(digest7702, sig) == tx.from.
Diseño de seguridad：la versión web no puede inducir a los usuarios a autorizar cualquier Delegator, ya que el método signEIP7702Authorization se implementa únicamente dentro de la billetera MetaMask, sin permitir llamadas desde window.ethereum a la versión web. Los métodos de firma accesibles desde la web, como eth_signTypedData_v4, no son aplicables a las firmas de autorización EIP-7702, y su formato de resumen de firma es el siguiente：
Mientras que el formato de firma requerido por la especificación EIP-7702 es：
Debido a que eth_signTypedData_v4 incluye un prefijo fijo de 0x1901 y el proceso de cálculo del resumen es completamente diferente al de 7702, incluso si se construyen clever domainSeparator, primaryType y message, es casi imposible que digest712 == digest7702.
Por lo tanto, la versión web no puede falsificar una firma de autorización 7702 legítima a través de este método. Además, MetaMask implementa un mecanismo de lista blanca para las direcciones Delegator, permitiendo por defecto y solo autorizando al Delegator oficial (0x63c0...32B), prohibiendo que las DApps inyecten direcciones, evitando así que los usuarios sean inducidos a firmar datos de autorización de Delegator maliciosos.
2. Método de uso
Actualmente en Metamask, la forma de actualizar una EOA existente a una cuenta inteligente 7702 (Smart Account) se divide principalmente en dos categorías: actualización activa y actualización pasiva.
La actualización activa se refiere a que el usuario hace clic activamente en el botón 'Cambiar' en la interfaz de la billetera, autorizando un contrato Delegator específico.
La actualización pasiva ocurre cuando el usuario interactúa con ciertas DApps que soportan 7702. Cuando Metamask detecta la operación relevante, aparecerá automáticamente un aviso, sugiriendo al usuario completar la actualización.
2.1 Actualización activa：
Contenido de la transacción：solo incluye la acción de actualizar la cuenta, es decir, autorizar un contrato Delegator específico.
Proceso de actualización：accede a la interfaz de detalles de la cuenta en la billetera, haz clic en el botón de cambiar en la imagen de abajo, lo que permitirá al usuario actualizar su cuenta en Ethereum Mainnet a una cuenta inteligente. Después de hacer clic en cambiar, aparecerá la ventana para que el usuario firme la transacción de actualización actual：
Registro de autorizaciones：después de confirmar, espera a que la transacción se registre en la cadena. El registro exitoso en la cadena significa que el usuario se ha actualizado correctamente a una cuenta inteligente, y se puede consultar la información de la transacción de autorización específica en la página de la dirección de la billetera actual en **Autorizaciones (EIP-7702)** en etherscan.
2. Método de uso
Actualmente en Metamask, la forma de actualizar una EOA existente a una cuenta inteligente 7702 (Smart Account) se divide principalmente en dos categorías: actualización activa y actualización pasiva.
La actualización activa se refiere a que el usuario hace clic activamente en el botón 'Cambiar' en la interfaz de la billetera, autorizando un contrato Delegator específico.
La actualización pasiva ocurre cuando el usuario interactúa con ciertas DApps que soportan 7702. Cuando Metamask detecta la operación relevante, aparecerá automáticamente un aviso, sugiriendo al usuario completar la actualización.
2.1 Actualización activa：
Contenido de la transacción：solo incluye la acción de actualizar la cuenta, es decir, autorizar un contrato Delegator específico.
Proceso de actualización：accede a la interfaz de detalles de la cuenta en la billetera, haz clic en el botón de cambiar en la imagen de abajo, lo que permitirá al usuario actualizar su cuenta en Ethereum Mainnet a una cuenta inteligente. Después de hacer clic en cambiar, aparecerá la ventana para que el usuario firme la transacción de actualización actual：
Registro de autorizaciones：después de confirmar, espera a que la transacción se registre en la cadena. El registro exitoso en la cadena significa que el usuario se ha actualizado correctamente a una cuenta inteligente, y se puede consultar la información de la transacción de autorización específica en la página de la dirección de la billetera actual en **Autorizaciones (EIP-7702)** en etherscan.
2.2 Actualización pasiva
Contenido de la transacción：incluye la acción de actualizar la cuenta y las acciones masivas de interacción con el contrato en la cadena.
Proceso de actualización：cuando el usuario interactúa con ciertas DApps en la cadena, Metamask sugerirá activamente al usuario que la transacción actual se puede completar mediante la actualización a una cuenta inteligente usando el método de envío masivo. Por ejemplo, al realizar un intercambio de ciertos tokens en Uniswap, al hacer clic en el botón Usar cuenta inteligente, se actualiza a una cuenta inteligente, y luego la autorización del token y el intercambio se completarán en una sola transacción.
2.3 Volver a EOA normal
Independientemente de si se utiliza el método de actualización activa o pasiva para convertir la cuenta actual en una cuenta inteligente, la dirección del contrato Delegator vinculado se almacenará de forma permanente en la cadena, como la lógica de ejecución actual de la cuenta.
Si el usuario desea restaurar la cuenta a una EOA normal, debe iniciar manualmente una operación de 'volver a EOA'. La esencia de esta operación es: a través de una autorización EIP-7702, enviar address(0) como nueva dirección del contrato Delegator. Cuando la transacción se registre exitosamente en la cadena, el campo de código de la cuenta se vaciará y la lógica de ejecución volverá a ser el código vacío por defecto, y la cuenta volverá al estado EOA normal.
Accede a la interfaz de detalles de la cuenta en la billetera, haz clic en el botón de cambiar, lo que permitirá al usuario cambiar de su cuenta en Ethereum Mainnet a una cuenta EOA normal.
Después de hacer clic en confirmar, espera a que la transacción se registre en la cadena. El registro exitoso en la cadena significa que el usuario ha cambiado de una cuenta inteligente a una cuenta EOA normal, y la información específica de la transacción también se puede encontrar en la página de dirección de la billetera actual en etherscan.
Dos, Ejemplos de ataques de phishing 7702
El 24 de mayo, la banda de phishing #InfernoDrainer utilizó la función de ejecución masiva del contrato 7702-Delagator de Metamask para engañar masivamente a los usuarios (0xc6D2…06DC) para que autorizaran tokens, llevando a cabo un ataque de phishing, con pérdidas superiores a $146,000 en $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Dirección fraudulenta
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Ejemplo de transacción de phishing
https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba
Razón del phishing
El usuario (0xc6D2…06DC) realizó una transacción de autorización masiva maliciosa：
Hash de la transacción Ethereum: 0x1ddc8cecbc... | Etherscan
Llamada al Método 0xe9ae5c53 por 0xc6D289d5...0d2E606DC en 0xc6D289d5...0d2E606DC | Éxito | 23 de mayo de 2025 02:31:35 PM (UTC)
etherscan.io
#InfernoDrainer y #PinkDrainer están experimentando con una cadena de producción negra de phishing más encubierta y de mayor impacto utilizando 7702.
Según nuestra investigación, actualmente las bandas de fraude de phishing #InfernoDrainer y #PinkDrainer están investigando y experimentando con una cadena de producción negra de phishing más encubierta y de mayor impacto utilizando 7702, las direcciones relacionadas son las siguientes, y también publicaremos un informe más detallado posteriormente：
Drainer Inferno：
0x0000db5c8B030ae20308ac975898E09741e70000
Drainer Pink：
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Tres, Recomendaciones de seguridad
Proveedor de billetera：
Referencia a la implementación y gestión de seguridad de MetaMask para el Delegator 7702, prohibiendo a los usuarios autorizar cualquier Delegator, permitiendo solo operaciones dentro de la aplicación. Se recuerda a los usuarios que cualquier acción que los induzca a firmar autorizaciones a través de una página web es un ataque de phishing.
Verifica si la cadena coincide con la red actual y recuerda a los usuarios que existe un riesgo de repetición al firmar con chainID igual a 0.
Al firmar la autorización del usuario, muestra el contrato objetivo, y al ejecutar en masa a través de Delegator, muestra el contenido específico de la llamada de función, reduciendo el riesgo de ataques de phishing en la red.
Usuario：
La protección de la clave privada siempre es lo más importante. No son tus claves, no son tus monedas.
No autorices a ningún Delegator basándote en ninguna página web independiente; las autorizaciones seguras generalmente solo se realizan dentro de la aplicación como MetaMask.
Al utilizar cualquier billetera para firmar, asegúrate de leer cuidadosamente el contenido de la firma para evitar firmas ciegas o erróneas. Después de hacer clic en confirmar, espera a que la transacción se registre en la cadena. El registro exitoso en la cadena significa que el usuario ha cambiado de una cuenta inteligente a una cuenta EOA normal, y la información específica de la transacción también se puede encontrar en la página de dirección de la billetera actual en etherscan.
Dos, Ejemplos de ataques de phishing 7702
El 24 de mayo, la banda de phishing #InfernoDrainer utilizó la función de ejecución masiva del contrato 7702-Delagator de Metamask para engañar masivamente a los usuarios (0xc6D2…06DC) para que autorizaran tokens, llevando a cabo un ataque de phishing, con pérdidas superiores a $146,000 en $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Dirección fraudulenta
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Ejemplo de transacción de phishing
Razón del phishing
El usuario (0xc6D2…06DC) realizó una transacción de autorización masiva maliciosa：
#InfernoDrainer y #PinkDrainer están experimentando con una cadena de producción negra de phishing más encubierta y de mayor impacto utilizando 7702.
Según nuestra investigación, actualmente las bandas de fraude de phishing #InfernoDrainer y #PinkDrainer están investigando y experimentando con una cadena de producción negra de phishing más encubierta y de mayor impacto utilizando 7702, las direcciones relacionadas son las siguientes, y también publicaremos un informe más detallado posteriormente：
Drainer Inferno：
0x0000db5c8B030ae20308ac975898E09741e70000
Drainer Pink：
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Tres, Recomendaciones de seguridad
Proveedor de billetera：
Referencia a la implementación y gestión de seguridad de MetaMask para el Delegator 7702, prohibiendo a los usuarios autorizar cualquier Delegator, permitiendo solo operaciones dentro de la aplicación. Se recuerda a los usuarios que cualquier acción que los induzca a firmar autorizaciones a través de una página web es un ataque de phishing.
Verifica si la cadena coincide con la red actual y recuerda a los usuarios que existe un riesgo de repetición al firmar con chainID igual a 0.
Al firmar la autorización del usuario, muestra el contrato objetivo, y al ejecutar en masa a través de Delegator, muestra el contenido específico de la llamada de función, reduciendo el riesgo de ataques de phishing en la red.
Usuario：
La protección de la clave privada siempre es lo más importante. No son tus claves, no son tus monedas.
No autorices a ningún Delegator basándote en ninguna página web independiente; las autorizaciones seguras generalmente solo se realizan dentro de la aplicación como MetaMask.
Al utilizar cualquier billetera para firmar, asegúrate de leer cuidadosamente el contenido de la firma para evitar firmas ciegas o erróneas.