Decentralized Finance / DeFi Security Recommendations

Decentralized Finance / DeFi Security Recommendations

In recent months, there have been a number of attacks on prominent DeFi projects:

  • bZx, a leveraged trading platform was attacked two times (pt.1, pt.2) for around $900k  
  • MakerDAO, a decentralized stablecoin was exploited for about $8M
  • Synthetix has also suffered oracle manipulation attacks.
  • dForce/LendF.me suffered a re-entrancy attack for $25M (later returned)

While these attacks are real and significant, we also believe that they are preventable. Much of the lack of attacks on blockchain applications in earlier years was not because the projects were secure, but because the stakes weren’t high enough for attackers. Now as user adoption and the incentives to attack grow, security needs to grow with it. 

How should DeFi projects be secured? We think they should take the following steps:

Audits Should Cover Economic and Financial Attacks

Some of the DeFi attacks successfully carried out recently were the result of bugs in the smart contract code, but many of them did not involve any code logic errors. Instead they took advantage of oracle price manipulations which weren’t protected against in the applications affected. As DeFi projects often rely on other projects for liquidity or price feeds, they may be particularly vulnerable to this type of attack. 

Any proper smart contract audit, but Defi project especially, should cover the possibility of attacks on economic incentives as well as financial attacks such as oracle price manipulation. These vulnerabilities have as much potential as any syntax error or mis-implemented check to drain funds under the contract’s control. 

Edge Cases Need to Be Strongly Considered

Edge cases in smart contract audits refer to events which may occur under extreme conditions such as an attacker having access to a very large pool of capital, or if the network is extremely congested and 3rd party oracles cannot be updated correctly. 

These situations used to be considered low probability, and projects would often not adequately protect against them. Yet we can see from the bZx attacks and the MakerDAO Black Thursday event that they need to be considered for.

One major factor which has made edge cases more significant is Flash Loans. These are short-term loans that exist for just one transaction. Borrowers can borrow huge amounts of crypto assets as long as they return them, along with a fee, in the same transaction. 

Flash loans level the playing field for financial attacks and make them more profitable. Whereas a lone hacker may have had the technical capability to execute a financial attack before flash loans, unless they also had a large capital reserve they may not have been able to move the market enough to make a significant profit. Now anyone with the technical capability to execute a financial attack also has access to enough capital to execute it.

The MakerDAO Black Thursday event also clearly illustrates that other edge conditions such as extreme price drops, or network congestion are not merely theoretical scenarios but very real, and may often happen at the same time. As the price of Ether dropped severely, network congestion prevented MakerDAO’s price oracles from behaving correctly. This caused a series of failures which resulted in DAI being undercollateralized to the tune of $4 million USD worth of ETH. 

The lesson for any DeFi project going forward is that your application cannot merely brush off edge cases, but most properly consider for all those edge conditions to occur, sometimes all at once. If your application can’t handle extreme conditions, it cannot handle real financial value on mainnet. 

Move Slow and Test Things

With funds on the line from day one, DeFi applications need to have security best practices baked in. That means using safe libraries, high test coverage, hiring auditors well before mainnet launch, and having emergency procedures ready. Progressive rollouts are also a good idea so that security issues can be spotted when the cost of an attack is still relatively small. Besides auditing for coding errors, economic and financial attacks also need to be considered. 

In the case of dForce/LendF.me, development was rushed, with little to no precautions taken before going to production. It seems that the project may have copied an early version of Compound Finance’s code, and then added additional functionality without adequate testing or a security audit.

The growth of DeFi as an application space is an extremely exciting one. It shows some of the first major product-market-it in the blockchain industry. However as assets locked in DeFi grow, the incentives to attack these projects grows as well. Security can no longer be an afterthought.

What Can You do?

Auditors and developers need to adapt to the new security environment of today’s interconnected DeFi ecosystem. The composability of DeFi projects means the failure of one project, such as MakerDAO, can lead to ripple effects on projects that integrate it. Audits should consider not just the project itself, but its interactions with other projects. 

Edge cases should also be strongly considered. DeFi innovation such as flash loans have made financial attacks much easier, and extreme network conditions as we saw on March 9th, should always be accounted for.