Smart Contract Security Will Kill DeFi Success…

Don’t mess with people’s money.  A lesson that DeFi Dapps and protocols are not dealing with very well.  The theft continues – mostly due to errors that are avoidable.  This amounts to shooting user adoption in the foot – self-inflicted damage.  And it continues to occur.

Theft in smart contracts that process cross-chain transactions, as well as wallet exploits, have now amounted to $1 billion in stolen crypto in Q2 and Q3 to-date.  Add that to the $1 billion stolen in Q1, and we’re talking serious loss. $2 billion in 2022.  Wow. And we still have Q4.

According to Chainalysis, 69% of funds stolen were from cross-chain bridge vulnerabilities. 

I remember a conversation that went like this, “if you had a bowl of cherries, and one of them contained poison and would kill you if you ate it, would you eat ANY of the cherries in the bowl?”  That’s what it’s starting to look like for DeFi – with exploits repeating themselves proving the point that newly developed code is in dire need of better TESTING and code AUDITS prior to deployment in production.

Stablecoin stability is first on the list

Let’s take the recent hack on Acala’s stablecoin (Polkadot parachain). It got depegged from USD due to a MISCONFIGURATION on the newly released iBTC/aUSD pool.  Seriously?  Where is the rigorous dev-to-staging-to-production roll-out process that prevents these sorts of issues from EVER happening??  Approximately $1.6 million USD in tokens stolen, and the value of aUSD went from $1 to $0.  At time of this post, approx. 2 weeks after the hack, aUSD has recovered to approx. $0.67.  Value gone. Poof!  Would you trust that? It was designed to be a liquidity pool for decentralized exchanges and DeFi protocols.  Looks like it was a liquidity pool for theft!  Would you put your assets there?

Another self-inflicted wound.  Building more fear in the stability of stable coins.  Not to mention safety of DeFi overall.  The room for bugs and depeggings of stable coins is razor thin – as in, ZERO room for error, if we’re going to regain trust in decentralized stablecoins and see widespread adoption in DeFi protocols.

It’s time for blockchain protocols to start taking seriously the state of their code as well as dev and deployment processes, including security precautions.  To borrow a wrongly-used phrase, but it’s correct in this context, “Stop the Steal!!!”

A Look At The Recent Exploits and Theft

Enough of the lecture, let’s look at what happened with the smart contracts, bridges, and wallet exploits that occurred in Q2 and Q3:

FEI Protocol hack April 2022 – Re-entrancy bug… DAO rugpull – $80 million

Essentially, FEI Protocol was hacked with a reentrancy bug in code they forked from Compound.  Most of the vulnerabilities were corrected in that code, but several remained, and who would think that taking and forking code from an existing protocol would introduce such an elementary bug? In case you’re not familiar, a smart contract can be vulnerable to this exploit  when it doesn’t follow the check-effect-interaction pattern when sending value to an address.

Who would think to check Compound’s code for such a basic error?

Well,here’s the proof that projects should ALWAYS take their code through full and thorough testing, rather than assume it’s good.  $81 million lesson.  

So, what’s happening now?  Seems the DAO isn’t really “decentralized” – and while they (the principals) voted to make those who lost money whole, they’ve re-voted to only restore SOME of the value, and taking the rest for their own.  Amounts to a rug pull.  Except they’re under no obligation to restore those funds or spend the DAO treasury to do so – so technically, not a rug pull. 

Money is a funny thing.  All integrity goes out the window in favor of greed and self-interest.

This situation shines a light on the “truth” behind DAOs – mostly that a minority actually controls the voting.  This is a total aside from the subject of this blog, but interesting to note, is the ETH move from PoW to PoS was voted on by only 13% of those eligible to vote, and 96% of those who voted, voted for the change to PoS.  Essentially 87% of eligible ETH votes were never cast.  

Nomad – Zero/Null (0x00) Address vulnerability – $181 million

Deja Vu! Didn’t this happen earlier this year with the Qubit Finance null address (0x00) hack?

Amazing that it occurred again – and this time, the theft was $100 million MORE than what occurred with Qubit Finance.  With some testing in place – taking into account common exploits, this would have been completely avoidable.  

Except with this one (vs. the Qubit hack), as hackers found out what was possible, they joined the party.  All that was required was a simple copy/paste operation, utilizing the original hacker’s transaction calldata, and replacing the original address with a personal one.

Bing. Bang. BOOM.  $181 million stolen.  $33 million was returned from white hat hackers.

Get the entire hack explained at Halborn’s blog post.

Harmony’s Horizon bridge – compromised private keys – $100 million

Horizon is Harmony’s bridge between ETH and the Binance Smart Chain.  The stolen amount represents two-thirds of the bridge’s total capital, and impacted 50 thousand wallets. 

The bridge allows users to transfer assets like tokens, stable coins, NFTs, etc. between the two platforms.

The bridge was exploited through the theft of two private keys.  Interestingly, these private keys had both a passphrase and a key management service that encrypted each of them.  And no system had access to any plain text keys.

Somehow the hacker was able to access and decrypt multiple keys – and this allowed the hacker to create a transaction that extracted $100 million from the bridge and also confirm the transaction using the two accounts they gained control over.

Tornado Cash was then used to launder the stolen tokens.

Evidently there are 5 validators on the bridge, but the multi-signature scheme only required two of the five to approve a transaction.  That has since been modified to require four of the five.

What could be done (and checked/verified in the future)?  

Have several validators approve any transaction, and take steps to ensure that the compromise of one private key doesn’t compromise the security of any of the others. For example, make sure storage of keys is separated, protecting them with unique pass phrases and other encrypted security means, should be a requirement in bridge validator implementations.

