Incident Summary
On 10 December 2024, Clober DEX liquidity vault on Base Network was exploited resulting in a loss of 133.7 ETH (~$501k). The root cause of the attack was a reentrancy vulnerability in the _burn() function of the Rebalancer contract. Clober made an announcement via their X account, offering a 20% bounty to the attacker.
The attacker's wallet address is also linked to an exploit that affected the MAHA Lending Pool on ZeroLend on 4 December 2024 which resulted in a loss of ~$77k.
Key Transactions
Exploit Transaction:
https://basescan.org/tx/0x8fcdfcded45100437ff94801090355f2f689941dca75de9a702e01670f361c04
Attack Flow
Addresses
Attacker wallets:
- Base: 0x012Fc6377F1c5CCF6e29967Bce52e3629AaA6025
- ETH: 0x7760d838192f6e526721a0f6b160627bae989a3e / 0x711c87a0767101fa6f3893facb670b5689621e23
Attack contract: 0x32Fb1BedD95BF78ca2c6943aE5AEaEAAFc0d97C1
Rebalancer contract: 0x6A0b87D6b74F7D5C92722F6a11714DBeDa9F3895
Step by Step
-
First the attacker initiated a 267.4 ETH flash loan via Morpho Blue.
-
The attacker then called rebalancer.open() and created a pool with WETH and a fake token 0xd3c8d0cd07Ade92df2d88752D36b80498cA12788 with the strategy set to their exploit contract, 0x32Fb1BedD95BF78ca2c6943aE5AEaEAAFc0d97C1. During the creation process, the _open() function was called which accepted the strategy.
-
The rebalancer.mint() function was called and 267.4 of both WETH and token 0xd3c was sent to Rebalancer as liquidity for LP tokens.
-
The attacker then called the rebalancer.burn() function to withdraw 133.7 of each token. During the _burn() function the pool.strategy.burnHook was called, as the strategy is the attacker’s contract, it enabled the attacker to reenter the rebalancer.burn() function which didn’t have reentrancy protection.
During the second call the attacker was able to remove 267.4 WETH as the pool reserve balance wasn’t updated until after the burnHook. The initial burn call then finished execution giving the attacker an extra 133.7 ETH.
Vulnerability
The direct cause of the incident is a reentrancy vulnerability in the burn() function via a malicious pool.strategy contract created by the attacker, in which additional WETH was withdrawn.
The initial vulnerability lies in the open() function, where the pools.strategy contract is provided as an arbitrary input. In this instance, the attacker supplied their malicious contract to create a pool with WETH and a fake token which later allowed them to reenter the burn() function and gain an additional 50% ETH.
Clober presents a new algorithm for order book DEX that enables on-chain order matching and settlement on decentralized smart contract platforms. Clober’s order book contract adopts a monolithic design, where a single contract called BookManager contains all the book instances. The rebalancer contract is built upon the BookManager to enable execution of strategy rather than a single swap in order to “rebalance“ the order book DEX, eg the one deployed at (https://basescan.org/address/0x9092e5f62b27c3eD78feB24A0F2ad6474D26DdA5#code).
Note that the strategy contract is also used to handle the mint and burn of liquidity from the rebalancer.
The open() function in rebalancer not only creates a new Book instance from the BookManager contract but also sets up a arbitrary new strategy address for new token pairs. This enables potentially more complex and pair specific strategies to be freely introduced but the lack of a role / contract check lead to exploitation.
In addition the burn() function does not satisfy the check-effect-interaction pattern in that the pool.reserve value is overwritten (effect) after the arguably more sensitive pool.strategy.burnHook() call.
A guide on how Clober’s order book works can be found here: https://docs.clober.io/concepts/introduction.
Fund Flow
On 24 August 2023, the attacker's wallet received an initial deposit of 2.87 ETH from Binance before being immediately transferred to the Base network.
After the attack, the exploiter sent 132 ETH to the pivot address 0x514786C268f7080573687f240Da9Bd37D574aAE3, then transferred 65 ETH to address 0x4c28518Fd9f565eCb20df66769E250e3dA676fbD and 66.99 ETH to address 0x84a0e7d23956e672BFA191f7F66E2A6eF3848100.
Funds from 0x4c2 and 0x84a were bridged from Base network to Ethereum via Across Protocol and split between two wallets:
- 0x7760d838192f6e526721a0f6b160627bae989a3e (62.97 ETH)
- 0x711c87a0767101fa6f3893facb670b5689621e23 (68.97 ETH)
Conclusion
Understanding reentrancy is an important part of secure smart contracts. Reentrancy can occur whenever a function calls back to user, allowing them to perform another function call, as such an otherwise secure function can still lead to a contract being exploited. Smart contracts should try to follow the process of Checks → Effects → Interactions in order to protect against reentrancy. Functions can be further protected by using a ReentrancyGuard which prevents a function from being re-entered.
To keep up to date on the latest incident alerts and statistics follow @certikalert on X, or read our latest analysis on certik.com.
