Background
On May 22, according to community information, Cetus, a liquidity provider on the Sui ecosystem, was allegedly attacked, with a significant drop in liquidity pool depth, and multiple token trading pairs on Cetus experiencing a decline, with an estimated loss exceeding $230 million. Subsequently, Cetus released an announcement stating: "We have detected an incident in our protocol, and for safety reasons, the smart contract has been temporarily suspended. Currently, the team is investigating the event. We will soon publish a further investigation announcement."
After the incident, the BlockTempo security team immediately intervened for analysis and issued a security alert. Below is a detailed analysis of the attack method and fund transfer situation.
(https://x.com/CetusProtocol/status/1925515662346404024)
Related Information
One of the attack transactions:
https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x
Attacker's address:
0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Attacked pool address:
0x871d8a227114f375170f149f7e9d45be822dd003eba225e83c05ac80828596bc
Involved tokens:
haSUI / SUI
Attack Analysis
The core of this incident is that the attacker carefully constructed parameters to cause an overflow while bypassing detection, ultimately using an extremely small Token amount to exchange for massive liquidity assets. Here is a detailed step-by-step analysis:
(Attack Sequence Diagram)
1. The attacker first borrowed 10,024,321.28 haSUI through a flash loan, causing the pool price to drop from 18,956,530,795,606,879,104 to 18,425,720,184762886, a price drop of 99.90%.
2. The attacker carefully chose 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%
3. Then comes the core of this attack, where the attacker declared to add 10,365,647,984,364,446,732,462,244,378,333,008 units of huge liquidity, but due to a vulnerability, the system only collected 1 token A.
Let's analyze why the attacker could exchange massive liquidity with 1 Token. The core reason lies in the overflow detection bypass vulnerability in the get_delta_a function's checked_shlw. The attacker precisely exploited this point, causing the system to severely deviate when calculating how much haSUI actually needs to be added. Due to the undetected overflow, the system misjudged the required amount of haSUI, allowing the attacker to exchange massive liquidity assets with very few Tokens, thus achieving the attack.
When the system calculates how much haSUI is needed to add such huge liquidity:
The key lies in the serious flaw in the implementation of the checked_shlw function. In fact, any input value less than 0xffffffffffffffff << 192 would bypass overflow detection. However, when these values are left-shifted by 64 bits, the result exceeds the u256 representation range, causing the high-order data to be truncated, resulting in a value far smaller than the theoretical value. This causes the system to underestimate the required amount of haSUI in subsequent calculations.
- Error mask: 0xffffffffffffffff << 192 = Very large value (approximately 2^256-2^192)
- Almost all inputs are smaller than this mask, bypassing overflow detection
- The real problem: When n >= 2^192, n << 64 will exceed u256 range and be truncated
The intermediate value constructed by the attacker liquidity * sqrt_price_diff = 6277101735386680763835789423207666908085499738337898853712:
- Smaller than the error mask, bypassing overflow detection
- But when left-shifted by 64 bits, it will exceed the u256 maximum value, causing the excess part to be truncated
- Resulting in a final calculation result approximately less than 1, but due to rounding up, the quotient is calculated as 1
4. Finally, the attacker removed liquidity to obtain massive token profits:
First removal: Obtained 10,024,321.28 haSUI
Second removal: Obtained 1 haSUI
Third removal: Obtained 10,024,321.28 haSUI
5. The attacker returned the flash loan, with a net profit of approximately 10,024,321.28 haSUI and 5,765,124.79 SUI, completing the attack.
Project Team's Repair Situation
After the attack, Cetus released a repair update. The specific repair code can be referenced at: https://github.com/CetusProtocol/integer-mate/pull/7/files#diff-c04eb6ebebbabb80342cd953bc63925e1c1cdc7ae1fb572f4aad240288a69409.
The repaired checked_shlw function is as follows:
Repair Explanation:
Corrected the incorrect mask 0xffffffffffffffff << 192 to the correct threshold 1 << 192, and modified the judgment condition from n > mask to n >= mask
Ensuring correct detection and return of overflow flags when left-shifting 64 bits might cause overflow
MistTrack Analysis
According to the analysis, the attacker 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06 profited approximately $230 million, including multiple assets such as SUI, vSUI, and USDC.
We discovered that the attacker had prepared gas fees two days prior and made an attempt before the attack, which failed:
After profiting, the attacker transferred some funds like USDC, SOL, and suiETH through cross-chain bridges such as Sui Bridge, Circle, Wormhole, and Mayan to the EVM address 0x89012a55cd6b88e407c9d4ae9b3425f55924919b:
Among these, 5.2341 WBNB was cross-chained to the BSC address 0x89012a55cd6b88e407c9d4ae9b3425f55924919b:
Then, the attacker deposited assets worth $10 million into Suilend:
The attacker also transferred 24,022,896 SUI to a new address 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562, which has not been transferred out yet:
Fortunately, according to Cetus, in cooperation with the SUI Foundation and other ecosystem members, they have successfully frozen $162 million of stolen funds on SUI.
(https://x.com/CetusProtocol/status/1925567348586815622)
Next, we will use the on-chain anti-money laundering and tracking tool MistTrack to analyze the EVM address 0x89012a55cd6b88e407c9d4ae9b3425f55924919b that received cross-chain funds.
This address received 5.2319 BNB on BSC and has not transferred out yet:
The address received 3,000 USDT, 40.88 million USDC, 1,771 SOL, and 8,130.4 ETH on Ethereum.
Among these, USDT, USDC, and SOL were exchanged for ETH through coW Swap, ParaSwap, etc.:
Then, the address transferred 20,000 ETH to the address 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16, which has not transferred out yet:
Currently, the address's balance on Ethereum is 3,244 ETH:
MistTrack has added the above-related addresses to the malicious address library, and we will continue to monitor the address balances.
Summary
This attack demonstrated the power of mathematical overflow vulnerabilities. The attacker precisely calculated and selected specific parameters, exploiting the checked_shlw function's flaw to obtain liquidity worth billions with the cost of just one token. This was an extremely precise mathematical attack, and the Slowmist security team recommends that developers strictly verify the boundary conditions of all mathematical functions in smart contract development.
