Common Security Vulnerabilities in DeFi and Prevention Measures

Recently, a security expert shared a lesson on DeFi security for community members. The expert reviewed the major security incidents that the Web3 industry has encountered over the past year, discussed the reasons for these incidents and how to avoid them, summarized common security vulnerabilities in smart contracts and preventive measures, and provided some security advice for project parties and ordinary users.

Common types of DeFi vulnerabilities mainly include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function issues, business logic vulnerabilities, private key leaks, and reentrancy attacks. This article will focus on flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but they are also often exploited by attackers. Attackers borrow large amounts of funds through flash loans to manipulate prices or attack business logic. Developers need to consider whether the contract's functionality could lead to anomalies due to large sums of money or be exploited to obtain unjust profits.

Many DeFi projects seem to have high returns, but in reality, the quality of the project teams varies significantly. Some projects may have purchased their code, and even if the code itself has no vulnerabilities, there may still be logical issues. For example, some projects distribute rewards based on the number of tokens held by investors at fixed times, but attackers can exploit flash loans to purchase a large number of tokens and obtain most of the rewards when they are distributed.

Price Manipulation

The issue of price manipulation is closely related to flash loans, mainly because certain parameters in price calculation can be controlled by users. There are two common types of issues:

1. Using third-party data when calculating prices, but doing so incorrectly or lacking checks, resulting in price manipulation.
2. Use the number of tokens at certain addresses as calculation variables, and the token balances at these addresses can be temporarily increased or decreased.

Reentrancy Attack

Reentrancy attacks are one of the main dangers that can arise when calling external contracts. An attacker may take over the control flow and make unexpected changes to the data. For example:

solidity mapping (address => uint) private userBalances;

function withdrawBalance() public { uint amountToWithdraw = userBalances[msg.sender]; (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); require(success); userBalances[msg.sender] = 0; }

In this example, since the user's balance is only set to 0 at the end of the function, the attacker can call the function again after the first successful call, thereby withdrawing the balance multiple times.

To solve the reentrancy problem, attention should be paid to the following points:

1. Not only should we prevent the reentrancy issue of a single function;
2. Follow the Checks-Effects-Interactions pattern for coding;
3. Use a time-tested anti-reentrancy modifier.

A typical case of a reentrancy attack is the Omni Protocol incident. In this attack, the transactions submitted by the attacker who discovered the vulnerability were captured and executed in advance by other hackers, resulting in the original attacker only receiving a portion of the profits. This highlights the "dark forest" nature of the Web3 ecosystem, where attackers can also be prey to one another.

Security Recommendations

Project party security recommendations

1. Follow best security practices for contract development.
2. Implement contract upgrade and pause functionality.
3. Implement a time lock mechanism.
4. Increase security investment and establish a comprehensive security system.
5. Raise the security awareness of all employees.
6. Prevent internal malfeasance while enhancing risk control and improving efficiency.
7. Exercise caution when introducing third-party services and adhere to the principle that "the default upstream and downstream are both unsafe."

How can users/LP determine if a smart contract is safe?

1. Check if the contract is open source.
2. Verify whether the Owner adopts a decentralized multi-signature mechanism.
3. Check the existing trading situation of the contract.
4. Confirm whether the contract is a proxy contract, whether it is upgradeable, and whether it has a time lock.
5. Check whether the contract has been audited by multiple institutions and assess whether the Owner's permissions are too extensive.
6. Pay attention to the selection and use of oracles.

In summary, security issues are always one of the most important considerations in the DeFi field. Whether it is the project party or ordinary users, there is a need to remain highly vigilant and take appropriate security measures to reduce risks and ensure the safety of assets.