El 22 de mayo de 2025, un importante ataque tuvo como objetivo el Protocolo Cetus en la cadena de bloques Sui, lo que provocó daños estimados en 223 millones de dólares. Este incidente atrajo la atención inmediata de todo el ecosistema, especialmente de parte de los observadores técnicos, debido a la inusual mecánica que implicaba. Lo que sigue es un análisis exhaustivo del ataque, desde el intercambio flash y la manipulación de marcas hasta una vulnerabilidad silenciosa en la lógica de detección de desbordamientos.

https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x

La configuración

El atacante inició el exploit utilizando flash_swap para pedir prestada una gran cantidad de tokens SUI a cambio de HaSui. A diferencia de los flashloans tradicionales, flash_swap en Cetus permite al usuario recibir el token1 (SUI en este caso) por adelantado y luego reembolsar el token0 (HaSui) en la misma transacción. Este mecanismo es fundamental para la configuración del atacante.

En este caso concreto, el atacante adquirió con éxito 5,76 millones de SUI y se vio obligado a reembolsar 10,02 millones de HaSui. Sin embargo, durante esta permuta, el precio de HaSui en el fondo de liquidez se manipuló drásticamente. El precio del pool bajó de un tic, que representaba una ratio de 1,056, a un precio tan bajo que el precio alcanzó tan solo el 0,0000009977, lo que supuso una enorme devaluación hasta el 0,00009% de su precio original.

El rango de precios correspondiente al rango de garrapatas es:

Inyección estratégica de liquidez

Tras esta caída de precios, el atacante utilizó open_position para crear una posición de liquidez de rango estrecho y eligió un rango de cotización muy específico (TickLower: 300000, TickUpper: 300200). En este entorno manipulado, inyectaron una cantidad astronómica de liquidez: más de 10^34 unidades, todo ello dentro del rango de precios ultracomprimido creado por la caída del tic-tic.

Esto fue posible gracias a una función aparentemente inocua: get_amount_by_liquidity. En condiciones normales, esta función calcula la cantidad de token A y B que se necesita para alcanzar un determinado nivel de liquidez. Para ello, utiliza funciones auxiliares como get_delta_a, que se basa en get_sqrt_price_at_tick.

Sin embargo, dado que el tic actual manipulado es -138185 y que el rango de ticks elegido está muy por encima de ese valor (empezando en 300 000), la ruta lógica dentro de get_amount_by_liquidity garantizaba que los cálculos pasaran por una sección vulnerable del código en la que se realizaba una operación de desplazamiento a la izquierda (checked_shlw).

Desbordamiento y truncamiento: la principal vulnerabilidad

Aquí es donde el exploit se vuelve verdaderamente técnico. Se supone que la función checked_shlw permite desplazar a la izquierda un número de 256 bits por 64 bits. En entornos similares a Solidity, una operación de este tipo es arriesgada, ya que puede desbordarse. Esta implementación en particular intentó detectar los desbordamientos comprobando si la entrada superaba un umbral predefinido: 0xffffffffffffffffff << 192.

El umbral real para detectar un cambio seguro en 64 bits debería ser 2^ (256 - 64) - 1. Sin embargo, (0xffffffffffffffff << 192) es mayor que 2^192. Esto significa que una entrada elegida con cuidado podría eludir la comprobación de desbordamiento al estar por debajo del umbral utilizado en el código, pero seguir siendo lo suficientemente grande como para provocar un desbordamiento durante la ejecución.

El atacante proporcionó una entrada de este tipo, en la que la multiplicación de la liquidez y la diferencia de precio se desbordó silenciosamente, lo que arrojó un valor mucho menor al previsto (de hecho, casi cero).

Como resultado, el protocolo calculó que el atacante solo tenía que pagar una cantidad insignificante de fichas (básicamente una unidad) para añadir una enorme liquidez a la reserva. Este error de cálculo permitió al atacante inyectar una enorme liquidez sin coste real.

Posteriormente, el atacante eliminó la liquidez añadida a través de remove_liquidity y completó el ataque pagando las fichas impagadas de flash_swap a través de repay_flash_swap. El atacante obtuvo un beneficio de 5.765.124 SUI y 10.024.321 HaSUI. Finalmente, el equipo de Cetus solucionó la vulnerabilidad mediante dos RP:

https://github.com/CetusProtocol/integer-mate/pull/6/files

Cetus publicó rápidamente un parche en su repositorio de números enteros, y la primera solicitud de extracción intentaba refinar la detección de desbordamientos. Sin embargo, esa solución inicial era inadecuada. Utilizaba una máscara de 1 << 192, que aun así permitía que los valores en mayúsculas y minúsculas pasaran desapercibidos.

Se realizó una segunda solicitud de extracción seguida de una comparación más estricta, en la que se comprobaba que la entrada era mayor o igual a 2^192, lo que garantizaba unos límites adecuados para desplazar a la izquierda de forma segura. Solo con esta corrección se mitigó la vulnerabilidad de manera efectiva.

https://github.com/CetusProtocol/integer-mate/pull/7/files