Common Security Vulnerabilities in DeFi and Preventive Measures

Recently, a security expert shared a DeFi security lesson for community members. He reviewed the significant security incidents that the Web3 industry has encountered over the past year, discussed the reasons behind 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 include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function problems, business logic vulnerabilities, private key leakage, reentrancy, and more. Below, we will focus on flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but when exploited by hackers, they can borrow a large amount of funds at no cost, return it after executing arbitrage, and only pay a small amount of Gas fees to gain huge profits.

In the past two years, issues with flash loans have been frequent. Some projects appear to offer high returns, but in reality, the quality of the project teams varies widely. Even if the code itself is free of vulnerabilities, there may still be logical issues. For example, some projects distribute rewards based on the number of tokens held by the holders at a fixed time, but attackers can use flash loans to purchase a large number of tokens and obtain most of the rewards when they are distributed. There are also projects that calculate prices based on tokens, which can be influenced by flash loans. Project teams should be vigilant about these issues.

Price Manipulation

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

1. When calculating prices, third-party data is used, but incorrect usage or lack of verification leads to prices being maliciously manipulated.

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

One of the main dangers of calling external contracts is that they can take over the control flow and make unexpected changes to data by calling functions.

There are many ways for reentrancy to exist in different contracts, which can be combined with different functions of the contract or functions of multiple different contracts to carry out a reentrancy attack. Therefore, when addressing the reentrancy issue, it is important to pay attention to:

1. Not just preventing the reentrancy issue of a single function

2. Follow the Checks-Effects-Interactions pattern for coding.

3. Use a time-tested anti-reentrancy modifier

The most feared thing is reinventing the wheel, writing everything ourselves. There are many best security practices in this field that we can use, and there is no need to reinvent the wheel at all. When you create a wheel, it has not been thoroughly validated, and the probability of problems occurring at that time is clearly much higher than using a very mature and well-tested one.

Security Recommendations

Project Party Security Tips

1. Contract development follows best security practices.

2. Contracts can be upgraded and paused: Many attacks do not transfer all the coins at once, but rather execute multiple transactions. If there is a relatively sound monitoring mechanism, it can be detected. Once detected, if the contract can be paused, it can effectively reduce losses.

3. Use of time locks: If there is a time lock, assuming it is 48 hours before completion, during this time many people can notice that the creator has updated a mint method that everyone can use. Those monitoring will know that the project may have been hacked and can notify the project team to make changes. Even if they notify them, no one may take action, but at least they can withdraw their portion of the funds to ensure their profits are not affected. Therefore, if a project does not have a time lock, theoretically, it increases the probability of problems occurring.

4. Increase investment in security and establish a complete security system: Security is not a point, nor is it a line; security is a system. Don't think that as a project party, having the contract audited by multiple companies means there are no issues; you must consider various risks that could lead to financial losses. Try to conduct risk modeling and gradually eliminate most of the risks, while the remaining risks should be acceptable and within the tolerable range. Security and efficiency cannot be achieved simultaneously, so certain trade-offs must be made. However, if you completely neglect security and do not invest in it, being attacked is quite normal.

5. Increase the security awareness of all employees: Raising security awareness does not require much technology. In this environment, just asking a few more questions about why and thinking a little more can help avoid many issues.

6. Preventing internal malfeasance while enhancing risk control alongside improving efficiency: For example, whether the contract's Owner is single-signature or multi-signature, and whether to use a time lock, all need to be considered.

7. Third-party introduction of security: As a part of the ecosystem, project parties will have their own upstream and downstream. There is a principle of "default upstream and downstream are insecure" in terms of security. Validation must be done for both upstream and downstream. It is very difficult for us to control third parties, and the exposure to security risks is particularly high, so great care must be taken when introducing third parties. Contracts are open-source and can be introduced and called; if the contract is not open-source, it should never be referenced.

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

For ordinary users, determining whether a project is safe mainly looks at the following six points:

1. Is the contract open source: We absolutely do not engage with projects that do not have open source contracts, because we have no way of knowing what the contract entails.

2. Whether the owner uses multi-signature and whether the multi-signature is decentralized: If multi-signature is not used, we cannot assess the project's business logic and content. In the event of a security incident, it would be impossible to determine if it was caused by hackers. Even if multi-signature is used, it is necessary to evaluate whether the multi-signature is decentralized.

3. Existing trading situation of the contract: Especially since there are many phishing scam projects on the market, they may create a relatively similar contract. At this point, we need to look at the contract's deployment time, interaction frequency, etc. These are all criteria for assessing whether the contract is safe.

4. Is the contract a proxy contract, is it upgradable, and is there a time lock: If the contract cannot be upgraded at all, it is too rigid. It is still recommended that the project's contract is upgradable. However, the upgrade should be approached with care. When there are upgrade contents or important parameter changes, there should be a time lock in place, providing everyone with a time window to assess whether the real upgrade is harmful or beneficial to users. This is also a way of being open and transparent.

5. Has the contract been audited by multiple institutions ( Do not blindly trust auditing firms ), Is the Owner's permission too large: First, do not only trust one auditing firm, as different auditing firms and auditors have different perspectives on issues. Secondly, check whether the Owner's permissions are too large. A normal project Owner's permissions should be controllable, so there won't be too many high-risk operations, and operations will also use time locks to let users know what the operations are.

6. Pay attention to the oracle: If the project uses a leading oracle available in the market, there basically won't be any major issues. However, if it uses a self-built oracle, or if it uses an oracle that allows feeding prices by casually collateralizing some tokens, then caution is warranted. When you discover that the oracle may have some issues, or there is a possibility of manipulation, you should not participate, even if the project's returns are high.