SlowMist: Analysis of YAM attack (Released in 2020)

On August 13, 2020, YAM, a well-known Ethereum DeFi project, officially tweeted that it found a loophole in the contract, and the price plummeted by 99% within 24 hours. After receiving the intelligence, the SlowMist security team quickly carried out relevant follow-up and analysis. The following are detailed technical details.

What happened?

The above is a brief description of the event by YAM officials. To put it simply, the official found in the contract that there was a problem with the function responsible for adjusting the supply. This problem caused excess YAM tokens to be put into the YAM reserves contract, and if this problem is not corrected, it will lead to subsequent governance of YAM becoming impossible. At the same time, the official gave the specific problem code of this vulnerability, as follows:

It can be seen from the above figure that due to irregular coding, when the YAM contract adjusts totalSupply, the final result should be divided by the BASE variable, but it is ignored in the actual development process, resulting in incorrect calculation of totoalSupply, which is higher than the original value. 10¹⁸ times larger. But how do token supply issues and governance relate? This requires us to do further analysis on the code.

Impact of Vulnerabilities

According to the official problem code and project Github address, it can be located that the rebase function to adjust the supply is located in the YAMDelegator.sol contract. The specific code is as follows:

Track the rebase function and find that the rebase function finally calls the delegateAndReturn function, the code is as follows:

Analyzing the code, it is found that the delegateAndReturn function finally uses the delegatecall method to call the logic in the implementation address, that is to say, this is an upgradable contract model. The real rebase logic is located in YAM.sol, continue to follow up the specific logic of the rebase function, as follows:

By analyzing the logic of the final rebase function, it is found that the code adjusts totalSupply according to yamsScalingFactor. Since yamsScalingFactor is a high-precision value, it should be divided by BASE after the adjustment is completed to remove the accuracy in the calculation process and obtain the correct value. However, when the project party adjusted totalSupply, they forgot to adjust the calculation results, which resulted in the unexpected increase of totalSupply and incorrect results.

By observing the decorator of the rebase function, it is found that only the rebaser can be called here. The rebaser is a contract in YAM that is used to implement supply-related logic, that is to say, the rebaser contract finally calls the rebase function in the YAM.sol contract. By tracking the relevant code, it is found that the logic corresponding to the supply adjustment in the rebaser contract is the rebase function, and the code is as follows:

The analysis code finds that after a series of checks, the function first obtains the current supply of YAM, calculates the amount of minted coins this time, and then calls the rebase function in YAM.sol to adjust totalSupply. In other words, the impact on totalSupply after rebase will not take effect until the next call to the rebase function of the rebaser contract. Finally the rebase function calls the afterRebase function. Let’s follow up with the code in the afterRebase function:

The main logic of the afterRebase function is in the buyReserveAndTransfer function, which is used to use part of the additional tokens to purchase yCRV tokens in Uniswap. Track the buyReserveAndTransfer function, the code is as follows:

buyReserveAndTransfer will first calculate the amount of YAM used to exchange yCRV in Uniswap. If the amount is less than the amount of YAM minted, the excess YAM coins will be issued to the reserves contract. This step is to call the uniswapV2Call of the rebase contract through the Uniswap contract The function is implemented, and the specific code is as follows:

At this point in the analysis, a complete rebase process is completed. You may be confused. Let’s simplify it with a simple flow chart:

In other words, every rebase, if there are redundant YAM tokens, these tokens will flow into the reserves contract, so what is the relationship between this and community governance?

By analyzing the project code, it is found that the governance-related logic is in YAMGovernorAlpha.sol, in which the function to initiate a proposal is propose. The specific code is as follows:

It can be found that when initiating a proposal, the proposal initiator needs to have a certain amount of voting rights. This value must be greater than the value calculated by proposalThreshold. The specific code is as follows:

That is to say, the proposal initiator’s voting power must be greater than 1% of initSupply to initiate a proposal. What about initSupply? The answer is the mint function of the YAM token, the code is as follows:

It can be seen from the code that the mint function will update the value of initSupply every time a coin is minted, and this value is calculated based on the value of amount, that is, the number of coins minted.

Now that we have analyzed all the processes, what is left is to connect all the analyzes to see what impact this vulnerability has on YAM, as shown in the following figure:

The analysis of the whole incident is shown in the figure above. Since the last value of totalSupply was taken during rebase, the miscalculated value of totalSupply will not be immediately applied to initSupply through mint, so the community still has a chance to recover before the next rebase. This mistake, cut your losses. But once the next rebase is executed, the whole mistake will become irreparable.

By querying the relevant information of the YAM token contract on Etherscan, we can see that totalSupply has reached a very large value, while initSupply has not been affected.

Summary

In this incident, the official has given a specific repair plan, so I won’t go into details here. This incident fully exposed the huge risks hidden in unaudited DeFi contracts, although YAM developers have indicated in Github that many codes of YAM contracts refer to fully audited DeFi projects such as Compound, Ampleforth, Synthetix and YEarn/ YFI, but unexpected risks inevitably occurred.

Belmore, the core developer of the DeFi project Yam Finance (YAM), said on Twitter: “I’m sorry, everyone. I failed. Thank you for your great support today. I am so sad.” The Fog Security Team recommends the following:

1. Due to the high complexity of DeFi contracts, any DeFi project needs to be fully audited by a professional security team before going online to reduce the risk of contract accidents. For auditing, please contact the SlowMist security team (team@slowmist.com)

2. Decentralized governance in the project should be done step by step. At the beginning of the project, appropriate permissions need to be set to prevent black swan events.

About SlowMist

SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, etc.

Website：
https://www.slowmist.com
Twitter：
https://twitter.com/SlowMist_Team
Github：
https://github.com/slowmist/