Tres redes de cadena de bloques suspenden operaciones debido a incidentes de seguridad

Artículo escrito por Liam 'Akiba' Wright

Compilado por Saoirse, Foresight News

En cuatro días, tres redes blockchain se detuvieron sucesivamente. Cada interrupción de red utilizó permisos de emergencia completamente distintos, y solo Cronos modificó parte del historial oficial de la cadena.

Cronos indicó que, tras el ataque de vulnerabilidad al protocolo Tectonic, los nodos de validación detuvieron la red mediante el mecanismo de consenso, restauraron la cadena al estado anterior al ataque y reiniciaron la generación de bloques desde la altura de bloque 90,896,189. Esta operación no solo detuvo la generación de bloques, sino que también reescribió directamente el estado de la cadena. Todas las transacciones y cambios de estado generados después del punto de restauración ya no forman parte de la cadena principal oficial tras el reinicio.

Ontology e ICON implementaron otro conjunto de medidas de emergencia. Ontology suspendió la producción de bloques antes de confirmar el ataque malicioso; su actualización del 1 de septiembre indicó que esta actividad maliciosa no causó pérdidas de activos de los usuarios. ICON primero suspendió el contrato afectado y luego apagó toda la red; la fundación afirmó que, durante la fase de migración, tenía control sobre la red, y en ese momento la mayor parte de los ICX robados ya se habían transferido a cuentas de custodia en intercambios.

El cese de la blockchain es simplemente una medida de control de primer nivel. El problema más profundo es: ¿quiénes tienen autoridad para ordenar el cierre de la red? ¿Pueden reescribir el estado de la cadena ya confirmado? ¿Qué pérdidas serán irrecuperables cuando los fondos se transfieran entre cadenas o ingresen a instituciones centralizadas de custodia?

Se ha restaurado la información de permisos para las medidas de respuesta de emergencia a eventos desencadenados por red; se conoce el riesgo de recuperación tras el ataque de la vulnerabilidad CronosTectonic, que provocó el cierre de la red y la recuperación al estado de la cadena anterior a la vulnerabilidad mediante consenso de validadores; todos los eventos en cadena posteriores al punto de verificación de los datos de conteo de votos y el umbral de votación se anulan; los fondos transferidos a Ethereum no están bajo el control de Cronos; el cálculo final de pérdidas del protocolo Tectonic aún no se ha completado. Durante una inspección diaria, Ontology detectó un riesgo potencial, posteriormente confirmó actividad maliciosa y suspendió preventivamente la producción de bloques sin realizar rollback; el equipo de desarrollo central, el equipo técnico y los nodos validadores participaron; no se divulgaron los umbrales de activación para la respuesta de emergencia; durante la reparación y actualización de la red, las transacciones no pudieron ejecutarse; no se encontró daño en los activos de los usuarios. El contrato de migración de ICON presenta una vulnerabilidad de replay; se suspendió primero el contrato, luego se detuvo toda la red durante la migración, periodo en el que la red estuvo bajo control de la fundación, con una reducción en el número de nodos validadores centrales, cuyas pérdidas asume la fundación; la recuperación de ICX almacenado en intercambios depende del proveedor de custodia, los procesos legales y las autoridades encargadas de hacer cumplir la ley.

Comparación de los métodos de respuesta de emergencia para las cadenas públicas Cronos, Ontology e ICON

Cronos denominó esta respuesta al evento como "Acción de emergencia de consenso de validadores". El anuncio de reinicio del 31 de agosto indicó que, a las 23:49:01 UTC del 30 de agosto, la red recuperó la producción de bloques desde la altura de bloque 90,896,189, y el estado de la cadena retrocedió al momento anterior al ataque de la vulnerabilidad Tectonic.

La operación de apagado de Cronos implica tomar decisiones sobre la distribución de beneficios en puntos de recuperación. Después del punto de verificación, el estado en cadena relacionado con la vulnerabilidad, junto con todas las transacciones irrelevantes durante ese período, se eliminan de la cadena oficial. El anuncio de reinicio no incluyó una lista de transacciones, estadísticas de nodos de validación, umbrales de peso de votación ni una lista de nodos participantes. Cronos se comprometió a publicar un informe posterior al incidente que explique completamente el proceso de manejo y el alcance técnico del impacto.

