Por Canuto  

Charles Hoskinson advirtió sobre un código que calificó de peligroso tras compartir un análisis que atribuye a EIP-7702 un papel en el presunto vaciado de una billetera caliente de Binance. El desglose sostiene que el atacante habría usado autorizaciones firmadas y una lógica adaptada a la infraestructura del exchange, aunque no establece cómo habría obtenido acceso para firmar.

***

  • CyberSatoshi afirmó que un contrato reconstruido habría procesado activos y dejado 1 ETH para evitar que una cola automatizada de Binance se quedara sin gas.
  • El análisis sostuvo que 50 autorizaciones con nonces consecutivos podrían haber permitido seguir el contador cambiante de la billetera Binance 14.
  • EIP-7702 requiere una autorización criptográfica válida para delegar código, que puede operar con acceso amplio a la cuenta; el análisis no explica cómo se habrían obtenido las credenciales.

 

Charles Hoskinson, fundador de Cardano, advirtió sobre lo que describió como código «seriamente peligroso» al difundir un análisis de un presunto vaciado de una billetera caliente de Binance. El desglose, elaborado por CyberSatoshi, atribuye a la función de delegación EIP-7702 de Ethereum un papel en la rapidez de las operaciones, pero no demuestra por sí solo una falla del protocolo ni explica cómo se habrían conseguido las firmas necesarias.

Una alerta y dos preguntas de seguridad

La advertencia de Hoskinson acompañó un análisis que reconstruye el bytecode de un supuesto sweeper asociado a Binance. Su mensaje fue breve y no especificó qué parte del desglose respaldaba ni identificó un defecto concreto de Ethereum. Por eso, la alerta pública y las conclusiones técnicas del autor deben leerse como elementos relacionados, pero no equivalentes.

El análisis de CyberSatoshi plantea dos cuestiones distintas: cómo habría conseguido un atacante autorización para actuar en nombre de la billetera y qué capacidad le habría ofrecido la delegación una vez obtenida esa autorización. La distinción es central porque EIP-7702 no elimina el requisito de firma: una cuenta no puede quedar delegada a voluntad de un tercero sin una autorización criptográfica válida.

Según el desglose publicado por crypto.news, CyberSatoshi sostuvo que el contrato habría sido adaptado a las operaciones de las billeteras de Binance. Esa caracterización es una conclusión del autor, no una confirmación independiente de la arquitectura interna del exchange ni una explicación verificada de sus controles, alertas o procedimientos de tesorería.

La información disponible tampoco establece cómo habría ocurrido el presunto acceso a las credenciales de firma, qué persona o sistema habría autorizado las operaciones ni cómo se detectó el incidente. CyberSatoshi sostuvo que el escenario requería la clave privada en bruto o acceso de firma sin restricciones a la infraestructura de seguridad de Binance 14, un punto que limita cualquier afirmación sobre el origen del ataque.

El contrato habría intentado sortear obstáculos operativos

CyberSatoshi afirmó que el contrato reconstruido dejaba exactamente 1 ETH en la billetera después de barrer su saldo nativo. Según su explicación, ese remanente habría evitado que la cola automatizada de billeteras calientes de Binance fallara por falta de gas y generara alertas. El análisis no aporta una confirmación independiente de ese supuesto efecto sobre los sistemas internos del exchange.

El análisis también describe un bucle para procesar tokens que consultaba saldos mediante llamadas de bajo nivel y seguía adelante cuando una operación individual fallaba. En esa lógica, un token en lista negra o que no respondiera no necesariamente habría detenido el resto del proceso, lo que habría permitido al contrato continuar con otros activos pese a un error parcial.

Otra función personalizada habría permitido a la billetera comprometida llamar a una bóveda externa que, de acuerdo con CyberSatoshi, contenía USD $823 millones en USDC. El autor sostuvo que esa bóveda reconocía a Binance 14 como controlador, por lo que las llamadas realizadas desde esa billetera podrían alcanzar fondos que no estaban en su saldo inmediato.

El análisis presenta estos detalles como indicios de una herramienta hecha a medida para la arquitectura de Binance, pero sus afirmaciones sobre el funcionamiento de alertas y sistemas de tesorería siguen siendo la interpretación de CyberSatoshi. La información citada no incluye una explicación de Binance que confirme cómo se comportaron sus salvaguardas.

Qué permite EIP-7702 y qué autorización exige

