Original author: Matthew Lee
On July 31st, Curve announced that its stablecoin pool for Vyper 0.2.15 was attacked due to a compiler vulnerability. Specifically, the failure of the reentrancy lock function allowed hackers to easily launch reentrancy attacks, which allowed attackers to execute certain functions in a single transaction. Some of the funds pools on Curve were using an older version of the compiler, providing an opportunity for hackers.
(Reentrancy attacks are a type of vulnerability caused by the combination of Vyper's features and poorly written smart contracts. They have occurred multiple times in the past, and the security team at OKExCloud has conducted detailed analyses of such cases. Click on the "Read Original Article" link in the lower left corner of this article for more information. Therefore, this article will not showcase the attack details.)
Following that, several other projects announced that they were also attacked. NFT collateral protocol JPEG'd, lending project AlchemixFi, and DeFi protocol MetronomeDAO, cross-chain bridge deBridge, DEX Ellipsis using the Curve mechanism, and others all suffered significant losses.
However, on July 30th, some projects had already become aware of the potential attack threat. Taking Alchemix as an example, they began transferring their assets on the 30th and successfully transferred 8,000 ETH. However, during the asset transfer process, the attacker still managed to steal the remaining 5,000 ETH in the AMO contract.
Image Source: OKLink Explorer
Other project parties have also taken some measures, such as AAVE prohibiting lending from Curve; Alchemix also removing AMO-controlled liquidity from the Curve pool; Metronome directly suspending mainnet functionality.
How to Defend Against Hacker Attacks from Both Sides?
Curve is not the first project to suffer from hacker attacks. Even top DeFi projects are not immune to hacker attacks, so ordinary project parties should pay attention to both the attack side and the contract defense side.
So what preparations can project parties make for the attack side?
The OKLink team recommends that project parties use an on-chain labeling system to identify wallets with a history of suspicious activities and prevent interactions with addresses that have abnormal behavior. One of the attackers of Curve has had a negative record associated with their address, as shown in the image below:
Image Source: OKLink Chaintelligence Pro
Their behavior pattern also deviates from the norm to some extent, as shown in the image below, with more than a hundred transactions in three days.
Image Source: OKLink Onchain AML
How can project parties defend themselves on the defensive end?
We have identified two issues in dealing with such events:
1. Inadequate maintenance work. Most projects focus heavily on code writing and review, but maintenance work has not been given due attention. This vulnerability in the Vyper compiler was discovered two years ago, but the attacked pool still used an old version of the compiler.
2. Too limited code testing scenarios. Many test codes do not effectively test problems. More complex testing methods, such as fuzz testing, should be added. Testing work should be conducted from multiple dimensions such as hacker attack methods, attack complexity, confidentiality, and integrity.
How can stolen funds be recovered?
In reality, most stolen funds are difficult to recover. The figure below shows the destination of the hacker's transferred funds. It can be seen that the stolen ETH has not been transferred externally and the address is not associated with any physical institutions.
Image Source: OKLink Chaintelligence Pro
Some addresses are associated with physical institutions, such as address 0xb752DeF3a1fDEd45d6c4b9F4A8F18E645b41b324 (already returned 2,879.54 ETH). Funds can be recovered through reporting and negotiation with physical institutions for addresses similar to those associated with physical institutions.
Image Source: OKLink Chaintelligence Pro
The correct approach to this incident is to wait for the follow-up fund movement of the dormant address through the warning and tracking functions provided by OKLink or other technology service providers and then take further action. However, the best approach is for the industry to unite and develop a response mechanism based on security incidents, which can better counter abnormal behavior.
Our Warning
Re-entry attacks of this kind of security incidents are likely to occur again, so in addition to the efforts we need to make on both ends of the attack and defense, project parties need to have emergency plans in place to respond promptly when under attack by hackers and minimize the losses to project parties and users. Contributors to Vyper also suggest that for public products like Vyper, we should strengthen public incentives and look for critical vulnerabilities. OKLink calls for the early establishment of a set of security response standards to make tracking funds of black/gray addresses easier.
Just as OKLink's product plays a role in preventing hackers and tracing funds in this type of incident, project parties should consider the additional value that third-party technology service providers can bring when building the security module of the platform and quickly and better build the security fortress of the project.
Raymond Lei and Mengxuan Ren from OKLink also contributed to this article.
