DeFi Security Audit: How to Prevent Your DeFi Project From Hacking?
Decentralized finance is successfully conquering the investors’ trust. Yet, DeFi security issues regarding the growing number of recent protocol attacks arise a lot of controversies about the reliability and safety of decentralized finance technology.
In this article, we want to tell you how to prevent DeFi hack, secure your DeFi protocol, and help you to perform DeFi audit.
Recent DeFi hacks
The TVL locked in DeFi grows exponentially and has exceeded $12B recently according to DeFi Pulse. Such a fast-developing market clearly gathers a lot of attention from hackers who want to make a fortune.
Yet, unfortunately, In Blaize we watch a lot of examples where the attack was made due to security neglect by protocol owners. Let’s look through some notable DeFi protocol hacks from the beginning of 2020.
dForce attack
One of the high profile attacks was made in April on dForce protocol and worth $25 mln. The protocol suffered from the reentrancy attack on the smart contract using ERC-777 token standard.
dForce uses lendf.me decentralized protocol developed by the dForce foundation to enable lending on the Ethereum platform. As we know, the ERC-777 token standard was aimed to extend the capabilities of commonly used ERC-20 and has no vulnerabilities. However, the combination of ERC-777 and Lendf.me contracts made the attack possible.
The ERC-777 token contract has the ability to inform the sender or receiver about the tokens’ transfer. If the receiver is a smart contract (in the face of Lendf.me protocol), the contract may choose how to “answer” to certain sent. One of those reactions may be reentering the token contract and causing another sent. This feature allowed the attack to happen and take approximately all funds out of the protocol.
Worth noticing, the dForce contract pattern has let’s say “so-similar” structure to the earlier Compound contracts. We are sure there is no need to remind, that coping other protocols’ codes will not prevent your DeFi project from hacking.
Harvest attack
DeFi protocol Harvest attack took place a few weeks ago and was one of the most recent violations. Unlike in dForce example, Harvest suffered from the smart contract vulnerability reflected in a lack of arbitration function moderation.
In further explanation, the hacker detected the weakness in the arbitrage opportunity while using a flash loan option on the Uniswap (v2). In order to perform the attack, he manipulated the value of stablecoins on Curve.fi protocol.
The hacker exchanged $10 worth USDC for USDT to grow the value of the second. Then, transferred the amount to Harvest finance in exchange for fUSDT. After that, he made the same moves in the reverse order – USDT to USDC in order to lower the price of USDT collateral Tether.
As a result of such an attack, the hacker withdraws more coins than he deposited and so drains the pool. The action was repeated several times and led to $24 million loss in stablecoins.
Harvest protocol hack has significantly influenced its TVL and general community trust to the protocol. The total value locked in Harvest was cutted more than twice along with the same fluctuation of the FARM (Harvest Finance token) price.
DeFi attacks classification
Due to the impressive amount of “a big win” attacks, we can, unfortunately, even classify those. Rather if there is no same DeFi protocol hack, we can still notice a certain similarity in the protocol’s vulnerabilities.
Code vulnerability
The first type of DeFi protocol hacks is performed simply due to coding mistakes. Those arise out of carelessly performed security audits or even unchecked smart contract vulnerabilities. The most extensive list of existing contracts’ weaknesses can be found here.
Want to know how to defend your protocol from common smart contract weaknesses? Read further in this article.
Unfortunately, a lot of blockchain projects owners decide to run the project with insufficient coverage of unit tests and ignore conducting smart contract security audits. This considerably higher the possibility of an attack and money loss.
I am and always will underline the importance of smart contracts auditing. Do not try to reduce the development time trying to reduce the time for audit or full test coverage. Remember, if you don’t check your project, the hacker surely will!
Sergey Onyshchenko, CEO of Blaize
Smart contract logic
The next type of DeFi project hacking does not deal with the standard code vulnerabilities, but the whole smart contract logic. We can often see the opinion that the proper contract trial in a testnet may surely reduce the possibility of such an attack, yet not for someone who does not see it.
Broadly, there might be an opportunity for hacking that auditors or protocol developers do not see due to a lack of experience and knowledge of business processes. The knowledge of traditional financial instruments and its application is a must while dealing with such a sector as DeFi.
Find more insights In TOP THINGS to Know to Develop a SUCCESSFUL DeFi Project
This type of hacking opportunity is purely shown in the Harvest example. The arbitrage opportunity hacker used, was not laying in the code quality or security audit refusal. Harvest Finance attack brought out such important questions as the vulnerability may not always be in a contract but in the protocol infrastructure.
Private key loss
Private key ownership is an important subject to think of. To clarify, the private key to your dApp is created by you (the project owner). The developers’ team or online generators, or any third party do not create the private key.
In Blaize, we have a common established practice for such – our team delivers a completed project and prepares the whole documentation, which describes the complete deployment and project setting up process. So that the customer will be the only owner of the private key.
Consequently, it is very important to keep this in mind and do not give access to it, as long as its owner may cause the kill function or withdraw the whole money from the dependent contracts in a second. In further research, this type of DeFi attack is so similar to the traditional social hacking method.
We often saw examples, when a protocol owner creates something like a protocol administrator positions and gives the private key to those. Unless those authorities have “limited” access to the key and therefore smart contract functions, Blaize developers do not recommend to introduce such practice into your protocol governing.
You, as a project owner, should be very careful while planning the administrative roles in your project. Build the system in such a way that even though one of the admins’ accesses will be compromised, the whole system will not suffer from the hacking attack.
Take into account which methods of your smart-contracts are left public (available for ordinary users) and which are accessible for your admins and protocol operators. Do not give all the power to the single operator.
Many of this and other important issues should be discussed with you during the discovery stage of your project. Every solid blockchain development company has to warn you of possible risks and their mitigations. Find out more on how to choose a reliable blockchain contractor for your project in our thorough guidelines.
Blaize developers recommend using the OpenZeppelin Defender tool kit. It allows users to safely store the admin keys and automate the operators’ actions.
Double trouble hacking opportunity
The issue of Parity Library would be a good example of what the “random stranger” can do if he gets access to your private key. Just to remind, this “accident” caused a block of 587 Ether wallets with a total amount of 513,774.16 Ether loss. That money are imprisoned in a smart contract until today.
The important thing is that the Parity “attack” deals with another common vulnerability such as system’s logic and infrastructure. Hence, the lack of acknowledgement and awareness of the problem created this hacking opportunity.
Additionally, the Parity contracts were audited several times by different subcontractors. This extra underlines the thought that the audit itself is not the point, the team of experienced developers with a deep understanding of the core system architecture and logic is the thing you should look for.
How to protect your defi project from hacking?
Well, there are enough vulnerabilities to be detected in the existing DeFi projects. Yet, in Blaize, we want to help you prevent those and tell how to improve DeFi protocol security.
1. Full unit tests coverage
Unit tests are an inseparable part of any finest project testing. Those help to detect the functionality problem in separate parts of the contract and eliminate them at the very beginning. The important thing is that the contracts require full unit test coverage, not just 60{42b5f59b3ab5133d6097ddc47ebce2180046fc8c7e54102a39597d40d1358fb0} or 70{42b5f59b3ab5133d6097ddc47ebce2180046fc8c7e54102a39597d40d1358fb0} covering “the most important parts of code”.
2. Smart Contract Security Audit
Yet, if you performed the tests for all methods, classes and modules, it still does not give a guarantee that your contract is perfect. The whole unit test coverage cannot define all possible paths and combinations the user will hit, that is why security audit has to be considered as the next step. Audit helps to detect uneven and unexpected vulnerabilities of smart contracts before project deployment and therefore, prevent DeFi hacking.
3. Secondary auditing
The thing to understand is that one audit before project deployment is not enough and dForce protocol hack is a perfect example of this. Although the ERC-777 token standard is considered as less vulnerable it does not mean its integration with Lendf.me will be completely smooth. The same stays for the introduction of imBTC (used in this attack as well). If they had audited all possible functions, they could have avoided such an unfortunate experience.
4. Code uniqueness
Staying with the dForce example, we can surely say that copy-pasting code from other protocols is not the best idea. Simply, if you do not fork the whole project, you will try to “fit in” separate parts of the code, which will often be incompatible with what you already have. This will be the main reason for future exploits.
5. Contracts’ access protection
In order to prevent unnecessary private key access or protect your DeFi protocol in case of key loss, we highly recommend using the multisig scheme. There are two ways how Blaize developers implement this – the first is to create a separate multisig contract and the second is to create the multisig logic within your protocol.
Want to implement multisig scheme to protect your DeFi app from key loss or unwanted access? Contact Blaize for further discussion!
The multisig contract requires (n) amount of signatures out of (m) amount of proxy users (for ex. 3/ 5) to approve the transaction or protocol operations. So in case of key loss or unwanted access by a third party, the contract will be safe. Moreover, lost keys can be eliminated and/or replaced.
6. Experienced DeFi developers team
As you can see, it is necessary to think of cybersecurity issues even before the project development. Thus hiring a team of experienced blockchain developers with accurate knowledge of DeFi project vulnerabilities and specifications is highly required. Blaize skilled engineers are able to check your project from variable angles including security audit services which will surely protect your DeFi project from hacking.
7. Turn to community
As the final step, Blaize developers recommend turning to your protocol community. Conducting all those steps to eliminate existing security risks is a crucial thing to do, but to enhance the result, you can engage a dedicated audience to help you. Providing bug bounty will encourage users to report any detected problem. Thus, you benefit from both improving user experience within the protocol and successfully defend from DeFi hacks.
Conclusion
DeFi is surely one of the most powerful sectors of today’s crypto. This is also an attractive place to invest and considerably increase your capital. Yet, nothing ventured, nothing gained so every profit meets inconveniences on its way.
As you can see, there is a list of such inconveniences and vulnerabilities in terms of DeFi security. We believe any project owner should be aware of them and control its elimination on time.
In Blaize we have dealt with a number of DeFi projects, that is why our developers are able to deliver a competitive and secure DeFi app on the market as well as conduct DeFi hacking audit. Build your own successful and hack resistant DeFi project with Blaize!
Post author
Aleksei Korobeinikov
CTO of Blaize & Blockchain Solutions Architect
Expert on blockchain systems research & development