Cetus Protocol Liquidity Provider Contract Overflow Vulnerability

On May 22, according to community news, the liquidity provider Cetus on the SUI ecosystem was suspected of being attacked

A liquidity provider, Cetus, on the SUI ecosystem was suspected to be undergoing a significant liquidity depth reduction, and multiple token trading pairs on Cetus experienced declines, with expected losses exceeding $230 million.

Cetus was founded in March 2024 by experienced blockchain developers and researchers. The protocol aims to build a decentralized exchange that is fast, efficient, and user-friendly. Cetus provides liquidity provider services for the SUI ecosystem and supports various token trading pairs, such as haSUI/SUI, vSUI/SUI, and USDC/SUI.

After the incident occurred, the SlowMist security team intervened for analysis and issued a security alert. Below is a detailed analysis of the attack method and fund transfer situation.

The core of this incident is that the attacker carefully constructed parameters to cause overflow while bypassing detection, ultimately allowing a very small token amount to exchange for massive liquidity assets.

The attacker first borrowed 10,024,321.28 haSUI through a flash loan, causing the pool price to plummet from 18,956,530,795,606,879,104 to 18,425,720,184762886, with a price drop of 99.90%.

The attacker carefully selected an extremely narrow price range to open a liquidity position:

Tick lower limit: 300000 (Price: 60,257,519,765,924,248,467,716,150)

Tick upper limit: 300200 (Price: 60,863,087,478,126,617,965,993,239)

Price range width: only 1.00496621%

Next is the core of this attack, where the attacker claimed to add a massive liquidity of 10,365,647,984,364,446,732,462,244,378,333,008 but due to the vulnerability, the system only accepted 1 token A.

Let's analyze why the attacker could exchange a massive liquidity with just 1 token. The core reason lies in the overflow detection bypass vulnerability in the checked_shlw function in the get_delta_a function. The attacker exploited this, causing the system to miscalculate the actual amount of haSUI needed to add. Due to the overflow not being detected, the system misjudged the required amount of haSUI, allowing the attacker to exchange only a very small number of tokens for a large amount of liquidity assets, thus executing the attack.

When the system calculates how much haSUI is needed to add such massive liquidity:

The key here is that there is a serious flaw in the implementation of the checked_shlw function. In fact, any input value less than 0xffffffffffffffff << 192 will bypass overflow detection. However, when these values are left-shifted by 64 bits, the result exceeds the representable range of u256, causing the high-order data to be truncated, resulting in a obtained value much smaller than the theoretical value. As a result, the system will underestimate the required amount of haSUI in subsequent calculations.

Error mask: 0xffffffffffffffff << 192 = a very large value (about 2^256 - 2^192)

Almost all inputs are less than this mask, bypassing overflow detection

The real problem: when n >= 2^192, n << 64 exceeds the u256 range and gets truncated

The intermediate value constructed by the attacker liquidity * sqrt_price_diff = 6277101735386680763835789423207666908085499738337898853712:

Less than the erroneous mask, bypassing overflow detection

But after left-shifting 64 bits, it exceeds the maximum value of u256, causing the overflow part to be truncated

This leads to a final calculation result of approximately less than 1, but since it is rounded up, the quotient is calculated to equal 1

Finally, the attacker removed liquidity and obtained massive token profits:

First removal: Obtained 10,024,321.28 haSUI