# How to exploit the same vulnerability of MetaPool in two different ways (Nerve Bridge / Saddle Finance) — What you see is not what you get

By BlockSec

On April 30th 2022, an attacker exploited the same vulnerability in the Nerve Bridge Incident to attack the Saddle Finance. In total, 4,900 Ether were under attack. Fortunately, 1,360 Ether of them were successfully saved by us. The detailed description of this incident can be found from the official post mortem.

Although the same vulnerability was exploited, the attack method is **different** from the previous one. As the new attack method is not as straightforward as one may expect, we believe it deserves more efforts to perform a deep investigation. In this report, we first briefly illustrate the vulnerability, and then review the original attack method of the Nerve Bridge Incident. After that, we focus on the Saddle Finance Incident by dissecting the attack process to demystify the new attack method.

# 0x1. About the Deployed Contracts

The relevant contract addresses are listed in the following:

- The victim
contract: 0x824dcd7b044d60df2e89b1bb888e66d8bcf41491*MetaSwap* - The vulnerable
contract: 0x88Cc4aA0dd6Cf126b00C012dDa9f6F4fd9388b17*MetaSwapUtils*

It is worth noting that the shown code of the MetaSwapUtils contract associated with the verified MetaSwap contract is **NOT** equivalent to the deployed MetaSwapUtils contract, whose address is specified in the `Settings`

, as follows:

So do not be confused with these two MetaSwapUtils contracts:)

# 0x2. Vulnerability Analysis

The vulnerable contract belongs to MetaPool, which has been discussed in detail in the previous blog. In short, MetaPool was originally designed by Curve to allow a single coin to be pooled with all the coins in another (base) pool without diluting its liquidity. It’s essentially a pool consisting of a stable-coin and a LP token of the base pool, which consists of several other stable-coins. There is a concern for the MetaPool design, i.e., the MetaPool is basically a stable-coin pool maintaining prices for stable-coins, while the LP token of a base stable-coin pool is **NOT** a stable-coin.

In fact, the price of a LP token of a base stable-coin pool can be obtained by invoking the `getVirtualPrice`

function of the base pool, and its price steadily increases with the accumulation of fees charged by the base pool. To handle that, MetaPool scales up the LP token's reserve before calculating the price, as shown in the below.

Accordingly, if a user swaps a LP token for a stable-coin, the amount of the LP token will be scaled up before calculating the price. Alternatively, if a user swaps a stable-coin for a LP token, the calculated amount of the LP token will be scaled down before transferring and bookkeeping.

The above code snippet of the `swapUnderlying`

function is used to swap between the stable-coin in the MetaPool and those stable-coins in the base pool. As shown in the two red rectangles, the function scales up the amount of incoming LP token and scales down the amount of LP token being exchanged.

However, the implementation of the `swap`

function is inconsistent with that of the `swapUnderlying`

function. Specifically, **the root cause of the vulnerability is due to the flawed calculation implemented in the ****swap**** function (i.e., the ****_calculateSwap**** function) which does not properly scale down and up the amount of the LP token**. As shown in the below, the left side gives the vulnerable code of MetaPool, while the right side gives the fixed version.

The attacker of the Nerve Bridge Incident exploited the inconsistency between the `swap`

function and `swapUnderlying`

function. (Note that Nerve Bridge is a fork project of Saddle Finance.) After that, Saddle Finance fixed the vulnerability and re-deployed the new version (i.e., V2) of the MetaSwapUtils library immediately.

Unfortunately, due to some unknown reason, the sUSD V2 MetaPool on Ethereum was still deployed with the old and vulnerable MetaSwapUtils library. As a result, this vulnerability was successfully exploited by an attacker once again on April 30th. Interestingly, unlike the attack method used in the Nerve Bridge Incident, **a different way** was adopted to attack the vulnerable MetaPool.

# 0x3. The Original Attack Method of the Nerve Bridge Incident

We re-use the below figure (see the the previous blog) to review the original attack method.

Since the vulnerable `swap`

function does not scale down the amount of the LP token (Nerve 3-LP) being exchanged, the exchanged amount (36,959) in the Step 3 is larger than normal. Then the attacker invokes the `swapUnderlying`

function (without vulnerability) to sell the 36,959 Nerve 3-LP (in the Step 4 and 5) for 51,494 fUSDT, which profits 1,143 fUSDT.

Reasonably, the profit can be explained as: the attacker harvests more Nerve 3-LP in the Step 3, and then the attacker sells them in a “normal” price by leveraging the inconsistency between the `swap`

function and the `swapUnderlying`

function.

# 0x4. The New Attack Method of the Saddle Finance Incident

The attacker of the recent Saddle Finance Incident used a different way to attack the same vulnerable `swap`

function without involving the `swapUnderlying`

function. Here we take one attack transaction as a concrete example to illustrate the process.

