DeFi Network Security Situation Report

DeFi security incidents have occurred frequently recently. The security incidents recorded in the National Blockchain Vulnerability Database include the shroom.finance project issuing unlimited tokens, the Unicats project authorization attack, the Balancer project attack, and Akropolis and OUSD being attacked by hackers again.

Recently, DeFi security incidents have occurred frequently. The security incidents recorded in the National Blockchain Vulnerability Database include the shroom.finance project issuing unlimited tokens, the Unicats project authorization attack, the Balancer project attack, and the Akropolis and OUSD being attacked by hackers. The DeFi ecological security threat risk level is high.

1. The current overall development of DeFi

In December 2017, the world's first DeFi project, Maker, was officially launched. This year, DeFi has experienced rapid development, especially from June to November, the value of DeFi locked assets increased from US$1 billion to about US$18 billion, an increase of 1,700%. At its peak, the number of projects exceeded 500. Currently, the main product types of DeFi include lending markets, decentralized exchanges (DEX), derivatives, payment networks, tokenized assets, etc. In addition, according to the purpose and token characteristics, DeFi also has categories such as infrastructure, data services, wallets and stablecoins.

Figure 1. Total locked value (TVL) share of major DeFi project types

As DeFi projects develop rapidly, various security incidents surrounding DeFi have begun to occur frequently.

2. Security Status of DeFi

(I) Security status of DeFi on various chain platforms According to statistics of DeFi security incidents since this year by the National Blockchain Vulnerability Database, 82.61% of security incidents occurred on Ethereum. TRON blockchain accounted for 6.52%, EOS blockchain accounted for 4.35%, and other blockchains accounted for 6.52%.

Figure 2: Proportion of DeFi security incidents on various blockchains

(II) Security issues of DeFi projects 1. Unlimited issuance problem Unlimited issuance refers to the existence of a vulnerability in the smart contract that can illegally call the issuance function, allowing attackers to issue coins at will.

DeFi project parties can issue additional tokens by adding minter permissions. In addition, there are also cases where the governance contract address that should have the coin minting permission is replaced with an external address held by the project party, which allows the project party to mint unlimited coins. Some project parties also did not write a time lock, resulting in unlimited coin issuance without time restrictions. For example, the DeFi project shroom.finance did not set a time lock, resulting in unlimited token issuance.

2. Authorization attack problem Authorization attack means that the attacker exploits the contract logic loopholes to obtain the contract permissions authorized by other users and transfer the user's tokens at will.

When investors participate in DeFi projects, for convenience, they are usually required to authorize all tokens to the contract address to avoid repeated authorization in subsequent operations. For example, if a user has 10 million tokens, but the contract does not use 10 million every time it transfers money, then each contract transfer requires the user's signature. If 10 million is authorized to the contract address at the beginning, unnecessary repeated operations can be avoided. However, if a malicious person uses the contract authority to call the transferFrom function in the ERC20 token to implement a proxy transfer, then all tokens in the user's wallet can be manipulated at will by the attacker. In the fraud project Unicats, the project party left such permissions that can bypass the judgment conditions, which is equivalent to an address whitelist, allowing it to use the contract identity to initiate transactions and arbitrarily steal users' assets.

Figure 3: Partial screenshot of the attack code

From the current situation, almost all project parties will set the maximum amount of user authorization by default (2^256) in the front-end or other places. When some contracts (A) call other contracts (B), they will also need to authorize contract (B), but they often use the method of authorizing as much as they use. Therefore, as an investor, you must remain highly vigilant about the authorization issues of DeFi projects to avoid falling into the "trap" of attackers.

3. Arbitrage problem Arbitrage is a way to make profits by simultaneously buying and selling the same virtual digital currency assets. It takes advantage of the different pricing of the same virtual digital currency assets in different exchanges. Especially in the initial stage of the issuance of virtual digital currency assets, the liquidity varies greatly between different exchanges, resulting in many opportunities to use the price differences between exchanges to arbitrage and earn profits.