Axie Infinity Ronin Bridge Hack – compromised private keys – $650 million

This hack wasn’t even noticed until a full SIX DAYS afterwards, when a user couldn’t withdraw about $5k ETH from the bridge.  How much theft can occur undetected in six days?  Apparently A LOT.  This is one of the largest thefts in the history of Crypto.

In this exploit, hackers compromised five validator node private keys.  And five is the number of validators needed to approve a transaction.  So how did this happen?

Turns out that a year ago, Axie DAO gave access to Sky Mavis (developers of Axie Infinitie) to sign off on transactions on its behalf, thereby mitigating user volume apparently.  However, this access was never revoked – and that eventually led to the backdoor exploit.

I know wordpress admins that are more careful if not paranoid about providing temp admin rights to their website – let alone the keys to hundreds of millions of dollars!

It’s worth noting that nine validators does NOT make for a decentralized protocol, as is evidenced by both this hack and the Harmony bridge hack (which had five validator nodes total).  Expanding that to 21 validator nodes (as promised by Axie Infinitie is better, but questions still exist:

• Does a mere 21 validator nodes constitute “decentralization”? 
  (check out our recent post on the centralized vs. decentralized dapp debate)
• How are the private keys generated?  
• Where are they stored?  
• Is there a single point of failure or access to generate more keys for those validator nodes?

All good questions!

Beanstalk Governance hack via flash loan – $181 million:

Beanstalk is an Ethereum stable coin protocol, and it uses a decentralized governance protocol.  Available in this protocol is an emergency “commit” function that requires two-thirds majority to allow, and it is processed within 24 hours, rather than going through the normal process.

I guess the question to ask is, “how is voting power determined?”  And here is where the issue lies.  The hacker had to control two-thirds of the governance vote, so how did that get influenced?  Beanstalk governance voting is determined by the donations to Beanstalk protocol’s Diamond contract.

In a stroke of genius, the hacker waited the 24 hour period, the hacker used a flash loan to make a large deposit to the Diamond contract, obtaining 79% of the governance protocol’s vote.  With this power, the hacker could unilaterally approve their proposals via the emergency commit function.  They then stole funds, and also paid off their flashloan.  In the end the hacker netted a profit of $76 million after paying off their flash loan.

The post-mortem.  Turns out that the 24-hour waiting period, designed to catch these sorts of requests, went unnoticed.  On top of that, the Beanstalk smart contract auditor, DID NOT audit the governance smart contract before it was deployed.  OOPS!

Again, all avoidable – but processes must be followed.  You can set things up to be secure, but if you don’t adhere to what you’ve got set up – it compromises the entire process, and leaves things open to compromise.

Solana’s Crema Finance also suffered a hack via flash loan attack that resulted in $9 million theft.

Curve Finance was hacked via DNS hijacking – $570 million

The DNS for Curve Finance was hijacked, and the hacker gained access to Curve’s DNS and modified the address it went to.  Most of the funds were recovered by Binance and returned, resulting in a relatively overall small loss.

But it begs the question again on the security front.  Yet one more place where there is a single point of failure should a Dapp get compromised.

Solana’s Slope wallet (not open source code) – wallet exploit – 8,000 wallets drained and $8 million stolen

It’s not just smart contracts, or bridges.  And it’s not just open source protocols that get hacked.  It’s also wallets, as about 8,000 users have now experienced, when the Slope wallet got hacked in a way that led to the draining of wallet balances.  Right in front of people’s eyes!

So what happened?  Was it a clever genius-level hack?  I wish!  But it wasn’t.  Turns out it was a complete “dereliction of duty” of the Slope team regarding their attention and care about security practices.  It’s almost embarrassing to say, but here it is:  The hack was due to Slope sending users’ seed phrases in plaintext to a centralized server.  It brings into question the experience level of the Slope team that they would create a wallet – that holds people’s money, and not be paranoid about security – but to leave the “holy grail” of wallet security – the SEED PHRASE exposed like that??  That is a complete lack of competence. And I do NOT apologize for calling it out.  It not only impacted the Slope wallet, it also impacted some Phantom wallets as well.  It literally boggles the mind!

What steps can be implemented to eliminate the rampant theft and restore trust in DeFi protocols, cross-chain bridges, and wallets?

Everything outlined above is solvable and avoidable in the future.  DeFi protocols, bridges, and wallets risk everything by not cleaning up their act.  Hearing about all of these exploits, if you were someone who hasn’t yet put their toe in the crypto waters, would you?

I return to my story about the bowl of cherries.  If one or two could kill you if you eat either one, would you eat ANY from that bowl?  OF COURSE YOU WOULDN”T!

Rather than cry and scream about regulations getting imposed – let’s clean up our development act, and start making it tough to hack protocols and platforms!  Let’s start enforcing good practices and start treating customer’s money with respect.  It will take the community to police this and to emerge stronger.

Some Ideas for improvements based upon the exploits:

1. Implement more thorough testing processes that take into account common exploits.
2. Establish stringent processes to handle migration from Dev to staging to production…
3. Proactively incorporate the following:
   1. Audits
   2. Bug Bounty programs
   3. Penetration Testing

There are a few other items that need to be addressed and answered:

• What is sufficient decentralization to even use the term “decentralized”?
• Is there permission management that is enforced and audited regularly?
• Has adequate monitoring of bridge or protocol activity been established so theft doesn’t go on unnoticed?
• NEVER prioritize speed over security.  You can bet you’ll live to regret it.

Finally, selecting and working with a development partner who understands and implements solid development and testing practices is critical to get the speed of development without compromising security by allowing flawed code onto the blockchain.  

At AktaryTech we live and breathe blockchain development, committed to helping accelerate the growth of functionality for blockchain protocols and platforms.