What crypto community has to redefine after the Curve exploit

Keywords

• Attack date: 30th of July, 2023
• Issue type: Vulnerable @nonreentrant function guard
• Exploited pools: alETH/ETH | msETH/ETH | pETH/ETH | CRV/ETH
• Vulnerable lang versions: Vyper 0.2.15, 0.2.16, 0.3.0
• Patch date: Vyper 0.3.1, released at 1st of December, 2021
• Estimative loss: ~$73.5M (Peckshield post)
• Returned funds: ~$52.3M (Peckshield post)

Introduction

📌 In this article, as security auditors, we wish to share some subtle findings that are crucial for comprehending and preventing similar incidents in the future.

📌 To save your time, we will provide only the most important information. For a thorough dive into all the technical nuances of the exploit, we suggest exploring the materials listed in the 🗃️References.

The story of hack begins with two near-simultaneous tweets:

This time hackers caught such a big fish — several pools of Curve were hacked: alETH/ETH | msETH/ETH | pETH/ETH | CRV/ETH.

The price of the CRV token within the CRV/USDT pair plummeted by ~34% at that time. Interestingly, the CRV token’s value was eventually saved by the CEX price feed oracle. While the CRV price dipped to ~$0.09 on DEX platforms, it traded around ~$0.60 on CEX platforms, preventing the price from dropping to zero.

These events also resulted in a temporary depegging of the crvUSD stablecoin. This algorithmic stablecoin experienced a ~0.35% decline before stabilizing back to its USD peg. The recently introduced crvUSD incorporated a PegKeeper algorithm, acting as a key price security tool. This ensures that the crvUSD value is adequately supported by collateral while maintaining a balance between supply and demand.

The repercussions of the hack can be considered moderate, as it equates to just ~3.5% of the protocol’s TVL. Furthermore, the exposed attack vector was a one-off exploit and can’t be replicated. On a brighter note, around ~73% of the stolen funds have already been retrieved. The transactions detailing the return of these stolen funds can be found below.

How Curve has been exploited?

As reported by Curve, this attack vector had not been explored prior to the exploit itself. It is important to emphasize that the hackers took several flashloans that were used to outflank a malfunctioning reentrancy lock. In total, the attackers executed 5 malicious transactions. Curve’s contracts became vulnerable when executing a raw_call to transfer native tokens.

The impacted Curve pools were each utilizing one of the susceptible Vyper versions and were paired with native ETH. Tokens adhering to the ERC-777 standard were also impacted. Their pools were equally vulnerable to this re-entrancy problem due to the ERC-777 callbacks.

On the example of pETH/ETH pool we will show the general algorithm of the attack. The exploit logic was as follows:

1. The exploiter opened an 80,000 WETH flash loan from Balancer and unwrapped all to ETH.
2. They provided flash loan funds (40,000 ETH) as liquidity to the Curve pETH/ETH pool and received LP tokens.
3. Some pETH and ETH were removed from the pool by burning LP tokens.
4. They again provided 40,000 ETH as liquidity to the pool, minting more LP tokens.
5. Another portions of pETH and ETH were withdrawn by burning Curve LP tokens.
6. pETH was swapped for ETH within the Curve pool.
7. Swapped ETH was wrapped to WETH.
8. WETH repaid to Balancer to return the flash loan.
9. ~$11 million was retained as profit.

The reentrancy took place between the remove liquidity and add liquidity procedures. Typically, a pool depositor should receive pool tokens equivalent to the product of the total pool token supply multiplied by the fraction of the depositor's provided liquidity. However, due to the reentrancy flaw, the designated pool tokens were determined using the pre-burn balances. This permitted the attacker to infinitely mint pool tokens, creating a deceitful claim on the pool’s entire contents.

Immediate subsequent actions include halting gauge emissions to the compromised pools and establishing new basic pools to be paired with either WETH or the updated ETH pool implementation.

What was the problem with Vyper?

General Problem description

Re-entrancy is a common Security problem that occurs when an external contract hijacks the intended flow of a contract to repeatedly call its functions. This can result in unauthorized transfers of funds or unexpected behaviors. The attack takes advantage of the recursive function calls in a smart contract, allowing the attacker to re-enter a function before the previous call to that function has completed.

It has several methods of preventing:

1. Usage of contract state modifiers.
2. Usage of blocker-variable (Mutex).
3. OpenZeppelin reentrancyGuard.

