El exploit del puente Ronin de USD 10 millones del 6 de agosto fue causado por un script de despliegue de actualización defectuoso, según un informe de la firma de seguridad de blockchain Verichains. 

La actualización redujo a cero el umbral de votación de los validadores, lo que esencialmente permitió a cualquier usuario retirar desde el puente «sin firma», declaró Verichains. 

El atacante intentó aprovecharse de este fallo para vaciar el puente, pero fue adelantado por un bot de MEV que llevó a cabo el ataque, probablemente sin proponérselo. El propietario del bot devolvió posteriormente la mayor parte de los fondos al equipo Ronin.

El análisis de Verichains deja al descubierto los riesgos que corren los usuarios cuando interactúan con contratos inteligentes actualizables. El protocolo podría haber perdido el importe íntegro si el atacante hubiera pagado más en gas y, por tanto, evitado al ganador.

Ronin es una red blockchain dedicada a alojar juegos Web3. Es más conocida por ser el hogar de Axie Infinity, un juego de cría de monstruos play-to-earn que afirmó tener más de 2 millones de jugadores durante su pico en 2022. Los jugadores del juego Ronin utilizan el puente para transferir fondos entre Ethereum y Ronin.

Según el informe de Verichain, el puente se basa en la variable mimimumVoteWeight para evitar que los usuarios retiren fondos que no les pertenecen. Cada transacción debe ser autorizada por un número mínimo de validadores fijado por esta variable.

Cuando se computa minimumVoteWeight, utiliza otra variable, totalWeight, como entrada.

TotalWeight en una versión anterior de Ronin. Fuente: Verichains

En versiones anteriores del puente, totalWeight existía en un contrato separado, llamado «MainchainBridgeManager». Cuando los desarrolladores crearon la nueva actualización, quisieron trasladar esta variable al propio almacenamiento interno del puente, en lugar de dejarla en el otro contrato. Esto significaba que necesitaban inicializar la variable en el momento del despliegue, estableciendo TotalWeight al valor que tenía en la versión anterior.

Por desgracia, aquí es donde la actualización salió terriblemente mal. Según Verichain, los desarrolladores de Ronin escribieron varias funciones de «inicialización» diferentes que debían ejecutarse en el momento del despliegue. Cada una de estas funciones tenía un número de versión diferente. La tercera versión contenía la crucial inicialización de totalWeight. Pero cuando los desarrolladores escribieron el script de despliegue, sólo llamaron a la versión 4, dejando totalWeight en su valor cero por defecto.

Fuente: Verichain

Tras esta actualización, los usuarios ya no necesitaban presentar firmas a los validadores para demostrar su derecho a retirar. Podían retirar «sin firma», ya que «cumplía la condición minimumVoteWeight (que era 0 por no estar inicializado)».

En un post publicado el 7 de agosto en X, el auditor de contratos inteligentes de Composable Security Damian Rusinek dio más detalles sobre lo que permitió que se produjera el ataque. Según Rusinek, el atacante proporcionó una firma desde una dirección que terminaba en B849f. Sin embargo, esta dirección «[no estaba] en la lista de operadores de puente». No necesitaba estar en la lista de operadores del puente porque «el mínimo de votos de los operadores era 0». Por lo tanto, «sólo se requería UNA firma y podía [ser] CUALQUIER firma válida».

Aunque no entraron en tantos detalles como Verichains o Rusinek, Ronin confirmó en un post de X del 6 de agosto que el exploit se produjo cuando la actualización «introdujo un problema que llevó al puente a malinterpretar el umbral de votos de los operadores de puente requerido para retirar fondos».

Los datos de blockchain muestran que esta transacción de ataque fue ejecutada por un bot MEV llamado «Frontrunner Yoink», que drenó con éxito más de USD 10 millones en criptomonedas del puente. Según Rusinek, lo más probable es que el bot «simulara el cambio de dirección e importe y utilizara su propia firma». A continuación, envió la transacción una vez que esta simulación demostró que el exploit funcionaría.

El propietario de Yoink devolvió la mayor parte de los fondos ese mismo día, y el equipo de Ronin anunció que se quedaría con USD 500,000 como recompensa por el fallo.

Los usuarios de Ronin sufrieron de cerca el ataque del 6 de agosto. Por suerte, el ataque fue dirigido por un bot MEV cuyo propietario era un operador honesto de sombrero blanco. Sin embargo, el hecho de que el ataque estuviera tan cerca de tener éxito pone de manifiesto la arriesgada naturaleza de los puentes actualizables entre cadenas.

Algunas redes afirman que este problema se eliminará cuando las capas 2 de Ethereum alcancen la «fase 2» y todas las actualizaciones se retrasen al menos siete días tras su inicio. Sin embargo, los críticos afirman que el proceso para alcanzar esta etapa está llevando demasiado tiempo y puede que nunca se complete.

Aclaración: La información y/u opiniones emitidas en este artículo no representan necesariamente los puntos de vista o la línea editorial de Cointelegraph. La información aquí expuesta no debe ser tomada como consejo financiero o recomendación de inversión. Toda inversión y movimiento comercial implican riesgos y es responsabilidad de cada persona hacer su debida investigación antes de tomar una decisión de inversión.