Ataque a Binance: qué revela la delegación de código en Ethereum

Una autorización añade funciones a la cuenta

El análisis del ataque a Binance destaca una función de Ethereum: EIP-7702 permite que una cuenta ordinaria designe código cuyas instrucciones ejecutará. Esta delegación exige una autorización firmada por la cuenta afectada. Puede añadir funciones programables a un monedero, pero su efecto depende del programa elegido. En el caso estudiado por Hacken y otros analistas, la cuenta identificada como Binance 14 quedó asociada a un programa destinado a trasladar sus activos al atacante.

La especificación explica que una delegación puede persistir después de la transacción que la instala. El monedero no recupera automáticamente su comportamiento original tras la primera ejecución. Esta propiedad da un significado particular a la revocación o sustitución de una autorización. No implica que todas las aplicaciones que usan la función estén comprometidas: el riesgo depende del código autorizado y de cómo se obtiene la firma. EIP-7702 tampoco debe describirse como un simple protocolo de multifirma.

El contador explica la serie de autorizaciones

Hacken informa de 50 autorizaciones preparadas para valores consecutivos del contador del monedero. Este contador, normalmente denominado nonce, permite ordenar las operaciones de una cuenta. Una autorización solo se aplica si sus condiciones coinciden con el estado esperado. En un monedero operativo de uso frecuente, ese estado puede cambiar entre la preparación y la ejecución. Una serie de valores sucesivos aumenta las oportunidades de encontrar el valor correcto, sin demostrar que se hayan eludido las reglas de validación de la red o falsificado firmas.

Sin embargo, este desarrollo no explica todas las transferencias del incidente. Los análisis distinguen la delegación observada en Ethereum de los movimientos ordinarios firmados en otras redes y desde otros monederos. Reducir todo el ataque a esta función dejaría fuera su dimensión multicadena. La observación pública muestra qué se autorizó y ejecutó; no revela directamente la organización interna de Binance, los accesos obtenidos previamente ni todas las validaciones que deberían haber impedido las instrucciones maliciosas.

Una firma válida no revela toda la intrusión

Una clave extraída y un sistema legítimo de firma secuestrado pueden producir transacciones con firmas válidas. La cadena permite verificar esa validez, pero no distinguir automáticamente ambos escenarios. Binance afirma que su investigación no ha encontrado pruebas de filtración de claves privadas por el momento. Esa formulación debe conservar su alcance limitado: describe conclusiones provisionales del operador, sin convertir la ausencia de pruebas publicadas en una demostración definitiva de lo sucedido dentro de sus sistemas.

El informe técnico completo deberá conectar las observaciones públicas con pruebas internas: origen del acceso, permisos obtenidos, proceso de firma y controles de retiro. Mientras tanto, pueden explicarse la delegación utilizada y los riesgos de un programa autorizado a actuar sobre una cuenta sin atribuir a Ethereum una vulnerabilidad no demostrada. La cuestión central sigue siendo la obtención de las autorizaciones necesarias. Entender su uso ayuda a reconstruir la ejecución; no sustituye la identificación de la causa inicial ni la comprobación de todas las hipótesis de investigación.