Ensure the security of your smart contracts

One more problem with ERC777

Author: Daniil Ogurtsov
Security researcher at MixBytes
Recently, while working with one of our clients, we’ve discovered an intriguing bug that could potentially serve as an attack vector for some DeFi projects. This bug is specifically associated with the well-known ERC777 token standard. Furthermore, it is not just simple reentrancy commonly observed in well-known hacks.
This article provides a comprehensive explanation of ERC777, covering all the necessary details. There is a scarcity of resources that delve into the specifics of ERC777 tokens, making this article a valuable and detailed guide for individuals interested in gaining in-depth knowledge about this token type.

In the final part of the article, we will explain our recent finding.
The attack vector in short
This bug takes advantage of the ERC777 feature that enables setting a hook receiver. By exploiting the ability to make arbitrary calls in a target contract, a malicious caller can call the ERC777 registry contract and assign a specific hook address to the target contract. As a result, whenever the target contract receives ERC777 tokens in the future, the attacker’s hook smart contract will be triggered. This hook can be utilized in various ways: either for reentrancy attacks to steal tokens or just to revert, thereby preventing the target contract from sending or receiving ERC777 tokens.
ERC777 and its hooks
What is ERC777
ERC777 is one of the token standards with hooks on transfers.
Described here: https://eips.ethereum.org/EIPS/eip-777

The primary motivation behind implementing ERC777 tokens lies in their ability to mimic the behavior of native token transfers. By triggering smart contracts upon token reception, developers can execute specific logic to enhance functionality and create more dynamic token interactions.
However, these additional calls during transfers set ERC777 apart from ERC20 tokens. These hooks introduce a new attack vector which can potentially affect smart contracts that are not designed to handle additional calls during token transfers. This unexpected behavior can pose a security risk to such contracts.

Here is the list of some ERC777 tokens on the Ethereum mainnet with some liquidity:

When hooks happen
ERC20 tokens just update balances during transfers.
But ERC777 tokens do it this way:

  1. Make a hook call to an address chosen by the token sender
  2. Update balances
  3. Make a hook call to an address chosen by the token receiver

It is well illustrated in the VRA token:
Source: https://etherscan.io/address/0xf411903cbc70a74d22900a5de66a2dda66507255

Now, let’s examine the code responsible for these calls.
As you can see:
  1. this function reads so-called implementer from _ERC1820_REGISTRY
  2. if the function finds an implementer, such an implementer is called

Let´s investigate this Registry and find out what implementers are.
Registry and implementers
All ERC777 tokens are linked to the Registry contract: https://etherscan.io/address/0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24.

This address is used by ERC777 tokens to store preferred hook receivers. These preferred hook receivers are called “interface implementers”.

It means that Alice can choose Bob as her interface implementer. Bob will receive hooks if Alice receives or sends ERC777 tokens.

Alice can manage different hook types. So, she can choose Bob as an interface implementer as long as Alice sends tokens and she can choose Tom only when Alice receives tokens.

In the majority of cases, she can also choose different interface implementers for different tokens.

These preferrences are stored in the Registry in this mapping:
_interfaceHash is an identification of an event Alice chooses an interface implementer for.

And anyone can read Alice interface implementers using this function:
As you can see this is the function we encountered previously in the VRA code.

Variable _TOKENS_SENDER_INTERFACE_HASH is used as _interfaceHash, which can be any bytes. But the VRA token uses these bytes to identify this type of hook:
How to start receiving hooks
In order to choose a hook receiver, Alice just should call this function on the Registry and input Bob’s address as the _implementer input.
She also has to specify an _interfaceHash. Let´s imagine she takes a _TOKENS_SENDER_INTERFACE_HASH from VRA tokens.

One more important detail.

After setting the implementer for VRA above, Alice will realize that Bob receives calls even if other ERC777 tokens are transferred.
Like imBTC:
imBTC has the same _interfaceHash on tokens sent.

This is due to the fact all ERC777 tokens share the same Registry address to store hook preferrences. But it’s up to ERC777 tokens to specify names for their hooks though sometimes they are similar, but not always.
How to find ERC777 tokens
The Registry is something that is similar to all ERC777 tokens.
So, we can try dune.com to receive all smart contracts that call the Registry.
We can use this SQL script. In fact, we should additionally filter that addresses are tokens but at least we have a perfect start that resulted in 78 addresses.
Is this Registry the only one possible?
In theory, no one can guarantee that some token uses exactly this 0x1820 contract as a Registry.
But we can check it with dune.com
It returns these addresses

We checked that 0x1820 is the only Registry with valuable ERC777 tokens. Other Registries have not-so-liquid tokens.
The wider picture of hookable tokens
ERC777 is not only a standard with hooks.

As the first step, you can read about ERC223, ERC995, or ERC667.
They are not so exotic. You must have heard of the LINK token which implements ERC667.
The attack vector with arbitrary calls
This is the attack vector we recently found for our client.

Researchers usually think ERC777 tokens make calls to token senders and receivers. But we described above that this is a myth - senders and receivers can choose any “Bob” as hook receivers.

So, imagine a target smart contract that allows making arbitrary calls to any address with any data.

Such functions can exist in DEX aggregators, wallets, multicall contracts.

The attack:
  1. Attacker finds a function in Target that allows arbitrary calls
  2. Attacker makes a Target call:
  3. registy1820.setInterfaceImplementer(Target, hookHash, Attacker)
  4. Now, our Attacker is an implementer for Target
  5. Attacker can call with every hookHash used in major ERC777 tokens
  6. Every time Target receives an ERC777 token, Attacker receives a hook call
  7. The following attack is different depending on the target code:

  • Attacker can reenter when some user executes a function in the target contract
  • Attacker can just revert, so that the user’s transactions are just reverted

DEX aggregators may experience problems if they calculate that the optimal swap path lies through some DEX pair with some ERC777 token.
After hours of discussion with our client, we found a solution that still does not break arbitrary calls.

Projects are better to restrict choosing Registry1820 as an address for arbitrary calls. As a result, no attacker is able to choose interface implementers.
Projects and auditors must be aware of the described hook behavior in ERC777. These tokens make calls not only to receivers and senders but also to some other hook recipients.

In this sense projects allowing arbitrary calls must pay special attention and consider one more attack vector with ERC777.
Who is MixBytes?
MixBytes is a team of expert blockchain auditors and security researchers specializing in providing comprehensive smart contract audits and technical advisory services for EVM-compatible and Substrate-based projects. Join us on Twitter to stay up-to-date with the latest industry trends and insights.
The information contained in this Website is for educational and informational purposes only and shall not be understood or construed as financial or investment advice.
Other posts