imBTC Uniswap Pool Drained for ~$300k in ETH

April 18, 2020 - 4 Min Read

Earlier today, we saw the exploitation of a liquidity pool on Uniswap for imBTC - a wrapped version of Bitcoin created by imToken and the Tokelon DEX.

loading 1251423721476116480

The exploit allowed the attacker to drain roughly $300k worth of value due to a reentrancy attack which allowed funds to be drained in a similar fashion to what happened with The DAO back in 2016.

Here's what you need to know:

  • The reentrancy attack was possible due to imBTC using the ERC777 standard
  • Uniswap v1 does not protect against reentrancy attacks for pools using the ERC777 standard
  • Trading on imBTC was halted immediately following the attack
  • The BTC backing imBTC tokens were not affected
  • Tokelon will release a post mortem in the following days.

What Happened?

Without going too deep into the weeds, the attacker was able to call the Uniswap smart contract to withdraw funds before the external balance could be updated, effectively creating a cycle in which all the tokens in the contract could be purchased for pennies.

loading 1251448415503908864

As we mentioned above, this was largely due to the ERC777 token standard - namely because of "hooks" or payable functions that allow contracts to execute code when they receive tokens (instead of only ETH with the ERC20 token standard).

loading 1251505392913350659

This issue was described in depth on Conensys's audit of Uniswap, which can be read in detail here. For your convenience here's a look at what happened using the example from the audit.

"If token allows making reentrancy on transferFrom(address from, address to, uint tokens) function by someone except the recipient, then all the liquidity funds might be stolen. For example, if token calls callback function of from address. It's irrelevant if reentrancy is done before or after the balances update."

Why Should I Care?

This attack brought to light a number of discussions regarding the ERC777 standard and Uniswap itself. For starters, Uniswap has expressed that they do not support ERC777 but their UI fails to mention this - leaving this knowledge on the shoulder's of the liquidity pool creator.

loading 1251402613318393857

While supported in Uniswap V2, this type of attack was destined to happen to someone, and it seems that the imBTC pool was the prime choice for the attacker. Most recently, we say imBTC supported as a part of the BTC++ Pie from PieDAO. This attack lead to BTC++ trading being halted within the pool as well.

loading 1251417399775105024

The wider narrative here is that while this attack was unfortunate for imBTC, many are pleading that ERC777 as a standard should not be dismissed because of one exploit. The ability for contracts to execute code when interacting with tokens has a number of benefits including transaction efficiency and the prevention of users sending funds to a contract address and having them lost forever. Here's a great thread describing this thought.

loading 1251505373992845317

In summary, this attack goes to show that token issuers need to stay on their toes when accessing the endless financial primatives being discovered on Ethereum. If anything, this attack will further battle harden DeFi, and we're excited to cover the rest of this story as it unfolds in the coming week.

To stay up on all new updates regarding the situation, we recommend following the imToken project here.

Written by


Follow contributor
See all articles by contributor