Decentralized Finance Security Vulnerabilities and Preventive Measures

Recently, a security expert shared a DeFi security course with the community. The expert reviewed significant security incidents that the Web3 industry faced over the past year, discussed the reasons behind these events and how to avoid them, summarized common smart contract security vulnerabilities and preventive measures, and provided some security advice for project parties and users.

Common types of DeFi vulnerabilities include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function issues, business logic vulnerabilities, private key leakage, and reentrancy attacks. This article focuses on the three types: flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but they can also be exploited by hackers for attacks. 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 be affected by large amounts of funds leading to anomalies or being exploited for improper rewards.

Many DeFi projects are vulnerable to flash loan attacks due to code or logic issues. For example, some projects distribute rewards based on holdings at fixed intervals, which attackers exploit by using flash loans to purchase a large number of tokens to gain most of the rewards. There are also projects that calculate prices through tokens, which may also be affected by flash loans. Project teams should remain vigilant about these issues.

Price Manipulation

The issue of price manipulation is closely related to flash loans, mainly in two situations:

1. When calculating prices, third-party data is used, but if the usage method is incorrect or checks are missing, it can lead to malicious manipulation of prices.

2. Use the number of Tokens from certain addresses as a calculation variable, and the Token balances of these addresses can be temporarily increased or decreased.

Reentrancy Attack

The main risk of calling external contracts is that they may take over the control flow and make unintended 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; }

Since the user balance is set to 0 only at the end of the function, repeated calls will still succeed, allowing for multiple withdrawals of the balance.

Reentrancy attacks come in various forms and may involve different functions of a single contract or functions of multiple contracts. To address reentrancy issues, it is important to note:

1. Not only prevents reentrancy of a single function
2. Follow the Checks-Effects-Interactions pattern in coding
3. Use verified reentrancy modifier

It is recommended to use mature security practices and avoid reinventing the wheel. New solutions developed independently lack sufficient validation, leading to a higher probability of issues.

Security Recommendations

Project Team Security Recommendations

1. Follow best security practices for contract development
2. Implement contract upgradeable and pause functionality
3. Adopt a time-lock mechanism
4. Increase investment in security and establish a sound security system.
5. Improve the security awareness of all employees
6. Prevent internal malfeasance while enhancing efficiency and strengthening risk control.
7. Be cautious when introducing third-party dependencies, as both upstream and downstream are not secure by default.

How do users determine the security of smart contracts?

1. Is the contract open source?
2. Does the owner adopt a decentralized multi-signature?
3. Check the existing transaction status of the contract
4. Is the contract upgradable, and is there a time lock?
5. Whether multiple institutions are accepted for auditing, is the Owner's permission too large?
6. Pay attention to the reliability of the oracle.

In summary, both project parties and users should enhance their security awareness and take necessary measures to reduce Decentralized Finance security risks.