🚪 Reentrancy Returns — Build Blockchain Issue No. 92

in #crypto • 4 years ago



Please enjoy Issue Number 91 of the Build Blockchain newsletter. To receive these in your inbox every Sunday morning, subscribe for free.


In the past week, there have been two notable hacks of Decentralized Finance smart contracts running on Ethereum, both involving a token called imBTC. The incidents have renewed debates about the responsibility of those who build— and those who use— DeFi apps. They've even led some to question the viability of DeFi in general, given the constant threat of a hack leading to irrecoverable loss of funds.

In this edition of Build Blockchain, we'll take a look at the technical aspects of the incidents and discuss what builders and users should do to protect themselves. We'll also touch on what these hacks say more broadly about the adoption and maturation of DeFi.

imBTC and ERC-777


The token involved in both of these incidents is called imBTC. It is similar to WBTC in that it's a token pegged to Bitcoin via BTC held custodially by a trusted third party. It is implemented on Ethereum using the ERC-777 standard, which adds features to the more ubiquitous ERC-20 standard while retaining backwards compatibility. Link.

One of the features of ERC-777 made both of the attacks possible. While most ERC-20 token transfers are simple atomic state updates, ERC-777 enables users to register a "hook" that is triggered when tokens are sent or received. There's actually nothing wrong with this feature per-se, but in both attacks, it had not been properly accounted for by the DeFi protocol which was exploited. This allowed the hackers to execute subsequent transactions before their first transaction had completed, while the DeFi contracts being attacked were in an unexpected state.

This kind of vulnerability exists because of a computer science property called "reentrancy." If that sounds familiar to you, it's because the hacker behind the infamous attack on "The DAO" used the same technique.

Draining A Uniswap Pool


The first hack involved draining the imBTC liquidity pool of the Uniswap decentralized exchange. In total, $300,000 worth of tokens were taken. Interestingly, this particular Uniswap exploit has been known about since a 2018 audit, wherein the exact attack used this week was spelled out by the auditors. Link.

Uniswap has grown as a popular exchange despite this exploit because the overwhelming majority of ERC-20 tokens are not vulnerable to it. Unlike many other DeFi protocols, Uniswap truly is decentralized. The contracts are truly autonomous, with no administrative privileges or pause functions, and users can trade any token that is ERC-20 compatible.

Unstoppable code is, of course, one of the properties that makes smart contracts so interesting. It gives us the ability to build systems that no one can modify once they're running. As usual, though, the flip side of a strength can manifest as a weakness. We saw that in this case. Despite the fact imBTC was vulnerable to a known weakness in the Uniswap architecture, users which had chosen to trade the token couldn't be prevented from doing so— not even for their own good.

The dForce Debacle


The second attack was for significantly more money— a whopping $25 Million worth of various tokens was drained from the smart contracts of the dForce lending protocol. Leveraging a reentrancy bug, the hacker made it seem as if he held much more imBTC in dForce than he did, then used this fake supply as "collateral" to take out "loans" of various other assets supplied by users.

Image

In a surprising twist, the hacker made a mistake that revealed his or her IP address. Presumably fearing legal consequences, the hacker ended up returning all of the stolen funds to dForce after several days of back and forth negotiation with the company. Emilio Frangella wrote an excellent breakdown of the ordeal in The Defiant. Link.

Who Pays For Best Practices?


While the dForce hacks at least had a happy ending, many were critical of the quality of the company's contracts in light of the attack. Among the criticisms, some pointed out that the contract failed to adhere to the "checks, effects, interactions" pattern, a well established best practice in smart contract code aimed at thwarting exactly these kinds of exploits.

Who is responsible for ensuring the security of smart contract apps— the developers who create them or the users who deposit their money into them?

There is no doubt that DeFi protocols should be extensively audited before launching, preferably by two or more auditors, and that contract code should be developed carefully and slowly by experienced teams. While this definitely should be the case, it's not clear exactly how the ecosystem can afford it.

Audits and smart contract experts are expensive, and we haven't yet worked out what DeFi business models look like. The community rightly demands those building DeFi apps "take responsibility," but it also demands systems that are "fully decentralized," generally meaning there is little opportunity for the entities building them to earn a profit. We find ourselves, then, back at a common problem in the crypto ecosystem: how do we adequately fund important public goods?

Audits also aren't bulletproof. The dForce protocol was professionally audited and the exploit was still missed. As mentioned, the Uniswap exploit used in this attack was known because of an audit, yet users chose to trade it on the platform anyway. The truth is, users must also take some responsibility for the money they are putting at risk. That starts with a simple principle: never put more money into DeFi than you can afford to lose. Everyone says this, but clearly not everyone listens.

Will DeFi Deflate?


Some have argued that unstoppable code means these systems are simply too risky to use. All software has bugs, but these bugs can't be fixed, and might cost you millions. One possible way this situation could improve is through developer tooling. Languages that allow you to write provably correct code add friction for developers and have high learning curves. Still, they might be begrudgingly adopted if the money at stake continues to grow. That brings up the question: will DeFi continue to grow, or will the risk of hacks irreversibly damage its appeal?

Image

Well, listen, I'm a software engineer and I'm excited about smart contracts, so you need to take my answer with a grain of salt. Unsurprisingly, I think decentralized finance will continue to grow. But for now, it's still tiny. Even Compound, a "popular" lending protocol, has a mere 27,000 users according to Dune Analytics. If I'm being intellectually honest, I have to acknowledge the possibility this will always remain a very niche community.

Image

If DeFi doesn't take off, though, I don't think it will be because of hacks or bugs. Software has been eating the world for 50 years. It has been buggy and vulnerable the entire time, but it has continued unabated in its ascent nonetheless. If costly bugs or high profile hacks were enough to slow this progression, it would have ended decades ago. In spite of these issues, software will continue to eat the world, and smart contracts make financial markets digestible.

All that said, if you're participating in this ecosystem, be cautious and responsible, both as a user and builder. It would be nice, after all, if we could manage to go a month or two without a large sum of money getting stolen.


Please enjoy Issue Number 91 of the Build Blockchain newsletter. To receive these in your inbox every Sunday morning, subscribe for free.

Sort:  

The community rightly demands those building DeFi apps "take responsibility," but it also demands systems that are "fully decentralized,"

I think this line right here is the cause of most of the issues in the entire blockchain space. Decentralization means personal responsibility. People want the former but not the latter, which is just not possible.