openzeppelin-contracts/contracts/security/ReentrancyGuard.sol at master ·… _OpenZeppelin Contracts is a library for secure smart contract development. …_github.com

4. Checks-Effects-Interactions pattern.

Check all conditions (Checks) → update the state (Effects) → external calls (Interactions).

Vyper way to find the solution

📌 All Vyper contracts that have been compiled with releases 0.2.15, 0.2.16, and 0.3.0 are vulnerable to the malfunctioning re-entrancy guard. Be careful while using them!

What Vyper developers did is they added an alternative of Mutex blocker-variable directly into a programming language as a special @nonreentrant function decorator. It allows to declare two states of storage (activated, inactive).

Due to the need to implement support for variables spanning multiple storage slots, starting with the 0.2.9 release, there were two distinct allocator implementations for slot calculation: one for regular storage variables and another for re-entrancy keys. This led to errors in offset calculations.

Vyper 0.2.14 has corrected the calculation of storage offsets for re-entrancy flags. However, this didn’t eliminate the need for two separate allocator implementations. Re-entrancy slots still ended up overlapping with regular storage variables. As a result, both 0.2.13 and 0.2.14 releases were swiftly deprecated.

So, they tried to fix that in 0.2.15 release, but that was the point where our general vulnerability appeared. It arose because the storage_slot offsets for re-entrancy keys disregarded the actual <key> of the @nonreentrant(<key>) decorator, simply reserving a new slot for every encountered @nonreentrant decorator, regardless of what “key” was utilized.

What we have to learn?

• A commendable practice, which has the potential to prevent such breaches even without clear indications for them, would be the periodic migration of contracts to fresher compiler versions. This would be followed by simulating various attack scenarios to practically ensure that a specific compiler version doesn’t expose new attack vectors for a particular protocol and behaves as expected.
• Untimeliness, incompleteness and obscurity of information regarding infrastructure updates, vulnerabilities discovered through Bug bounty programs, and results of security audits inevitably lead to information asymmetry. This often becomes the cause of tragic events.
• Choosing a compiler version is a critically important aspect of infrastructure security. Due to existing information asymmetry, the complete list of issues addressed in a particular version is not always known. Hence, developers should always evaluate infrastructure updates through the lens of the architecture of the project they are developing.
• In turn, auditors should be well-versed in the differences between various versions and be skilled in identifying potential infrastructure attack vectors. We strongly recommend familiarizing yourself with our previous research on the Solidity compiler bugs; it’s important to know for security auditors.

Exploring the Bugs and Features of Solidity Compiler Versions: A Guide for Smart Contract… _Solidity is an open-source programming language widely used to create smart contracts on blockchain platforms such as…_blog.oxor.io

• It’s also essential to highlight the benefits of post-audit formal verification porcedure as the most reliable proof of security. While this is a relatively costly service, it’s undoubtedly worth the investment. It’s particularly advisable for projects with a high TVL, as they are prime targets for hackers.

Conclusion

In conclusion, we’d like to emphasize the notion that the security of DeFi projects today requires the adoption of novel testing and monitoring practices that allow for an in-depth analysis of contract bytecode to be accessible to the general public. The lack of cross-team feedback exchange also becomes evident, so it is significant to adjust several channels for cross-team interactions.

The execution of these practices is only marginally affected by the unique characteristics of specific protocols’ architectures. This necessitates a more individual approach from auditors and security researchers.

About Oxorio

Oxorio is a young but rapidly growing audit and consulting company in the field of the blockchain industry, providing consulting and security audits for organizations from all over the world. Oxorio has participated in multiple blockchain projects during which smart contract systems were designed and deployed by the company.

Oxorio is the creator, maintainer, and major contributor of several blockchain projects and employs more than 5 blockchain specialists to analyze and develop smart contracts.

References

[[1]](https://hackmd.io/@vyperlang/HJUgNMhs2) — “Vyper Nonreentrancy Lock Vulnerability Technical Post-Mortem Report”.

[[2]](https://hackmd.io/@LlamaRisk/BJzSKHNjn) — “Curve Pool Reentrancy Exploit Postmortem July 30th, 2023”.

[[3]](https://resources.curve.fi/lp/understanding-curve-pools) — “Liquidity Providers” section | Curve Resources.

[[4]](https://cointelegraph.com/news/curve-vyper-exploit-whole-story-so-far) — “Curve Vyper exploit: The whole story so far” | CoinTelegraph.