This type of problem mainly occurs in DeFi projects with high business complexity. For example, the attack on the Balancer project. The attacker combined the characteristics of "flash loans", deflationary currencies, and the "constant product" rule of the Balancer token pool, and used the deflationary token STA and "flash loans" to construct a special case with only 1 unit of STA. When there is only 1 unit of STA and other tokens in the pool, only 1 unit of STA can be exchanged for other tokens of higher value. In addition, STA has a deflationary characteristic, that is, some tokens will be destroyed when transferring (generally 1/100 of the amount of transferred tokens), but because 1 unit of STA is the minimum value, 1 unit of STA will also be destroyed when 1 unit of STA is transferred, which makes the number of STA in the pool unchanged. The attacker can empty the fund pool by repeatedly performing this operation. As shown in the following figure:

Figure 4 Attack process

4. Reentrancy attack A reentrancy attack refers to a situation where the contract code is hijacked by an attacker when executing a callback function, causing the callback function that should have been called to be replaced with a malicious contract address, allowing the attacker to call the function again. For example, a function that should have performed a transfer is called twice, which allows the attacker to gain benefits twice.

Recently, the DeFi protocol Akropolis was attacked by hackers. Through analysis, it was found that the attack was mainly caused by the failure of the contract to perform parameter verification and to prevent reentrancy attacks.

The attacker first passes his malicious contract address as a parameter to the function deposit(), where the parameter position of the token address is passed in. This will cause the function to call the attacker's malicious contract when executing the token's safetransferFrom() function. The attack process is divided into the following steps:

1. The deposit() function first executes the depositToProtocol() function, and there is a maliciously hijacked safeTransferFrom() function in the depositToProtocol() function, so this step will execute the attack contract.

2. In the attack contract, the attacker called the deposit() function again, and this time the parameter passed in was a normal token address. This time, the attacker deposited real DAI for normal deposit operations.

3. As can be seen in the code, the mint function previously performed a balance difference calculation, and the coinage is calculated based on this difference. The deposit of real DAI this time increases the balance, so the attacker will obtain poolTokens equivalent to the deposited DAI.

4. After the malicious contract is executed, the normal contract will continue to execute the code after the depositToProtocol() function.

5. Since the attacker did deposit DAI before, this time the attacker will obtain poolTokens equivalent to the deposited DAI again, doubling the assets.

The attacker used this series of methods to launch multiple attacks on the contract and ultimately made a profit of more than 2 million DAI.

Figure 5 Attack process

Another example is the recent OUSD reentry attack, where the attacker used reentry attacks and elastic supply adjustments to achieve their attack objectives. In this attack, the attacker borrowed 70,000 ETH through dYdX flash loans and exchanged the ETH for the corresponding USDT and DAI.

1. The attacker first transferred 7.5 million USDT into the Vault, thus increasing his share of the value in the Vault to more than 50%.

2. The mintMultiple() function in the contract is called to mint coins, and 20.5 million DAI and another token impersonated by the malicious contract are passed in as parameters. The function receives 20.5 million DAI normally. When receiving another token, the attacker's malicious contract is actually called. The attacker deposits 2,000 USDT into the attack contract again for minting, in order to trigger the rebase() call.

3. Because a normal contract will settle assets and update the total value of assets after the transfer, and then distribute them through rebase(), but the contract is hijacked at this time, and the contract has not yet included the 20.5 million DAI in the total value of Vault assets, so when rebase() is performed, all 20.5 million DAI will be distributed as income.

4. Since the attacker holds more than 50% of the value in the Vault, the attacker will be allocated more than 10.25 million DAI without any effort. After that, the contract will execute normally and the attacker will receive OUSD tokens minted by oUSD.mint, which are equal to the deposited DAI.

In the end, the attacker's total gains amounted to approximately 33.27 million OUSD. Finally, the attacker redeemed the previously deposited tokens and returned the obtained tokens to the flash loan.

(III) Causes of DeFi security incidents The National Blockchain Vulnerability Database analyzes the main causes of DeFi security incidents, including business logic implementation vulnerabilities, business design defects, project party running away, reentry attacks, phishing scams, etc. The detailed cause classification is shown in the figure below.

Figure 6 Causes of DeFi security incidents

In addition, another reason for the frequent occurrence of DeFi security incidents is that a large number of "copycat" projects have sprung up in the market. These projects generally have problems such as weak technical foundation and unreasonable business design, and some are suspected of being fraudulent projects. Next, we analyze the typical problems as follows:

