Cut Incident - Price Manipulation

Caterpillar Coin, a decentralized finance (DeFi) project on the Binance Smart Chain, was exploited on September 10, 2024, resulting in an estimated loss of ~$1.4 million.

The exploiter executed the attack on the project in three transactions:

https://bscscan.com/tx/0x6262c0f15c88aed6f646ed1996eb6aae9ccc5d5704d5faccd1e1397dd047bc8a

https://bscscan.com/tx/0xce6e474dc9555ef971473fee19f87716f38ba01a0df39e78207b71eda134c420

https://bscscan.com/tx/0x2c123d08ca3d50c4b875c0b5de1b5c85d0bf9979dffbf87c48526e3a67396827

Overview

For our analysis, we will focus on the attack that resulted in the largest loss - the third attack:

https://bscscan.com/tx/0x2c123d08ca3d50c4b875c0b5de1b5c85d0bf9979dffbf87c48526e3a67396827

Attacker:

https://bscscan.com/address/0x560a77bc06dcc77eee687acb65d46b580a63eb45

Vulnerable Contract:

https://bscscan.com/address/0x7057f3b0f4d0649b428f0d8378a8a0e7d21d36a7

Exploit Analysis

The attack appears to have followed a straightforward pattern: the attacker used a flash loan to borrow USDT from the USDT-WBNB pair, then ran a loop to create several contracts with the main attack logic running in the constructor. Before creating each contract, the exploiter transferred a large amount of USDT for the logic in the constructor to utilize.

Let's take a deep dive into the logic within the constructor.

With the USDT sent to the contract before its creation, the new contract swaps a portion of it for CUT tokens.

The contract then utilizes the acquired CUT tokens and USDT to addliquidity to the pair contract. In return for providing liquidity, the contract receives a corresponding number of CAKE-LP tokens representing its share of the liquidity pool.

In the subsequent step, the contract employs the remaining CUT tokens (which we know to be a substantial quantity) to execute another swap, this time converting CUT tokens back into USDT.

Then, the attacker burns the CAKE-LP tokens. This action removes their provided liquidity from the pool, enabling them to withdraw their corresponding share of the underlying assets.

Deep dive to this step,

The observation that the 0x34be contract's CUT balance was zero before burning, yet it received 269,661 CUT tokens after burning despite the PAIR contract only transferring 60,652 tokens, strongly suggests an anomaly or exploit within the burning mechanism.

With the substantial amount of CUT tokens obtained through the apparent exploit in the burning process, the attacker was able to execute further swaps, converting these CUT tokens back into USDT. This likely allowed them to amplify their gains significantly.

Furthermore, the attacker appears to have looped the contract creation process, repeating the exploit multiple times to drain a substantial amount of the USDT reserves within the pair contract.

Deep dive into the addLiquidity and removeLiquidity steps in the CUT token code to clarify the mistake in the burn action.

For each new user adding liquidity, CUT token will record the order ID for rewarding purposes, including the equivalent USDT value of the added CUT amount.

And when removing liquidity, CUT token will calculate the reward based on the logic of the _transferFunDealTypeContractAddress contract. This is referred to as the price protection mechanism.

It's an unverified code contract; we will analyze the decompiled source code.

The valuePreservationByRmoveLP function is decompiled within the 0x70f88861 function.

In this function, the contract converts the CUT amount the user received from the removeLiquidity step and calculates the corresponding USDT value based on the current CUT price. It then calculates the change in value compared to the data stored in orderInfo. This change in USDT value is then converted back into a number of CUT tokens using the current price, and these tokens are rewarded to the user.

With this logic, an attacker could easily manipulate the price (pump and dump) to create a significant difference between the initial recorded value in the orderID and the later CUT value within the same transaction.

Rootcause

After analyzing the attack process, we can see the main flaw in the contract lies in the project's use of real-time prices for calculations the reward.

Lesson learned

Depending entirely on real-time prices for calculations can be risky. Attackers might exploit this by manipulating prices to their advantage. To protect the integrity of the project, it is recommended to use oracle-based prices for calculations instead. Using oracle prices ensures more accurate and secure data, reducing the risk of price manipulation and providing a reliable source for financial calculations.