Incluso la escala real de activos protegidos por esta intervención aún no está clara. TRM Labs estima que, tras la manipulación del precio del token TONIC, se prestaron aproximadamente 75 millones de dólares en activos; de ellos, unos 6 millones de dólares se dirigieron a Ethereum y aproximadamente 68,7 millones de dólares se recuperaron dentro de la cadena Cronos. Las estadísticas de Bitquery indican un volumen total de salida más alto: aproximadamente 8,3 millones de dólares en activos fluyeron hacia Ethereum, y un total de 10.961 bloques fueron descartados.

Los dos métodos de estadística tienen diferentes objetivos, y los datos finales de pérdidas de Tectonic aún no se han publicado. Pero un punto ya es muy claro: el rollback de Cronos solo puede restaurar el estado que aún permanece en esta cadena; los activos en la cadena de Ethereum están completamente fuera de su control.

El plan de disposición de activos de Tectonic aún deja pendientes problemas contables de los usuarios. El protocolo indica que se priorizará la apertura de funciones de retiro y reembolso de préstamos, mientras se suspenden los depósitos y nuevos préstamos. Este plan ofrece a los usuarios una vía para salir y reducir su apalancamiento, pero aún no se ha confirmado si los proveedores de fondos podrán rescatar completamente sus activos. El informe posterior a eventos que Tectonic aún debe publicar deberá aclarar el mecanismo de la vulnerabilidad, el monto total de fondos retirados, el volumen de deudas incobrables, los activos recuperados y las demás deudas pendientes.

Los progresos de recuperación de diversas infraestructuras no están sincronizados con la reanudación del consenso de la cadena. Cronos advierte que los diversos protocolos, puentes intercadena, exploradores de bloques y servicios RPC requerirán más tiempo para recuperarse. La página de estado de Alchemy también documenta por separado este incidente y su posterior recuperación. Aunque la red de la cadena puede declarar su reinicio oficial, los servicios que dependen de ella aún podrían no estar listos.

La acción de处置 de Ontology ocurrió antes de confirmar la actividad maliciosa. La red indicó que el equipo de desarrollo principal detectó durante una inspección diaria una posible vulnerabilidad de seguridad, suspendió inmediatamente la producción de bloques y entregó el sistema a un equipo técnico y nodos de validación para su revisión.

La actualización del 1 de septiembre indica que la revisión confirmó la presencia de un ataque malicioso; la red principal seguirá fuera de línea mientras se realizan la corrección de vulnerabilidades y la actualización de la red; el ataque no afectó los activos de los usuarios. Ontology tiene como objetivo restablecer el funcionamiento normal dentro de las próximas 24 horas, siempre que las pruebas de seguridad, la corrección de vulnerabilidades, la actualización y las pruebas se completen exitosamente.

El mantenimiento de Ontology conserva todos los estados en cadena confirmados, solo deteniendo la confirmación y liquidación de nuevas transacciones. El anuncio no especifica el punto de recuperación ni publica el conjunto de transacciones que deben anularse.

La información sobre los permisos divulgada públicamente no es completa. El anuncio menciona que el equipo de desarrollo principal, el equipo técnico y los nodos de validación de la red participaron en el manejo, pero no especifica quién es la persona con autoridad decisoria final ni proporciona un umbral de emergencia en formato numérico. El documento VBFT de Ontology describe el mecanismo de consenso habitual, incluyendo la generación de bloques confirmados por los nodos y la gestión del conjunto de nodos de consenso para actualizaciones de contratos, pero el documento solo cubre escenarios de funcionamiento normal; las reglas de suspensión de emergencia utilizadas el 31 de agosto no se han divulgado públicamente.

Aunque no se haya producido pérdida de activos, el tiempo de inactividad aún implica costos reales. Ontology informó a los usuarios que las transacciones en la cadena no podrán procesarse y sugirió no realizar operaciones sensibles al tiempo; posteriormente indicó que el reinicio de la red dependerá de la corrección de la vulnerabilidad, la actualización y las pruebas. Los usuarios no pueden ajustar sus posiciones ni realizar transferencias ni liquidaciones en la cadena, y todos los servicios externos conectados a esta red deben esperar la señal de la red.

Los criterios para determinar la recuperación del servicio están orientados a la seguridad, pero los detalles específicos son limitados. Ontology indica que, una vez completadas la reparación, la actualización, las pruebas y la validación, se esforzará por restablecer el servicio en 24 horas; sin embargo, no se ha revelado quién determinará si se han cumplido las condiciones ni cuáles son los umbrales de activación.

Esto genera incertidumbre en el nivel de gobernanza: el anuncio especifica las partes involucradas en la revisión, pero no identifica claramente a la entidad con la autoridad final para tomar la decisión de reanudar el servicio. Para los usuarios, el riesgo actual proviene de la interrupción del servicio, no de una pérdida de activos certificada ni de un rollback en la cadena.

