MetaTrust Raft suffers a loss of 3.6 million due to attack, hacker’s fancy maneuver almost sends it all into a black hole.

MetaTrust Raft experiences 3.6 million loss after being attacked, narrowly avoiding a catastrophic loss due to hacker's clever tactic.

On November 11, 2023, at 02:59:23 AM UTC+8:00, MetaScout detected a flash loan attack on the stablecoin protocol Raft on Ethereum. This resulted in the minting of 6.7 million stablecoins $R and a loss of $3.6 million for the protocol. The root cause was a precision calculation issue during the minting of the token shares, which the hacker exploited to obtain additional shares.

MetaTrust Labs conducted an in-depth research and analysis on this attack, revealing how the hacker utilized the vulnerability to launch the attack.

Stablecoin protocol Raft:

About The Stablecoin Protocol Raft

• Token Terminal Everything you need to know about Arbitrum is here
• MuseLianGuaiy launches MuseCard, shaping the future of cryptocurrency payments.
• DTCpay Brings the Future to Retail Singapore Startup Partners with Chinese Firms to Launch Cutting-Edge Crypto Payments System

Raft is a DeFi protocol that provides a capital-efficient lending mechanism by depositing liquidity staking tokens (LSDs) as collateral while retaining staking rewards. [Link to Raft](https://raft.fi/)

At the time of writing this article, the Total Value Locked (TVL) has decreased by 46% after today’s attack, amounting to $7 million. The price of $R has dropped by 99.6% to $0.0036.

Related contracts and transactions:

Smart Contracts & Transactions

– [Transaction](https://etherscan.io/tx/0xfeedbf51b4e2338e38171f6e19501327294ab1907ab44cfd2d7e7336c975ace7)

– Attacker: 0xc1f2b71a502b551a65eee9c96318afdd5fd439fa

– Attack contract: 0x0a3340129816a86b62b7eafd61427f743c315ef8

– Target contract: InterestRatePositionManager: 0x9ab6b21cdf116f611110b048987e58894786c244

Attack steps:

1. Borrowed 6,000 $cbETH from AAVE through a flash loan.

2. Transferred a total of 6,001 $cbETH to the InterestRatePositionManager contract.

3. Liquidated the pre-created position in the InterestRatePositionManager contract (0x011992114806e2c3770df73fa0d19884215db85f).

4. Set the index of the raft staking tokens to 6,003,441,032,036,096,684,181, which is the $cbETH balance of the InterestRatePositionManager contract multiplied by 1,000 due to the donation in step 2.

5. Used the divUp function to calculate shares, minting 1 wei share with just 1 wei of $cbETH. Note that the divUp function always returns a minimum value of 1 when the numerator is non-zero, regardless of the denominator’s size.

6. Repeated step 5 sixty times to obtain 60 wei shares, equivalent to 10,050 $cbETH.

7. Exchange 6003 $cbETH for only 90 wei $rcbETH-c;

8. Borrow 6.7 million $R, that is, profit, and ultimately exchange it for 1,575 $ETH worth 3.6 million dollars in different Dapps, including:

– Exchange 2.1 million $R for 2 million $sDAI on Balancer

– Exchange 1.2 million $R for 1.15 million $DAI on Balancer

– Exchange 200,000 $R for 86,000 $USDC on Uniswap

9. Surprisingly, the hacker burned 1,570 $ETH to the blackhole address, which means the hacker didn’t get any profit.

Root Cause

Root Cause

The root cause is a precision calculation issue that occurred during the token minting process, the hacker took advantage of this issue to obtain extra token shares. Due to the donation of $cbETH amplifying the index, the hacker’s shares had more value. Therefore, with just a small amount of $rcbETH-c, the hacker exchanged it for 6003 $cbETH and borrowed a large amount of $R.

Key Code

Key Code

Asset Loss

Asset Loss

3.6 million dollars

Fund Flow

Fund Flow

1,570 $ETH was burned due to the hacker’s mistake.

As of the time of writing this article, the attacker’s wallet contains 1.4 million $R tokens (worth $4.6 thousand).

Security Recommendations

Security Recommendations

1. Consider checking for potential rounding issues in interest rate calculations, such as whether they can be manipulated by malicious users in edge cases, as in the case of a Raft attack.

2. It is recommended to implement a monitoring system and take measures to pause the protocol in case of emergencies. Alternatively, integrating a memory pool blocking system would be beneficial. This system can effectively detect attack transactions in the memory pool when an attacker executes an attack, enabling proactive blocking to prevent losses.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!