Ronin Network - Rekt II

El puente de Ronin Network sufrió un exploit por aproximadamente $12 millones de dólares, debido a un descuido crítico en una actualización de contrato.

Para la comunidad de Axie Infinity y los usuarios de Ronin Network, las palabras "exploit de puente" probablemente desencadenen PTSD.

Después del monumental hackeo de $624 millones de dólares en marzo de 2022, muchos esperaban que esos días hubieran quedado atrás.

Pero el 6 de agosto, esas viejas heridas fueron reabiertas cuando Ronin enfrentó otro ataque.

Esta vez, el daño fue significativamente menor, pero el impacto psicológico resuena profundamente.

Es como si el mundo cripto estuviera viendo la secuela de una película de terror, preguntándose si el protagonista ha aprendido de los errores pasados o si está condenado a repetirlos.

Mientras Ronin tropieza una vez más, nos quedamos preguntándonos, ¿cuántas llamadas de atención necesita un proyecto antes de dominar finalmente los conceptos básicos de seguridad operativa?

Créditos: Chaofan Shou, Ronin Network, Verichains

Justo cuando pensabas que era seguro cruzar el puente de Ronin nuevamente, la historia se repite de una manera más pequeña, pero igualmente alarmante.

El 6 de agosto, Ronin Network, todavía sosteniendo el título del mayor hackeo en la historia cripto, se tropezó con otro exploit.

Esta vez, el daño fue de $12 millones de dólares, muy lejos del robo de $624 millones de dólares en 2022, pero no menos vergonzoso para un proyecto que debería haber aprendido la lección.

Es como si el equipo de Ronin hubiera decidido reiniciar su franquicia de terror con una secuela de bajo presupuesto que nadie pidió.

Como dice el refrán, "Engáñame una vez, vergüenza para ti. Engáñame dos veces, vergüenza para mí."

Pero, ¿qué decimos cuando un proyecto es engañado dos veces por descuidos similares?

Quizás sea hora de un nuevo refrán: "Si me hackean una vez, vergüenza para el atacante. Si me hackean dos veces, vergüenza para mi seguridad operativa."

Como un Paul Revere digital, Chaofan Shou fue el primero en dar la voz de alarma en X, alertando a todos que, una vez más, el puente Ronin estaba bajo ataque.

A diferencia de su anterior reacción (con seis días de retraso), esta vez Ronin fue un poco más rápido en reaccionar.

Psycheout.ron, COO de Ronin, respondió poco después del exploit fue detectado.

"El puente de Ronin Network ha sido pausado mientras investigamos un informe de algunos white-hats sobre una posible exploit MEV. El puente actualmente asegura más de $850 millones de dólares, que están seguros."

Aproximadamente tres horas después, la cuenta oficial de Ronin Network confirmó el exploit, afirmando que los white-hats les habían alertado y el puente fue pausado 40 minutos después de que se detectara la primera acción en la cadena.

Revelaron que los atacantes habían retirado justo menos de 4K ETH y 2M USDC, valorados en alrededor de $12 millones de dólares, que era el límite máximo de retiro en una sola transacción, una medida de seguridad que evitó más daños.

Como en muchos hackeos de cripto, el diablo estaba en los detalles, o en este caso, en el proceso de actualización.

Verichains destacó la causa raíz de este exploit, un fallo al inicializar adecuadamente un parámetro crítico durante una actualización de contrato. A continuación se detalla cómo se desarrolló.

La Actualización Fatal: El 6 de agosto, el equipo de Ronin implementó una actualización en su administrador de puente, pasando de la versión 2 a la 4.

Esta actualización introdujo un nuevo contrato de implementación, MainchainGatewayV3, que se desplegó apenas 6 días antes.

El hub de actualizaciones de Ronin muestra los cambios en esta nueva implementación, incluyendo modificaciones en cómo el contrato maneja los pesos de los operadores y las presentaciones de retiro.

El Descuido Crítico: En su prisa, llamaron a la función initializeV4 pero olvidaron llamar a initializeV3. Este descuido aparentemente menor resultaría costoso.

La Consecuencia No Intencionada: La variable _totalOperatorWeight quedó sin inicializar, default a cero. Esto significaba que el parámetro minimumVoteWeight, crucial para la verificación entre cadenas, estaba efectivamente desactivado.

El Exploit: Con las comprobaciones de seguridad efectivamente desactivadas, la vulnerabilidad estaba lista para ser explotada. Un bot MEV identificó la vulnerabilidad y se adelantó a cualquier intento de explotación manual, ejecutando el ataque y dirigiendo los fondos a su propia dirección.

El Control de Daños: Gracias a un límite de retiro diario, se salvaron otros $72 millones de dólares de ser robados. El equipo de Ronin logró pausar el contrato unos 38 minutos después de que comenzara el exploit.

En un giro sorprendente de los acontecimientos, los fondos robados fueron devueltos rápidamente, gracias a los white-hats MEV ultrarrápidos que superaron a los posibles actores maliciosos.

El ETH, valorado en aproximadamente $10 millones de dólares, fue enviado rápidamente de vuelta al equipo de Ronin.

El USDC restante fue devuelto poco después.

En reconocimiento a su vigilancia e integridad, el equipo de Ronin anunció una recompensa de $500,000 para los hackers white-hats involucrados.

Ronin también declaró que el puente se someterá a una auditoría antes de reabrirse, con Ronin apuntando a cambiar su operación alejándose de la estructura actual.

Se programó una revisión post-mortem para la próxima semana, prometiendo informes más profundos sobre los detalles técnicos y las medidas preventivas planeadas.

Este incidente destaca la espada de doble filo de los contratos actualizables y la importancia crítica de una implementación meticulosa.

El descuido de Ronin convirtió una actualización rutinaria en una lección de humildad de $12 millones de dólares.

¿Cuántas llamadas de atención más puede sobrevivir un proyecto antes de que los usuarios decidan que es hora de cruzar un puente diferente?

A pesar de su tiempo de respuesta mejorado, el fracaso de Ronin para implementar y probar adecuadamente su última actualización revela un proyecto aún tropezando con las prácticas básicas de seguridad.

Evitaron una bala gracias a la intervención fortuita de los white-hats MEV, pero la suerte no es una estrategia de seguridad sostenible.

Para un proyecto que ya ha sufrido el mayor hackeo en la historia cripto, este casi desastre debería ser una última llamada de atención.

Es hora de priorizar medidas de seguridad rigurosas sobre actualizaciones apresuradas.

De cara al futuro, Ronin y, de hecho, todos los proyectos blockchain deberían hacer lo siguiente:

• Siempre implementar pruebas exhaustivas para actualizaciones de contratos.

• Colaborar con auditores para verificar la correcta implementación.

• Tener cuidado con el contrato “Initializable” de OpenZeppelin, entendiendo sus posibles inconvenientes.

Ronin Network se tambalea precariamente entre la redención y la infamia.

En un ecosistema donde la reputación es tan volátil como los activos que asegura, ¿cuántos casi desastres puede sobrevivir un proyecto antes de que los usuarios decidan buscar aguas más seguras?

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.