El 22 de mayo de 2025, Cetus sufrió un ataque complicado de contratos inteligentes dirigido a la piscina CLMM. Hemos tomado medidas inmediatas para mitigar el impacto, este informe tiene como objetivo revelar de manera transparente la línea de tiempo del evento, el análisis de la causa raíz, el estado de los fondos y los planes futuros, y avanzar conjuntamente en los asuntos posteriores.
Línea de tiempo del evento
UTC tiempo 10:30:50 – El ataque se inició a través de transacciones anómalas.
UTC tiempo 10:40:00 - El sistema de monitoreo detectó un comportamiento anormal en el fondo de inversión.
UTC 10:53:00 - El equipo de Cetus identifica la fuente del ataque y emite una alerta a los miembros del ecosistema Sui.
UTC tiempo 10:57:47 – El núcleo del pool CLMM ha sido desactivado para evitar la expansión de pérdidas.
UTC tiempo 11:20:00 – Todos los contratos inteligentes relacionados fueron desactivados globalmente.
UTC tiempo 12:50:00 - Los validadores de Sui comienzan a votar para rechazar las transacciones firmadas por la dirección del atacante; cuando la participación de la votación supera el umbral del 33%, los validadores efectivamente "congelan" estas direcciones.
UTC hora 18:04:07 - Enviar mensaje de negociación en cadena al atacante.
UTC tiempo 18:15:28 - El contrato de falla ha sido reparado y actualizado (aún no reiniciado).
Análisis de Ataques
Los atacantes aprovecharon una vulnerabilidad en la biblioteca de código abierto inter\_mate del contrato CLMM. El flujo del ataque es el siguiente:
a. El atacante inicia un intercambio relámpago (flash_swap) para reducir temporalmente el precio en el fondo.
b. Abrir posiciones en un rango de precios más alto.
c. Aprovechar la verificación de desbordamiento incorrecta en la lógica de agregar liquidez (add\_liquidity) para inyectar un valor de liquidez inflado con muy pocos tokens.
d. A través de la eliminación de liquidez en múltiples rondas (remove_liquidity) se drenan las reservas de tokens.
e. Utilizando cálculos no verificados (como overflowing\_sub, get\_liquidity\_from\_a), repetir el proceso anterior a través de valores de liquidez cuidadosamente construidos.
Esta vulnerabilidad no fue detectada en auditorías de seguridad anteriores.
Causa raíz
La vulnerabilidad se deriva de un malentendido de la semántica de las operaciones de desplazamiento a la izquierda en la biblioteca de código abierto 'integer-mate', de la que depende el contrato CLMM. En su método 'checked_shlw', la verificación real debería ser "si el valor de entrada es ≤2^192", pero en la versión atacada, se detectó incorrectamente como "≤2^256", lo que provocó que la verificación de desbordamiento fallara. Esta es la única razón real del reciente ataque.
Los atacantes aprovecharon la vulnerabilidad mencionada, manipulando la escala de precios (tick) del fondo de liquidez y el mecanismo de liquidez, logrando extraer una gran cantidad de activos en múltiples ciclos de ataque.
Para aclarar, algunas personas en las redes sociales creyeron erróneamente recientemente que el ataque se originó por el "error de verificación aritmética MAX_U64" señalado en el informe de auditoría anterior, lo que engañó a muchos usuarios que no sabían la verdad. Nos gustaría declarar que este problema no está relacionado con este ataque. Este problema en sí mismo es solo una sugerencia de optimización informativa que solo hace que la transacción se revierta en casos extremos, y la corrección de optimización se ha completado en versiones anteriores.
Para proteger los intereses comunes de todo el ecosistema, con el apoyo de la mayoría de los validadores de Sui, se han congelado de forma urgente las dos direcciones de billetera Sui del atacante. Las billeteras congeladas contienen la mayor parte de los fondos robados:
Atacante Sui billetera 1 (congelada): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Atacante Sui Wallet 2 (congelado): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Los fondos robados restantes han sido completamente canjeados y puenteados a ETH por el atacante, y actualmente se encuentran en las siguientes dos billeteras de Ethereum:
Cartera de Ethereum del atacante 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Cartera de Ethereum del atacante 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Planes futuros
Revisión de contratos y fortalecimiento de la seguridad
Estamos colaborando con el equipo de seguridad de Sui y varios socios de auditoría para revisar nuevamente el contrato actualizado y llevar a cabo una auditoría conjunta. Solo después de una verificación completa se reactivarán gradualmente el CLMM y los servicios relacionados.
Planeamos iniciar auditorías adicionales de inmediato y publicar informes de auditoría periódicos basados en el TVL (valor total bloqueado). Al mismo tiempo, se continuará reforzando la supervisión en cadena, optimizando la configuración de gestión de riesgos y aplicando restricciones de velocidad controladas a la liquidez de los activos.
Recuperación de Activos LP
Estamos trabajando activamente en colaboración con socios clave del ecosistema para diseñar planes de recuperación para los pools de liquidez y LP afectados, con el objetivo de restaurar lo antes posible la funcionalidad de extracción de liquidez y todos los servicios de los pools afectados.
Para lograr el objetivo final de recuperar la totalidad de las pérdidas de los usuarios, hacemos un llamado sincero a todos los validadores de Sui para que apoyen la votación en cadena que hemos iniciado recientemente. Esta votación permitirá a los usuarios recuperar rápidamente la mayor parte de sus activos. Con tu apoyo, avanzaremos lo antes posible en el proceso de compensación por las pérdidas de los usuarios y en la reconstrucción de la confianza en la comunidad.
Trabajo legal y de negociación
Mientras se avanza en los procedimientos legales y de aplicación de la ley, también ofrecemos a los atacantes la oportunidad de convertirse en hackers éticos. Se enviará un aviso final a los atacantes en breve, y todos los avances se divulgarán de manera transparente a la comunidad.
Conclusión
Agradecemos sinceramente a los usuarios, a la Fundación Sui y a los socios ecológicos por su rápida respuesta y gran apoyo, lo que nos ha permitido congelar rápidamente más de 160 millones de dólares en fondos y transmitir información clave a las partes afectadas. Al mismo tiempo, somos conscientes de que la recuperación total aún requiere tiempo y estamos tomando medidas activamente para acelerar el proceso.
Desde sus inicios, Cetus ha sido uno de los equipos DeFi que más ha invertido en auditoría de contratos inteligentes y protección del sistema en la Sui Chain. Sin embargo, la realidad no es tan buena como debería ser: los contratos subyacentes y las bibliotecas de código abierto en las que se basan han pasado por múltiples rondas de auditorías y son ampliamente utilizados por los desarrolladores de ecosistemas, lo que nos hace creer erróneamente que son lo suficientemente seguros. En retrospectiva, no estuvimos lo suficientemente atentos. Esta dura lección nos ha enseñado que hay que hacer más.
En el futuro, fortaleceremos el sistema de seguridad y el control de riesgos a través de las siguientes medidas:
Implementar monitoreo en tiempo real utilizando herramientas como Blockaid para detectar y responder a amenazas y vulnerabilidades de manera oportuna.
Optimizar la asignación de gestión de riesgos, implementar límites de velocidad controlables sobre la liquidez de los activos.
Mejorar la cobertura de pruebas del código fuente del contrato inteligente
Indicadores de cobertura de código públicos
Realizar auditorías antes del lanzamiento oficial, después de cambios importantes en el código y al alcanzar hitos clave de TVL.
Actualización del programa de recompensas por vulnerabilidades de sombrero blanco, recompensas generosas por informes de vulnerabilidades valiosas
Las múltiples medidas mencionadas ya están en implementación y continuaremos profundizándolas.
Además, nos damos cuenta de que proteger los protocolos DeFi no puede depender únicamente de los esfuerzos del equipo y de los auditores, se necesita la fuerza de todo el ecosistema: desde desarrolladores hasta contribuyentes activos de sombrero blanco, para monitorear, defender y mejorar juntos. Esperamos reunir todas las fuerzas disponibles para construir una infraestructura sostenible y resiliente para todo el ecosistema, que soporte la prueba del tiempo.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Informe de incidente de robo de Cetus: se divulga la línea de tiempo y los detalles del ataque
Fuente: Cetus; Compilado por: AIMan@Gold Finance
El 22 de mayo de 2025, Cetus sufrió un ataque complicado de contratos inteligentes dirigido a la piscina CLMM. Hemos tomado medidas inmediatas para mitigar el impacto, este informe tiene como objetivo revelar de manera transparente la línea de tiempo del evento, el análisis de la causa raíz, el estado de los fondos y los planes futuros, y avanzar conjuntamente en los asuntos posteriores.
Línea de tiempo del evento
UTC tiempo 10:30:50 – El ataque se inició a través de transacciones anómalas.
UTC tiempo 10:40:00 - El sistema de monitoreo detectó un comportamiento anormal en el fondo de inversión.
UTC 10:53:00 - El equipo de Cetus identifica la fuente del ataque y emite una alerta a los miembros del ecosistema Sui.
UTC tiempo 10:57:47 – El núcleo del pool CLMM ha sido desactivado para evitar la expansión de pérdidas.
UTC tiempo 11:20:00 – Todos los contratos inteligentes relacionados fueron desactivados globalmente.
UTC tiempo 12:50:00 - Los validadores de Sui comienzan a votar para rechazar las transacciones firmadas por la dirección del atacante; cuando la participación de la votación supera el umbral del 33%, los validadores efectivamente "congelan" estas direcciones.
UTC hora 18:04:07 - Enviar mensaje de negociación en cadena al atacante.
UTC tiempo 18:15:28 - El contrato de falla ha sido reparado y actualizado (aún no reiniciado).
Análisis de Ataques
Los atacantes aprovecharon una vulnerabilidad en la biblioteca de código abierto
inter\_matedel contrato CLMM. El flujo del ataque es el siguiente:a. El atacante inicia un intercambio relámpago (flash_swap) para reducir temporalmente el precio en el fondo.
b. Abrir posiciones en un rango de precios más alto.
c. Aprovechar la verificación de desbordamiento incorrecta en la lógica de
agregar liquidez (add\_liquidity)para inyectar un valor de liquidez inflado con muy pocos tokens.d. A través de la eliminación de liquidez en múltiples rondas (remove_liquidity) se drenan las reservas de tokens.
e. Utilizando cálculos no verificados (como
overflowing\_sub,get\_liquidity\_from\_a), repetir el proceso anterior a través de valores de liquidez cuidadosamente construidos.Esta vulnerabilidad no fue detectada en auditorías de seguridad anteriores.
Causa raíz
La vulnerabilidad se deriva de un malentendido de la semántica de las operaciones de desplazamiento a la izquierda en la biblioteca de código abierto 'integer-mate', de la que depende el contrato CLMM. En su método 'checked_shlw', la verificación real debería ser "si el valor de entrada es ≤2^192", pero en la versión atacada, se detectó incorrectamente como "≤2^256", lo que provocó que la verificación de desbordamiento fallara. Esta es la única razón real del reciente ataque.
Los atacantes aprovecharon la vulnerabilidad mencionada, manipulando la escala de precios (tick) del fondo de liquidez y el mecanismo de liquidez, logrando extraer una gran cantidad de activos en múltiples ciclos de ataque.
Para aclarar, algunas personas en las redes sociales creyeron erróneamente recientemente que el ataque se originó por el "error de verificación aritmética MAX_U64" señalado en el informe de auditoría anterior, lo que engañó a muchos usuarios que no sabían la verdad. Nos gustaría declarar que este problema no está relacionado con este ataque. Este problema en sí mismo es solo una sugerencia de optimización informativa que solo hace que la transacción se revierta en casos extremos, y la corrección de optimización se ha completado en versiones anteriores.
Dirección del atacante (en la cadena Sui):
0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Estado de los fondos
Para proteger los intereses comunes de todo el ecosistema, con el apoyo de la mayoría de los validadores de Sui, se han congelado de forma urgente las dos direcciones de billetera Sui del atacante. Las billeteras congeladas contienen la mayor parte de los fondos robados:
Atacante Sui billetera 1 (congelada): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Atacante Sui Wallet 2 (congelado): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Los fondos robados restantes han sido completamente canjeados y puenteados a ETH por el atacante, y actualmente se encuentran en las siguientes dos billeteras de Ethereum:
Cartera de Ethereum del atacante 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Cartera de Ethereum del atacante 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Planes futuros
Revisión de contratos y fortalecimiento de la seguridad
Estamos colaborando con el equipo de seguridad de Sui y varios socios de auditoría para revisar nuevamente el contrato actualizado y llevar a cabo una auditoría conjunta. Solo después de una verificación completa se reactivarán gradualmente el CLMM y los servicios relacionados.
Planeamos iniciar auditorías adicionales de inmediato y publicar informes de auditoría periódicos basados en el TVL (valor total bloqueado). Al mismo tiempo, se continuará reforzando la supervisión en cadena, optimizando la configuración de gestión de riesgos y aplicando restricciones de velocidad controladas a la liquidez de los activos.
Recuperación de Activos LP
Estamos trabajando activamente en colaboración con socios clave del ecosistema para diseñar planes de recuperación para los pools de liquidez y LP afectados, con el objetivo de restaurar lo antes posible la funcionalidad de extracción de liquidez y todos los servicios de los pools afectados.
Para lograr el objetivo final de recuperar la totalidad de las pérdidas de los usuarios, hacemos un llamado sincero a todos los validadores de Sui para que apoyen la votación en cadena que hemos iniciado recientemente. Esta votación permitirá a los usuarios recuperar rápidamente la mayor parte de sus activos. Con tu apoyo, avanzaremos lo antes posible en el proceso de compensación por las pérdidas de los usuarios y en la reconstrucción de la confianza en la comunidad.
Trabajo legal y de negociación
Mientras se avanza en los procedimientos legales y de aplicación de la ley, también ofrecemos a los atacantes la oportunidad de convertirse en hackers éticos. Se enviará un aviso final a los atacantes en breve, y todos los avances se divulgarán de manera transparente a la comunidad.
Conclusión
Agradecemos sinceramente a los usuarios, a la Fundación Sui y a los socios ecológicos por su rápida respuesta y gran apoyo, lo que nos ha permitido congelar rápidamente más de 160 millones de dólares en fondos y transmitir información clave a las partes afectadas. Al mismo tiempo, somos conscientes de que la recuperación total aún requiere tiempo y estamos tomando medidas activamente para acelerar el proceso.
Desde sus inicios, Cetus ha sido uno de los equipos DeFi que más ha invertido en auditoría de contratos inteligentes y protección del sistema en la Sui Chain. Sin embargo, la realidad no es tan buena como debería ser: los contratos subyacentes y las bibliotecas de código abierto en las que se basan han pasado por múltiples rondas de auditorías y son ampliamente utilizados por los desarrolladores de ecosistemas, lo que nos hace creer erróneamente que son lo suficientemente seguros. En retrospectiva, no estuvimos lo suficientemente atentos. Esta dura lección nos ha enseñado que hay que hacer más.
En el futuro, fortaleceremos el sistema de seguridad y el control de riesgos a través de las siguientes medidas:
Implementar monitoreo en tiempo real utilizando herramientas como Blockaid para detectar y responder a amenazas y vulnerabilidades de manera oportuna.
Optimizar la asignación de gestión de riesgos, implementar límites de velocidad controlables sobre la liquidez de los activos.
Mejorar la cobertura de pruebas del código fuente del contrato inteligente
Indicadores de cobertura de código públicos
Realizar auditorías antes del lanzamiento oficial, después de cambios importantes en el código y al alcanzar hitos clave de TVL.
Actualización del programa de recompensas por vulnerabilidades de sombrero blanco, recompensas generosas por informes de vulnerabilidades valiosas
Las múltiples medidas mencionadas ya están en implementación y continuaremos profundizándolas.
Además, nos damos cuenta de que proteger los protocolos DeFi no puede depender únicamente de los esfuerzos del equipo y de los auditores, se necesita la fuerza de todo el ecosistema: desde desarrolladores hasta contribuyentes activos de sombrero blanco, para monitorear, defender y mejorar juntos. Esperamos reunir todas las fuerzas disponibles para construir una infraestructura sostenible y resiliente para todo el ecosistema, que soporte la prueba del tiempo.