Explicación de los ataques del robot barredor EIP-7702
La actualización Pectra de Ethereum trajo la revolución de EIP-7702, pero también armó a los piratas informáticos con el arma definitiva: robots barredores financiados por patrocinadores que drenan las billeteras comprometidas sin necesidad de gas nativo.
Ataques de robots barredores EIP-7702: cuán comprometidos Carteras Drena el Gas Instantáneo Llega
- La llegada del hard fork Pectra de Ethereum representa uno de los puntos de inflexión más críticos en la historia de la arquitectura de cuentas descentralizadas. En el centro de este salto programático se encuentra EIP-7702, una propuesta diseñada para resolver la fricción de larga data entre las cuentas de propiedad externa (EOA), las billeteras estándar controladas por clave privada utilizadas por la gran mayoría de los usuarios minoristas, y Contrato inteligente Cuentas (CA).
- Al permitir que una EOA estándar adopte temporal o persistentemente los comportamientos de un contrato inteligente billetera, EIP-7702 brinda utilidades avanzadas, como procesamiento por lotes de transacciones, patrocinio de gas y lógica de recuperación personalizada, directamente al panorama de billetera existente.
- Sin embargo, en el ecosistema adversario de las cadenas de bloques públicas, cada avance tecnológico inevitablemente amplía el campo de juego para los actores maliciosos. Mientras los desarrolladores de Web3 celebran la democratización de la abstracción de cuentas, los círculos de seguridad de sombrero negro se han adaptado silenciosamente. La integración de EIP-7702 ha armado a los estafadores con una herramienta altamente peligrosa: el robot barredor financiado por patrocinadores.
- Históricamente, una billetera cuyas claves privadas se filtraron tenía muchas posibilidades de recuperación si no contenía ningún token de gas nativo (como ETH). Los equipos de seguridad podrían coordinar el rescate de transacciones privadas antes de que el script de monitoreo automatizado de un pirata informático pudiera anticipar el depósito de las tarifas del gas. Según EIP-7702, todo este marco defensivo ha sido completamente desmantelado.
1. El Génesis: Reducir la brecha entre la EOA y las cuentas inteligentes
- Para comprender por qué EIP-7702 representa un cambio tan masivo en la mecánica del robot barredor, primero debemos rastrear el proceso evolutivo de la abstracción de cuentas. Durante años, la comunidad Ethereum ha lidiado con las limitaciones de los EOA estándar. Una EOA es una entidad monolítica: se basa estrictamente en un par de claves del Algoritmo de firma digital de curva elíptica (ECDSA) para autorizar transacciones. Esta arquitectura introduce una fricción sustancial, en particular el problema del arranque de gas, la fragilidad de la firma única y la falta de procesamiento por lotes atómicos.
- Una EOA nueva no puede ejecutar ninguna acción en cadena hasta que haya sido financiada con tokens de gas nativos, lo que crea un grave obstáculo de incorporación. Además, si la clave privada de un EOA se pierde o es robada, la cuenta queda comprometida permanentemente; No existe un mecanismo de recuperación nativo ni una opción multifirma sin transferir los fondos a un contrato separado. Además, ejecutar un intercambio descentralizado básico (DeFi) el swap requiere dos transacciones secuenciales distintas: una transacción inicial de aprobación ERC-20 seguida de la ejecución real del swap. Esto cuesta gasolina extra y degrada la experiencia del usuario.
El camino hacia la abstracción de cuentas
- El primer gran intento estructural para abordar estas limitaciones fue ERC-4337. Este estándar introdujo un grupo de memoria de transacciones fuera de la cadena completamente separado donde los usuarios podían enviar operaciones de usuario a paquetes descentralizados. Estos paquetes empaquetarían múltiples operaciones en una única transacción estándar de Ethereum, enrutandolas a través de un contrato EntryPoint central para ejecutar la lógica de la billetera de contrato inteligente.
- Si bien ERC-4337 logró demostrar la viabilidad de la abstracción de cuentas, sufrió dos limitaciones clave: requirió que los usuarios migraran completamente sus activos desde sus EOA existentes a cuentas de contratos inteligentes completamente nuevas, e introdujo costos de gas más altos debido a las complejas capas de ejecución de contratos inteligentes.
- Para superar el obstáculo de la migración, los desarrolladores propusieron EIP-3074. Esta propuesta introdujo dos nuevos códigos de operación EVM que permitieron a una EOA delegar su autoridad a un contrato de invocador externo, permitiendo al invocador realizar transacciones en nombre de la EOA. Sin embargo, los auditores de seguridad rápidamente señalaron vulnerabilidades graves: un único contrato de invocador malicioso o comprometido podría obtener control ilimitado y permanente sobre cualquier EOA que lo autorizara, abriendo un vector devastador para ataques de phishing.
El compromiso definitivo
- En respuesta a estas preocupaciones de seguridad, Vitalik Buterin formuló EIP-7702. En lugar de introducir códigos de operación de delegación sin formato y de bajo nivel, EIP-7702 introduce un tipo de transacción especializada que permite a una EOA establecer temporal o persistentemente su propia ranura de código para apuntar a un contrato externo. Cuando se ejecuta una transacción EIP-7702, la EOA especifica una lista de autorización.
- Para cada entrada en esta lista, el EVM escribe temporalmente un prefijo de designación de delegación directamente en la ranura del código de la EOA. Esta designación le indica al EVM que enrute todas las llamadas de contrato posteriores dirigidas a ese EOA directamente a la lógica de implementación del contrato delegado especificado. Este mecanismo permite que las EOA estándar hereden instantáneamente todas las capacidades de las cuentas inteligentes (incluido el patrocinio de gas, los controles de firmas múltiples y el procesamiento por lotes de transacciones), manteniendo al mismo tiempo la compatibilidad total con versiones anteriores y dejando un camino claro para revertir la delegación apuntando la cuenta a la dirección nula.
2. El viejo paradigma: cómo operaban los robots barrenderos clásicos
- Para apreciar completamente cómo EIP-7702 ha optimizado la eficiencia de los robots de barrido maliciosos, debemos analizar las limitaciones estructurales del panorama de robots de barrido anterior a Pectra. Históricamente, cuando la clave privada o la frase inicial de recuperación de un usuario se veía comprometida, el atacante implementaba inmediatamente un robot de barrido: un script automatizado que se ejecutaba en un nodo RPC de alta velocidad y escaneaba continuamente el mempool público en busca de transacciones entrantes dirigidas a la dirección de billetera comprometida.
- El robot barredor clásico operaba bajo una restricción rígida: cada transacción que cambia de estado en la red Ethereum requiere la ejecución de gas nativo. Si la billetera comprometida contenía tokens ERC-20 de alto valor o NFT valiosos, pero no contenía gas nativo, el robot barredor del atacante quedaba temporalmente paralizado. El robot no pudo mover los tokens porque no había gas dentro de la billetera comprometida para pagar a los validadores por la transacción de transferencia.
En consecuencia, el robot barrendero tuvo que esperar a que la víctima o un equipo de rescate de sombrero blanco depositara ETH nativo en la billetera comprometida para facilitar la recuperación, o que la víctima intentara ejecutar una transacción directamente.
- En el momento en que el robot barrendero detectó una transacción pendiente que depositaba ETH en la dirección comprometida, calculó la tarifa de gas exacta requerida para anticipar cualquier transacción de rescate posterior. Al utilizar subastas de gas prioritarias o enrutar transacciones directamente a los constructores de bloques públicos, el robot barredor enviaría instantáneamente una transacción de transferencia con un precio de gas extremadamente alto. La transacción del robot se empaquetaría en la parte superior del siguiente bloque, barriendo con éxito los activos de la víctima y dejando que la transacción de rescate entrante falle debido a la falta de tokens restantes.
La trampilla de escape del Sombrero Blanco: Flashbots y MEV-Share
- Este requisito de gas creó un nicho altamente especializado para operaciones de rescate de sombrero blanco. Cuando un usuario se dio cuenta de que se había filtrado la clave de su billetera, podía contactar a expertos en seguridad para coordinar un Flashbots Rescue. Debido a que los mempools públicos están fuertemente monitoreados por robots limpiadores de piratas informáticos, los rescatistas utilizaron puntos finales RPC privados para evitar el mempool público por completo.
- Utilizando herramientas como Flashbots o MEV-Share, los rescatistas construirían un paquete de transacciones atómicas que contiene dos pasos distintos. Primero, una billetera externa segura propiedad del equipo de rescate enviaría la cantidad exacta de ETH necesaria para el gas a la billetera comprometida. En segundo lugar, la billetera comprometida transferiría inmediatamente sus valiosos tokens ERC-20 o NFT a una dirección de destino segura, utilizando el ETH recién depositado para cubrir el gas.
- Debido a que estas dos transacciones se agruparon y se enviaron directamente a los constructores de bloques cooperativos, se garantizó que se ejecutarían exactamente en el mismo bloque, uno tras otro, sin espacio para que interviniera un robot de barrido externo. El público nunca vio el depósito de gas entrante hasta que el bloque ya estuvo minado y finalizado, rescatando con éxito millones de dólares en riqueza digital.
3. Sweeper Bot: Descubriendo el exploit del patrocinio
- La integración de EIP-7702 ha desmantelado por completo las garantías de seguridad del clásico paquete de rescate Flashbots al introducir el patrocinio de gas. Según EIP-7702, una transacción puede ser enviada por un tercero (conocido como retransmisor o patrocinador) que paga las tarifas del gas en nombre del EOA objetivo. Esta única modificación ha eliminado el mayor cuello de botella del robot barrendero clásico: la necesidad de que la billetera de la víctima contenga gas nativo.
- Cuando un atacante obtiene acceso a una clave privada comprometida en la era posterior a Pectra, ya no necesita implementar un script pasivo que espera un depósito entrante de ETH. En cambio, el atacante puede configurar su robot barredor para que actúe como su propio patrocinador de gas. El bot construye una transacción EIP-7702 que contiene una carga útil de autorización firmada por el EOA comprometido. Esta carga útil actualiza temporalmente el EOA de la víctima a una billetera de contrato inteligente que contiene una rutina de transferencia por lotes.
- Luego, el atacante transmite esta transacción desde su propia billetera externa totalmente financiada. Debido a que la billetera del atacante es el origen de la transacción, las tarifas del gas se deducen directamente del saldo del atacante. El EVM procesa la transacción, instala temporalmente la lógica de transferencia personalizada en el EOA de la víctima y ejecuta instantáneamente una transferencia por lotes de todos los tokens ERC-20 y NFT a la dirección segura del atacante: todo en un solo paso atómico pagado por el patrocinador. La billetera de la víctima está completamente vacía sin tener ni una sola gota de ETH nativo.
Los dos principales vectores de ataque
Esta nueva clase de ataques de robots barrenderos opera a través de dos vectores de entrada distintos:
La clave privada comprometida: Si un pirata informático roba una frase inicial o una clave privada a través de un archivo de configuración filtrado, una copia de seguridad en la nube comprometida o malware de portapapeles, tiene la máxima autoridad para firmar cualquier carga útil. En lugar de esperar a que llegue el combustible, el robot barredor del atacante firma inmediatamente una carga útil de autorización EIP-7702 en nombre de la víctima. Luego, el robot envía la transacción, paga la gasolina y barre la cuenta al instante. Los equipos de rescate de sombrero blanco no pueden realizar un rescate clásico con Flashbots porque no hay ningún paso de financiación para agrupar; el atacante puede iniciar el barrido en cualquier momento que elija, con total independencia de las acciones de la víctima.
The Phishing-Delegation Signature: El segundo vector, aún más insidioso, no requiere que el atacante robe la clave privada de la víctima. En cambio, se basa en interfaces de phishing engañosas. Cuando un usuario visita un sitio web malicioso (disfrazado de un reclamo de lanzamiento aéreo o un panel de optimización de cartera), la dApp le solicita que firme un mensaje fuera de la cadena. Para el ojo inexperto, esto parece una firma estándar e inofensiva. En realidad, el usuario está firmando una tupla de autorización EIP-7702.
- Una vez capturada esta firma, la delegación está completa. El atacante ahora posee una carga útil criptográficamente válida que le permite actualizar el EOA de la víctima para señalar un contrato de implementación malicioso en cualquier momento. Debido a que cualquier persona puede enviar transacciones EIP-7702, el atacante puede mantener esta firma en reserva, esperando semanas o meses hasta que la víctima deposite una cantidad significativa de activos en su billetera.
- En el instante en que llega un activo de alto valor, el robot barredor del atacante envía la lista de autorización a la red, actualiza el EOA y drena los activos utilizando su propio gas patrocinado.
Tabla 1: Modelos de barredora
| Sistema | Requisito de gas |
| Viejo Barrendero | Necesita ETH de víctima |
| Nueva Barredora | Utiliza gas atacante |
4. Modificaciones de estado y flujo de ejecución a nivel de EVM
- Para comprender cómo EIP-7702 altera el comportamiento central de la máquina virtual Ethereum, debemos observar las reglas exactas de cambio de estado introducidas por este tipo de transacción. EIP-7702 introduce un nuevo tipo de transacción, designado formalmente por un envoltorio de sobre especializado. La carga útil de una transacción EIP-7702 incluye una estructura de transacción estándar junto con una adición crítica: la lista de autorización.
- La lista de autorización se representa como una lista de tuplas serializadas que contienen parámetros como el identificador de la cadena, la dirección del contrato inteligente de destino, el nonce de la cuenta y los componentes de la firma (paridad y, r y s) generados por la clave privada de la EOA.
- El identificador de cadena especifica la red exacta para evitar cadena cruzada ataques de repetición. La dirección indica la implementación del contrato inteligente de destino en la que el firmante desea delegar su cuenta. El nonce rastrea el recuento de transacciones actual del EOA del firmante para evitar la reutilización de la firma o la ejecución desordenada. Finalmente, los componentes de la firma se generan firmando el hash de los datos de autorización.
El Proceso de Transición Estatal
Cuando una transacción EIP-7702 se empaqueta en un bloque, el EVM procesa la lista de autorización antes de ejecutar cualquier carga útil de transacción. Para cada tupla válida de la lista, el EVM realiza varias operaciones:
Recuperación de firma: El EVM utiliza el algoritmo de recuperación de firma estándar para derivar la clave pública e identificar la dirección de la autoridad firmante.
Verificación sin contacto: El EVM verifica que el nonce en cadena del firmante coincida con el nonce especificado en la tupla. Si el nonce en cadena es mayor, la autorización se descarta como inválida.
Redacción del Designador de Delegación: Si la verificación tiene éxito, el EVM modifica el estado de la cuenta de autoridad. Escribe los bytes del designador de delegación directamente en la ranura del código de la cuenta. Este prefijo especial indica al EVM que la cuenta ya no es una EOA estándar para fines de ejecución. Todas las llamadas externas futuras dirigidas a la dirección de autoridad redireccionarán inmediatamente su contexto de ejecución al código que reside en la dirección delegada.
Incrementando el Nonce: El nonce en cadena de la cuenta de autoridad se incrementa en uno para evitar que se vuelva a ejecutar exactamente la misma carga útil de autorización.
5. La destrucción de la retrocompatibilidad: la falacia de la EOA únicamente
- Más allá de la amenaza inmediata de los robots de barrido patrocinados, EIP-7702 introduce un riesgo sistémico al ecosistema de contratos inteligentes más amplio al romper una suposición fundamental de la seguridad de Ethereum: la verificación de solo EOA. Durante casi una década, los desarrolladores de contratos inteligentes han utilizado un control de seguridad común y específico para verificar si una llamada entrante proviene de un usuario estándar u otro contrato inteligente.
- Históricamente, esta verificación se consideraba una protección confiable. Debido a que las transacciones estándar de Ethereum solo pueden iniciarse mediante una EOA, verificar que la persona que llama inmediatamente coincida con el iniciador original de la transacción garantiza que la persona que llama no sea un contrato inteligente.
- Esta suposición se utilizó ampliamente para defenderse de varias vulnerabilidades críticas, como las vulnerabilidades de préstamos rápidos (que impiden que los contratos inteligentes interactúen con las funciones de un protocolo durante un único bloque de transacción para neutralizar los ataques de obtención de capital) y los ataques de reentrada (que garantizan que la cuenta llamante no pueda ejecutar funciones de respaldo maliciosas para secuestrar los bucles de ejecución).
La subversión EIP-7702
- EIP-7702 invalida completamente esta verificación. Debido a que un EOA ahora puede delegar su ranura de código para apuntar a un contrato externo, un EOA puede comportarse exactamente como un contrato inteligente sin dejar de ser el iniciador de la transacción. Cuando un EOA delegado interactúa con un protocolo, la persona que llama y el origen de la transacción seguirán coincidiendo, pero la ranura de código del EOA contiene un código de bytes activo y ejecutable que puede ejecutar lógica maliciosa personalizada.
- Un ejemplo destacado del mundo real de esta vulnerabilidad ocurrió en la cadena BNB. Un atacante identificó un contrato DeFi no verificado que se basaba en la verificación exclusiva de EOA para restringir el acceso a su fondo de liquidez interno. El atacante implementó un contrato de delegación malicioso, firmó una carga útil de autorización EIP-7702 en su propio EOA e inició una transacción.
- Debido a que el EOA llevaba un código delegado, pasó por alto con éxito la verificación de EOA exclusiva del contrato. Cuando el protocolo transfirió tokens nativos al EOA, activó instantáneamente la función de respaldo del contrato delegado, lo que permitió al atacante ejecutar un exploit de reentrada recursivo y drenar el protocolo.
Tabla 2: Técnicas de Recuperación
| Método | Mecanismo |
| Antiguo Rescate | Paquetes de mempool privados |
| Nuevo Rescate | Restablecimiento de dirección cero |
6. Operaciones defensivas: sobrescritura y purga de delegaciones maliciosas
- Si descubre que su billetera ha sido comprometida a través de una firma de delegación maliciosa EIP-7702, las medidas de seguridad tradicionales como revocar las asignaciones de tokens ERC-20 ya no son suficientes. Debido a que el puntero de delegación le da al atacante control de ejecución permanente sobre su EOA, debe borrar activamente la delegación para recuperar la seguridad de su cuenta.
Afortunadamente, los arquitectos de EIP-7702 crearon un mecanismo nativo para restablecer la ranura de código de un EOA: delegar a la dirección cero.
- Cuando un EOA autoriza una delegación que apunta a la dirección cero, el EVM intercepta esto como un comando especial. En lugar de escribir un prefijo de delegación, el EVM borra completamente la ranura del código de la cuenta y restablece su código hash al estado vacío predeterminado. Esta acción restaura instantáneamente la billetera a un EOA limpio y estándar, cortando el control de ejecución del atacante.
El manual de recuperación: ejecutar una purga patrocinada
Debido a que una billetera comprometida probablemente sea monitoreada por un robot de barrido activo, intentar financiar la billetera con ETH para borrar la delegación es extremadamente arriesgado. Para reclamar la cuenta de forma segura, debe ejecutar una purga financiada por el patrocinador utilizando una dirección secundaria segura para pagar las tarifas del gas.
Paso 1: Aislar el EOA comprometido. Deje de depositar activos o ejecutar transacciones desde la billetera comprometida. Asegúrese de tener una billetera secundaria segura (con suficiente ETH para pagar la gasolina) para actuar como su patrocinador o retransmisor.
Paso 2: Generar la carga útil de reinicio. Redacte una carga útil de autorización EIP-7702 donde el campo de dirección de destino esté configurado en la dirección cero. La carga útil debe hacer referencia al nonce actual en cadena del EOA comprometido. Firme esta carga útil utilizando la clave privada del EOA comprometido.
Paso 3: Transmitir a través de Sponsor Wallet. Utilizando una herramienta de desarrollo de línea de comandos o un marco de desarrollo verificado, empaquete la carga útil de autorización firmada en una transacción EIP-7702. Configure los parámetros de la transacción para deducir las tarifas del gas directamente desde su billetera segura de patrocinador secundario. Transmita la transacción a la red.
Paso 4: Verificar el Restablecimiento del Estado. Una vez que se extrae la transacción, el EVM incrementará el nonce del EOA comprometido y borrará por completo el puntero de delegación de su ranura de código. Puede verificar el restablecimiento ejecutando una verificación de saldo y código en la dirección utilizando una herramienta de línea de comandos de desarrollo.
7. Telemetría en tiempo real y seguridad en cadena a través de DEXTools
- En el ecosistema post-Pectra altamente fragmentado, donde los rollups modulares, los tokens de gas personalizados y las cuentas de contratos inteligentes delegadas se están expandiendo rápidamente, mantener una visibilidad absoluta de sus activos es una necesidad. Cuando los usuarios interactúan con nuevos protocolos DeFi, grupos de rendimiento o marcos de recuperación de líquidos, habitualmente se les pide que firmen transacciones que, si son maliciosas, podrían contener cargas útiles de autorización EIP-7702 ocultas.
- Para proteger su cartera de estas tácticas avanzadas de phishing, debe practicar la verificación proactiva en cadena. Depender de las alertas básicas del navegador ya no es suficiente; necesita datos en tiempo real para auditar la seguridad de los grupos y contratos inteligentes con los que interactúa.
- DEXTools proporciona la infraestructura analítica crítica necesaria para realizar estas comprobaciones antes de autorizar cualquier firma en su billetera. Al ingresar la dirección del contrato de cualquier token directamente en el avanzado Explorador de pares de DEXTools, puede monitorear instantáneamente historiales de transacciones en vivo, analizar el estado de verificación del código fuente del contrato, verificar los bloqueos del fondo de liquidez y auditar los puntajes generales de confianza de seguridad.
- Esta telemetría de inspección garantiza que solo interactúe con protocolos verificados y de alta integridad, lo que mantiene sus activos digitales a salvo de las trampas precalculadas de las redes de drenaje modernas.
Puedes acceder a DEXTools aquí ¡y comience a operar hoy!
Descargo de responsabilidad: Este artículo tiene fines informativos únicamente y no constituye asesoramiento de inversión, asesoramiento financiero, asesoramiento comercial ni ningún otro tipo de asesoramiento. DEXTools no recomienda comprar, vender ni mantener ninguna criptomoneda o token. Los usuarios deben realizar su propia investigación y consultar con un asesor financiero calificado antes de tomar cualquier decisión de inversión. Las inversiones en criptomonedas son volátiles y de alto riesgo. DEXTools no es responsable de las pérdidas incurridas.