EIP-7702 introduce un tipo de transacción mediante el cual una cuenta de propiedad externa puede delegar la ejecución a código desplegado en otra dirección. Una cuenta de ese tipo suele operar con firmas vinculadas a su clave privada, y la delegación permite ejecutar lógica de contratos inteligentes en el contexto de la propia cuenta, en lugar de limitarse a una transferencia convencional.

Entre los usos que contempla el diseño están agrupar varias operaciones en una transacción y permitir que otra cuenta pague las tarifas. Esa flexibilidad amplía lo que una cuenta puede hacer, pero también vuelve decisivo el alcance de la autorización: el código delegado puede actuar dentro del contexto de la cuenta que firmó, con consecuencias que dependen del código autorizado y de cómo se revisaron sus permisos.

La autorización identifica una cadena, una dirección de código delegado y un nonce, además de incluir una firma criptográfica. El protocolo recupera de esa firma la cuenta autorizadora y comprueba su nonce antes de aplicar la delegación, por lo que no basta con conocer la dirección de una víctima para asignarle código arbitrario.

CyberSatoshi sostuvo que el presunto ataque habría necesitado la clave privada de Binance 14 o acceso de firma sin restricciones a su infraestructura de seguridad. La especificación de Ethereum establece el requisito criptográfico, pero no explica cómo se habrían obtenido las credenciales de Binance; por tanto, el mecanismo de delegación describe una capacidad posible, no el origen del permiso ni quién lo habría concedido.

Las autorizaciones y el avance del nonce

CyberSatoshi afirmó que el atacante envió 50 autorizaciones firmadas con nonces consecutivos para alcanzar a Binance 14 mientras cambiaba su contador de transacciones. El nonce funciona como un número de secuencia para las operaciones de una cuenta, y su verificación impide aplicar autorizaciones que no coincidan con el estado que mantiene el protocolo en ese momento.

La especificación procesa las autorizaciones en orden y continúa con la siguiente entrada si una no supera la verificación. Cuando una autorización resulta válida, establece la delegación e incrementa el nonce de la cuenta autorizadora; por ello, entradas consecutivas bien firmadas podrían volverse válidas a medida que avanza ese contador.

Si varias autorizaciones de una misma secuencia son válidas, la última delegación válida determina qué dirección de código se utiliza. El detalle importa porque el mecanismo no implica necesariamente que solo una autorización de un lote pueda surtir efecto: el resultado depende del nonce inicial y de las firmas proporcionadas, según las reglas descritas por EIP-7702.

El autor sostuvo que esa delegación habría comprimido las transferencias de activos en una sola operación y reducido el tiempo disponible para intervenir. También afirmó que las defensas del exchange podrían haber detenido el robo después de tres transacciones, pero esa evaluación es contrafáctica: el desglose no aporta evidencia que permita comprobar qué habría ocurrido bajo un escenario distinto.

El riesgo está en la delegación y en los controles de firma

Los autores de EIP-7702 advierten que el código autorizado recibe acceso amplio a la cuenta y que la billetera debe auditarlo cuidadosamente. Entre las medidas de seguridad que enumeran están prevenir ataques de repetición y asegurar que las firmas cubran elementos como el valor de la transacción, el gas, el destino y los datos de llamada, para impedir que una autorización se reutilice con parámetros diferentes.

Una delegación mal implementada puede entregar a un atacante un control casi completo sobre la cuenta firmante, según los riesgos descritos en la especificación. Además, la delegación persiste más allá de la transacción que la instala, de modo que su efecto no necesariamente termina cuando se ejecuta la primera operación autorizada.

El diseño también señala que un fallo de ejecución no revierte las indicaciones de delegación que ya se procesaron. Para retirarla, el protocolo permite una autorización válida dirigida a la dirección cero, que elimina el código delegado de la cuenta. Esa posibilidad no sustituye la prevención y la revisión antes de firmar.

El caso, tal como lo presenta CyberSatoshi, deja una diferencia importante entre seguridad del protocolo y seguridad de la billetera: Ethereum exige una firma válida, mientras que el análisis no explica cómo un tercero habría obtenido acceso para producirla. La alerta de Hoskinson pone el foco en los riesgos del código delegado, pero los hechos disponibles no bastan para atribuir una vulnerabilidad concreta a EIP-7702 ni para confirmar todos los detalles operativos alegados.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados