4 DeFi Security Risks Explained: Understanding Common Vulnerabilities

Vulnerabilities in DeFi contracts led to 44 separate incidents of eye-watering losses in 2022. The largest attack was against the Ronin Network for $6240,000,000 while the smallest was against Curve Finance for $575,000. These hacks continue to destabilize the DeFi ecosystem and keep more traditional and risk-averse investors out and contribute to the ongoing DeFi winter.

In this article, I summarize the vulnerabilities that led to some of the largest heists in Defi history. Much of the data and background on the attacks come from rekt.news.

Key and Wallet Vulnerabilities for DeFi Contracts

Like BitCoin, DeFi contracts rely on a system of private and public keys to identify ownership of coins. These keys are then stored in digital wallets. The authority to spend tokens or execute any contracts is based solely on the ownership of the private key; and the verification of that ownership via the owner’s public key. Best practices around key management have been learned the hard way – with the granddaddy hack of them all – Mt Gox in 2011 – showing the dangers of managing haphazardly.

In the Rekt top 25, five different networks – Easyfi, Ascendex, Harmony, Vulcan, and Ronin – suffered losses due to the loss of keys or wallets. Some of these were straightforward where not even multiple signatures – multisig – was in use. Hackers have been targeting suspected keepers of the DeFi keys with hacking and phishing attacks and so any weaknesses in this area are being ruthlessly exploited.

As a refresher, let’s look at the best practices for DeFi key management:

• Multisig – changes to the core logic of a contract and the assets of a contract need to be secured via multiple keys and tied to multiple people. That prevents the compromise of one single person or key leading to a massive loss.

  
  

• Cold storage – private keys should be air-gapped from the public internet and stored in a secure medium appropriate for a key tied to millions of dollars in assets.

Pricing & Governance Vulnerabilities in DeFi Contracts

DeFi apps rely on contract codes to modify their own contracts, price assets, and trade assets. When that contract code depends on the price of another asset or is based upon a single user’s holdings, then the contract becomes susceptible to manipulation of its underlying economics.

One example is due to Flash Loans. Flash Loans are loans that are given out for a very brief period of time and then paid back on the same block. There is no default risk – because if the loan is not paid back promptly – then the block is never written and it’s as if the transaction never happened. An attacker can then borrow huge sums of crypto to then manipulate prices tied to a contract or tied to the governance structure of a DeFi contract. This then leads to an attacker either gaining access to the internals of the contract or receiving valuable assets at a discounted rate.

PancakeBunny, Cream, and Beanstalk all fell victim to flash loan attacks. Developers should consider using multiple prices instead of a single exchange or average prices across multiple blocks to defend against this attack. More on flash loans here.

A second example is attacking an oracle. An oracle is a way to bring off-chain data – such as the price of traditional security or other assets – on-chain. If the oracle itself is easy to manipulate, then that can lead to mispricing and allow an attacker to gain assets cheaply. This style of attack was seen on the Bonq protocol where a pricing oracle was manipulated to push down the initial purchase price and then push up the liquidation price. Protections against oracle manipulation include not using an instantaneous price as well as validating the structure of the oracle itself.

As DeFi solutions continue to become more sophisticated and complex, developers will have to be very careful to understand and test the economic assumptions of their contracts.

Algorithmic Weakness and Logic Errors

DeFi contracts continue to be difficult to reason about with novel algorithms and punishing gotchas. In the early days of Ethereum smart contracts, integer overflow errors and simple permissions issues were rife. With the advent of the Vyper language and better prebuilt libraries, these errors have become fewer. The reentrancy bug that led to The Dao attack is still present though as Fei Rarii lost $80M due to a more complex case of reentrancy logic.

In another example, Compound lost over 80M via dilution due to an incorrect less than or equals sign in its reward logic. Wintermute lost 160M due to a private key that was reverse-engineered. Wintermute used a vanity key generator which ended up allowing an attacker to guess the private keys.

Protecting against algorithmic weakness is challenging and consequently, it’s the single largest class of attacks.

A few key tools are in order:

• Test-driven development with verifying high levels of code coverage.
• Building better tooling to allow development by contracts, assertions, and exceptions – similar to those built into the Eiffel language.
• Using standard libraries that are battle-tested
• Using static analyzers and paying attention to their results.
• Having a red team test a contract.

Cross Chain DeFi Attacks

Reasoning about DeFi contracts on a single chain is difficult – especially when the programming models are still so new and best practices are still evolving. Reasoning about DeFi contracts on multiple chains is much harder. Managing the authorization of cross-chain transactions is complicated and tends to be the central culprit. Developers seem to struggle with managing which function should be able to do what transaction and which are privileged and which are not. The complex interplay between chain differences leads to a minefield. In the Rekt Top 25, Qubit, Nomad, Wormhole, and Poly are all bridges between multiple chains that all suffered fifty million dollar losses or more.

Preventing cross-chain attacks requires a developer to keep a careful accounting of privileged transactions and the influence between them. I’m unaware of any, but tools that map out function interdependence in a graph would give a good insight into where cross-chain attacks could occur.

Conclusions

DeFi firms continue to innovate and create more complex contracts. Unfortunately, DeFi firms and their customers continue to incur terrible losses from security incidents. For DeFi to grow up and become more mainstream, these security issues must become less prevalent.

Also published here.