Intuitively, it seems that there should not exist any profit, as any implication of Step 3 and Step 4 would be counteracted. Specifically, in Step 3, the attacker could swap out more saddleUSD due to the lack of scaling down the LP token (i.e., saddleUSD) being exchanged. However, in Step 4, the attacker would inevitably swap out **LESS** sUSD, because the vulnerable `swap`

function does not scale up the amount of incoming saddleUSD before calculating the price.

However, as shown in the above figure, the attacker profited **2,059,771** sUSD through the pair of swaps in Step 3 and Step 4. To figure out the reason of the profit, we have to dive into the pricing mechanism and perform a deep investigation to understand the attack process.

# 0x4.1 The Pricing Mechanism

The MetaPool of Saddle Finance inherits Curve’s pricing formula:

The graph of the function (when n equals to 2) is shown as the blue curve in the below figure. (The design of the formula can be found in Curve StableSwap Whitepaper.)

Here comes the question: *how does the MetaPool calculate the price for each swap by using this formula?*

Let’s say n is 2, and a user uses *dx*0 token0 to swap *dx*1 token1. We can simulate the calculation process for *dx*1. In each swap, `A`

can be treated as a constant, and `D`

is the only variable that can affect the price curve. In fact, `D`

is increased with the accumulation of the fees charged by the pool. Specifically, the calculation process can be summarized as the following three steps:

- Step I: Put the current pool’s reserves (
*x*0 and*x*1) into the formula to calculate the current`D`

, which determines the current price curve. - Step II: Let the
*x*0 increase*dx*0, and put the current`D`

and*x*0 into the formula to calculate the new*x*1. - Step III: Then,
*dx*1 is the difference between the new*x*1 and the old*x*1.

If token0 is the LP token of a base pool, then the Step II becomes:

Here *baseVirtualPrice / *1*e*18 is around 1.0033 during the attack. Alternatively, if the token is the LP token of a base pool, then the Step III becomes:

To understand how `D`

affects the price curve, we also use an example to describe it. Say a user first swaps *dx*0 token0 for *dx*1 token1, and then swaps dx_1*dx*1 token1 for *dx*0′ token0.

As shown in the above figure, since Step ② charges fees for the first swap, `D`

is increased to shift the price curve upwards (from the black curve to the blue one). Furthermore, the figure clearly describes the reason why *dx*0′ is smaller than *dx*0.

# 0x4.2 The Attack Analysis

To analyze the reason of the profit, we deployed the vulnerable and fixed *MetaSwapUtils* libraries locally and used the state of the victim pool at that moment to simulate the attack. Furthermore, during this simulation, we also recorded a few values that can help to understand the attack process, i.e., `A`

is 10,000, *x_sUSD* is 8,130,463, *x_saddleUSD* is 9,688,608, and `D`

is 17,818,392 at that moment.

The above figure describes the process of the profitable pair of swaps:

- Swap-I: swap 14,800,272 sUSD for 9,657,586 saddleUSD
- Swap-II: swap 9,657,586 saddleUSD for 16,860,043 sUSD

Specifically, Swap-I can be divided into the following two steps:

- ①: Swap 14,800,272 sUSD for 9,625,654 saddleUSD. Now,
`D`

is increased as 17,931,435 (due to the charged fees). - ②: Since the vulnerable MetaPool does not scale down the amount of exchanged saddleUSD, the pool losses 31,932 saddleUSD. The losses decrease
`D`

as**15,736,195**, which further shifts the price curve down (from the black curve to the gray one).

Similarly, Swap-II can also be divided into two steps:

- ③: Since the price curve is shifted down, the same 9,625,654 saddleUSD can swap out 16,891,906 sUSD that is far more than the cost: 14,800,272 sUSD.
- ④: Since the vulnerable MetaPool does not scale up the amount of incoming saddleUSD before calculating the price, there is 31,863 sUSD left in the MetaPool, which shifts the price curve up (from the gray curve to the blue one). Nevertheless, the pair of swaps still profits 2,059,771 sUSD.

Obviously, the above analysis clearly elaborates why the attacker could harvest the profit by using the new attack method. Besides, it seems that the original attack method seems to be more efficient than the new one due to the sUSD left in the MetaPool in Swap-II. Of course, the attacker could launch multiple attacks to drain the pool, which have been observed in the wild.

# 0x5. Some Take Away

The investigation suggests that the root cause for the profits in the two incidents is the same. Specifically, the first swap (which swaps for the LP token) decreases `D`

of the vulnerable MetaPool, which further shifts its price curve down. That shifting greatly affects the subsequent pricing and is the main reason for the subsequent profit.

# About BlockSec

The BlockSec Team focuses on the security of the blockchain ecosystem, and collaborates with leading DeFi projects to secure their products. The team is founded by top-notch security researchers and experienced experts from both academia and industry. They have published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, and released detailed analysis reports of high-impact security incidents.

- Twitter: [BlockSecTeam]| [BlockSecAlert]
- Medium: https://blocksecteam.medium.com
- Website: https://www.blocksecteam.com