Hoskinson advierte sobre el código de barrido de Binance en medio del debate sobre EIP-7702
Charles Hoskinson alerta sobre los riesgos potenciales de EIP-7702, vinculándolo a un reciente ataque a una billetera de Binance. Descubre más sobre las preocupaciones de seguridad.
Análisis de Charles Hoskinson sobre el EIP-7702 de Ethereum
El fundador de Cardano, Charles Hoskinson, ha alertado sobre un "código seriamente peligroso" al compartir un análisis que culpa a la función de delegación EIP-7702 de Ethereum por facilitar a los atacantes el vaciado rápido de una billetera caliente de Binance. En su publicación en X, Hoskinson escribió:
"Cuidado, hay un código seriamente peligroso por ahí", junto a un desglose publicado por CyberSatoshi.
La publicación que compartió describía el bytecode reconstruido de un supuesto barrido EIP-7702 de Binance, argumentando que el contrato estaba adaptado a las operaciones del intercambio. Sin embargo, el mensaje de Hoskinson no identificó un defecto específico del protocolo ni explicó qué parte del análisis respaldaba su afirmación.
Preguntas de Seguridad Planteadas
La cuenta de CyberSatoshi plantea dos preguntas de seguridad. La primera se refiere a cómo un atacante obtuvo permiso para actuar en nombre de la billetera, y la segunda se centra en lo que la función de delegación de Ethereum permitió al atacante hacer una vez obtenido ese permiso. Según el desglose de CyberSatoshi, el contrato reconstruido dejó exactamente 1 ETH en la billetera al barrer su saldo nativo, lo que evitó que la cola de billetera caliente automatizada de Binance fallara por falta de gas y activara alarmas.
El análisis describe un bucle de procesamiento de tokens que verifica saldos a través de llamadas de bajo nivel y continúa incluso cuando fallan operaciones individuales. CyberSatoshi argumentó que esto permitió que el barrido siguiera procesando activos, incluso si un token en la lista negra o de otro modo no respondía y no podía ser transferido.
Detalles del Ataque y la Función de Delegación
Una función de ejecución personalizada supuestamente permitió a la billetera comprometida llamar a un vault externo que contenía $823 millones en USDC. En la explicación del autor, el vault reconoció a Binance 14 como su controlador, permitiendo que las llamadas realizadas a través de esa billetera accedieran a fondos fuera de su saldo inmediato. CyberSatoshi caracterizó el contrato como diseñado específicamente para la arquitectura de Binance.
Las afirmaciones sobre su efecto en las alertas internas y los sistemas de tesorería son la explicación del autor de cómo funcionó la operación. La especificación EIP-7702 de Ethereum describe un tipo de transacción que permite a una cuenta de propiedad externa delegar la ejecución a un código desplegado en otra dirección. Una cuenta de propiedad externa normalmente opera a través de firmas de su clave privada.
La delegación permite ejecutar la lógica de contratos inteligentes en el contexto de su propia cuenta, apoyando características como agrupar varias operaciones en una sola transacción y permitir que otra cuenta pague las tarifas de transacción. Cada autorización identifica una cadena, una dirección delegada y un nonce, junto con una firma criptográfica. El protocolo recupera la cuenta autorizadora de esa firma y verifica su nonce antes de aplicar la delegación.
Requisitos de Seguridad y Consecuencias
CyberSatoshi reconoció este requisito, afirmando que el supuesto ataque necesitaba ya sea la clave privada en bruto o acceso de firma sin restricciones a la infraestructura de seguridad de Binance 14. La especificación no establece cómo se obtuvieron las credenciales de firma de Binance. Su requisito de firma establece que la delegación no puede ser asignada a una cuenta víctima arbitraria sin una autorización válida.
CyberSatoshi afirmó que el atacante presentó 50 autorizaciones pre-firmadas que cubrían nonces consecutivos para atrapar a Binance 14 mientras su conteo de transacciones estaba cambiando. La especificación procesa las autorizaciones en orden; cuando una autorización falla un chequeo, el procesamiento continúa con la siguiente entrada. Una entrada válida establece la delegación e incrementa el nonce de la cuenta autorizadora.
Por lo tanto, las autorizaciones sucesivas para la misma cuenta pueden volverse válidas a medida que ese nonce avanza. Donde existen varias entradas válidas, la última delegación válida determina la dirección de código utilizada, lo que es más específico que un lote en el que solo una autorización puede entrar en vigor. Las reglas permiten que múltiples entradas consecutivas tengan éxito, dependiendo del nonce inicial de la cuenta y las firmas suministradas.
CyberSatoshi argumentó que la delegación comprimió las transferencias de activos en una sola operación, reduciendo el tiempo disponible para la intervención. La afirmación de que las defensas del intercambio habrían detenido el robo después de tres transacciones es una evaluación contrafactual del autor.
Los autores del EIP advierten explícitamente que el código autorizado tiene acceso sin restricciones a la cuenta y debe ser auditado de cerca por la billetera. Su sección de seguridad enumera las protecciones que necesitan los contratos delegados, incluyendo prevención de repetición y firmas que cubren el valor de la transacción, gas, destino y datos de llamada.
Una delegación mal implementada puede dejar a un atacante con un control casi completo sobre la cuenta de firma. La delegación persiste más allá de la transacción que la instala. La especificación establece que un fallo de ejecución no revierte los indicadores de delegación ya procesados. Para eliminar la delegación, el protocolo permite una autorización válida que apunta a la dirección cero, lo que borra el código de delegación de la cuenta.