El evento de ICON mostró completamente el proceso de alerta, respuesta y liberación de activos del control de la cadena.

Según el informe de revisión posterior al incidente de la fundación, el atacante repitió 1.492 veces dos mensajes de retiro firmados históricamente válidos entre el 27 de agosto a las 02:01:02 y las 02:21:12 UTC. Un defecto de precisión hizo que 1.490 de estas llamadas tuvieran éxito, transfiriendo 119.866.000 ICX y 531.600 bnUSD desde el fondo de activos de la fundación.

A las 02:08, el sistema de monitoreo emitió una alerta, y los técnicos iniciaron la investigación posteriormente; el contrato afectado se suspendió a las 03:53. Los principales intercambios comenzaron a desactivar los depósitos y retiros de ICX a las 05:54, y la interrupción total en la red entró en vigor oficialmente a las 06:18:54. ICON se reinició alrededor de las 07:51 del 28 de agosto, tras un intervalo de aproximadamente 25 horas, y se corrigió la vulnerabilidad subyacente.

El informe de revisión concluye que la causa raíz fue el proceso de respuesta al incidente, no una falta de capacidad de detección. La alerta se activó en menos de 7 minutos, pero este tipo de alertas a menudo se confunden con anomalías RPC irrelevantes, y el sistema no notificó al personal de guardia. La investigación técnica no comenzó hasta aproximadamente las 03:40, poco antes de que se suspendiera el contrato.

Cuando la cadena se desconecte oficialmente, la mayoría de los ICX afectados ya habrán sido incorporados por los intercambios a sus propios sistemas de custodia. Los controles de la cadena ICON no pueden impedir que los intercambios transfieran o conviertan los activos que poseen. La fundación solo puede contar con la congelación de activos por parte de los intercambios, notificaciones de conservación, abogados y autoridades ejecutivas para manejar la situación.

El límite de custodia determina directamente la asignación de pérdidas. ICON indica que todos los activos afectados pertenecen a la fundación, y los depósitos, saldos y posiciones de los usuarios comunes no se han visto afectados. El informe muestra que se han recuperado completamente 531.600 bnUSD y 1,366 millones de SODA; de los 113.634 USDC prestados, se han recuperado 82.430. La pérdida neta confirmada es de aproximadamente 150,2 ETH, además de 31.204 USDC. La mayoría de los ICX involucrados simplemente fueron congelados o rastreados en el intercambio, sin ser realmente recuperados.

La estructura de gestión de ICON también difiere de los otros dos casos. El informe de revisión indica que durante la migración de tokens, la red estuvo bajo el control de la fundación; el documento de instrucciones de migración menciona que el consenso funcionaba en modo de mantenimiento, con solo 7 nodos principales. Por lo tanto, este periodo de inactividad se basó en una arquitectura operativa especial claramente controlada por la fundación.

Cada interrupción de la blockchain es, en esencia, transferir el riesgo a otro lugar.

• Cronos modifica el historial de la cadena principal: puede proteger los activos que aún se encuentran bajo la jurisdicción de la cadena, pero invalida simultáneamente las actividades normales en la cadena fuera de la vulnerabilidad, y no puede hacer nada respecto a los activos en Ethereum.
• Ontology convierte el riesgo en costo de tiempo y pérdida de disponibilidad del servicio; durante la investigación, las operaciones no pudieron liquidarse y no se confirmó ninguna pérdida contable en los activos.
• ICON completó la separación del contrato y la red después de que los activos ya hubieran salido del alcance de la custodia en cadena; se confirma que la pérdida será asumida por la fundación, y la recuperación de los ICX congelados depende de los intercambios y las autoridades judiciales.

Una simple calificación descentralizada ocultará estos resultados tan distintos. Un criterio de evaluación más pragmático es: ¿son públicas las reglas de respuesta de emergencia? ¿Cuál es el umbral que activa la intervención? ¿Se detiene solo la creación de nuevos bloques, o se reescribe el estado de la cadena ya confirmado? ¿Quién controla los activos que se escapan de la jurisdicción de esta cadena cuando ocurre la intervención? ¿Quién se compromete a asumir las pérdidas restantes?

Cronos y Tectonic aún deben publicar el informe completo de revisión. Ontology debe divulgar los detalles del ataque y las reglas de autorización de emergencia, y posteriormente confirmar si se han cumplido las condiciones para la actualización y reinicio. Lo realmente comparable es el límite de riesgo establecido por cada red: qué historial, tiempo y fondos se exponen al riesgo.