On the evening of July 30, 2023, multiple projects encountered a dark moment.
Around 21:35 on July 30, according to Beosin’s EagleEye security risk monitoring, early warning, and interception platform, the NFT lending protocol JPEG’d was attacked.
While the Beosin security team was analyzing, several other projects were also damaged.
Around 22:51 on July 30, the msETH-ETH pool was attacked by hackers.
- How to implement the concept of ‘Privacy Mempool’ using ZK and VDF?
- Opinion Blockchain relying on AWS will not bring transparency to artificial intelligence.
- World Engine A Shard Rollup Framework Designed for Full-chain Games
Around 23:35 on July 30, the alETH-ETH pool was cracked using the same attack method.
Subsequently, the liquidity pools belonging to the DeFi project Alchemix and the Metronome project were attacked.
The same attack method was used multiple times by hackers. What exactly went wrong?
The reasons for the attacks on multiple projects: Is it Vyper?
According to a tweet from the Ethereum programming language Vyper on July 31, Vyper versions 0.2.15, 0.2.16, and 0.3.0 have reentrancy vulnerabilities in their locks. In addition, native ETH can invoke callbacks during transfers, allowing these LP pools associated with ETH to be susceptible to reentrancy attacks.
Subsequently, the Curve official Twitter account stated that due to a malfunction in the reentrancy lock, many stablecoin pools (alETH/msETH/pETH) using Vyper 0.2.15 were attacked, but other pools are safe.
Analysis by the Beosin security team of the attacked projects
Below are the related transactions involved in this hacker attack event
● Attacking Transactions
● Attacker Addresses
● Attacked Contract
According to the analysis by the Beosin security team, this attack is mainly due to the failure of the reentrancy lock in Vyper 0.2.15. The attacker adds liquidity by calling the add_liquidity function during the removal of liquidity through the remove_liquidity function of the relevant liquidity pool. Because the balance update occurs before the reentrancy into the add_liquidity function, the price calculation becomes incorrect.
We take the msETH-ETH-f pool attacked by 0xc93eb238f as an example.
In the hacker’s preparation phase, they first borrowed 10,000 ETH as attack funds through balancer:Vault flash loans.
1. In the first step, the attacker calls the add_liquidity function to add the borrowed 5000 ETH to the pool.
2. In the second step, the attacker calls the remove_liquidity function to remove the ETH liquidity from the pool, and reenters the add_liquidity function to add liquidity again.
3. In the third step, due to the balance update occurring before the reentrancy into the add_liquidity function, the price calculation becomes incorrect. It is worth noting that both the remove_liquidity function and the add_liquidity function have used reentrancy locks to prevent reentrancy.
4. Therefore, the reentrancy prevention mechanism here is ineffective. By reading the vulnerable Vyper code shown on the left in the following figure, it can be found that when the name of the reentrancy lock appears for the second time, the original number of storage_slot will increase by 1. In other words, the slot for the first lock is 0, but after another function uses the lock, the slot becomes 1 and the reentrancy lock becomes ineffective.
As of the time of writing, the funds lost in this attack have exceeded $59 million. Beosin KYT has detected that 2879 ETH has been returned to the address c0ffeebabe.eth, and the stolen funds are still in multiple attacker addresses.
Regarding the impact of this event, on July 31st, Binance founder Changpeng Zhao CZ tweeted that CEX saves DeFi. Binance users are not affected. The Binance team has checked for the Vyper reentrancy vulnerability. Binance only uses version 0.3.7 or above. It is important to keep the codebase, applications, and operating systems up to date.
On July 31st, Curve tweeted that due to issues with the Vyper compiler in versions 0.2.15-0.3.0, CRV/ETH, alETH/ETH, msETH/ETH, and pETH/ETH were attacked by hackers. In addition, the Arbitrum Tricrypto pool may also be affected. Auditors and Vyper developers have not yet found any exploitable vulnerabilities, but please refrain from using them.
The impact of this incident is still ongoing, and users with funds in these pools need to be extra cautious.
In response to this incident, the Beosin security team recommends that projects using Vyper versions 0.2.15, 0.2.16, and 0.3.0 should conduct self-inspections as these versions have vulnerabilities with reentrancy locks. After the project goes live, it is strongly recommended that project teams continue to monitor vulnerability disclosure information for third-party components/dependencies and promptly mitigate security risks.