1. Business logic implementation error The so-called business logic implementation error refers to the existence of vulnerabilities due to incorrect code writing methods when writing programs to meet requirements. In the USDT lock event of the CherryFi project, its transfer logic called the safeTransfer function to perform specific transfer operations. However, the USDT transfer logic does not return a value, which causes the safeTransfer call to never succeed, resulting in funds being locked, and users are therefore unable to transfer USDT in and out. It is understood that the CherryFi code has not been audited.

2. Business design defects Business design defects refer to business defects that are not considered perfect and rigorous in the process of business design, rather than business defects caused by code writing problems. In DeFi projects, such problems are mainly reflected in the logic related to trading pairs or the elastic supply mechanism, and are very likely to cause malicious arbitrage problems. In the Curve project, if the exchange ratio of variable A is inconsistent before and after the change, arbitrage opportunities will arise.

Figure 7 Token Bonding Curve

As shown in the figure above, the balances of different tokens in the Curve token pool must satisfy this curve. To further illustrate the formation process of this arbitrage space, we can assume that Token X is USDT and Token Y is another token. When A=1 (blue curve), the user will exchange all the USDT and Token Y he holds into Token Y. Assume that there are 150 USDT and 50 Token Y in the pool before the exchange, as shown in the red dot in the figure. This point is on the blue curve, while maintaining the ratio of 150 to 50 (1.5:0.5). The user holds 50 USDT. According to the curve at this time, if the user uses 50 USDT to exchange Token Y, there will be 200 USDT in the pool. In order to ensure that the ratio is on the blue curve, the red dot will move to the yellow dot, and the corresponding ratio is 200:30 (2:0.3), so 50 USDT can be exchanged for 20 Token Y.

Assume that when A=10 (red curve), the current balance in the pool is 200USDT and 30Token Y. At this time, the 20Token Y held is used to exchange USDT. At this time, there are 50Token Y in the pool. In order to meet the ratio of the red curve, the yellow point will move to the green point, and the balance in the pool should be 140USDT and 50Token Y, that is, 20Token Y can be exchanged for 60USDT, so a profit of 10 USDT is obtained. This is the arbitrage space formed before and after the change of A.

3. Code Errors Code errors usually occur when writing code because programmers are careless and cause code writing errors. This problem can be devastating to the project. For example, due to a code writing error in the YAM project, the precision was forgotten to be divided during the elastic supply calculation process, as shown in the figure below, resulting in the contract retaining too many tokens. Governance requires voting. To initiate a proposal, the initiator of the proposal needs to pledge 1% of the total tokens in order for the proposal to be successful. If the total number of tokens is too large, the amount of tokens required for the proposal to be pledged will be huge, resulting in no one being able to afford the tokens required for the proposal. In the end, the project party had to announce the termination of the project.

Figure 8 Screenshot of some error codes

Finally, with the rapid development of the DeFi industry, more and more combinatorial innovations are being applied to DeFi projects. However, it is often difficult for people to discover the risks after the combination during security testing or security audits. For example, in the Lendf.me attack, there was no problem with the project's business logic or ERC777 itself, but there was a reentrancy vulnerability after the combination. The problem of combinatorial risks still needs to be solved by various manufacturers in the blockchain security industry.

3. Conclusion The current DeFi project is still in its early stages of development, with uneven levels of various project parties and large differences in technical conditions. Some DeFi projects, first, have not undergone professional code security audits; second, they ignore the characteristics of blockchain technology and only build based on the experience of traditional financial centralized systems; third, some blockchain applications have not been verified for authenticity, and there is a risk of being defrauded by criminals using gimmicks such as digital asset investment and financial management. Some project parties also have the behavior of transferring a large number of digital assets on the address, which urgently needs the attention of relevant parties. In summary, the risk level of DeFi ecological security threat is high.

The National Blockchain Vulnerability Database is operated by the National Internet Emergency Center. By calling on and guiding blockchain security vendors, white hats, blockchain companies and other parties to participate in the construction of a blockchain security ecosystem, it improves the discovery, analysis, and early warning of blockchain vulnerabilities and security incidents in China, as well as the overall research level and emergency response capabilities, and provides important technical and data support for the security assurance of China's blockchain industry.