Audit Application Form
Let's talk
One more problem with ERC777
Author: Daniil Ogurtsov
Security researcher at MixBytes
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.
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:
VRA
https://etherscan.io/address/0xf411903cbc70a74d22900a5de66a2dda66507255
AMP
https://etherscan.io/address/0xff20817765cb7f73d4bde2e66e067e58d11095c2
LUKSO
https://etherscan.io/address/0xa8b919680258d369114910511cc87595aec0be6d
SKL
https://etherscan.io/address/0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7
imBTC
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
CWEB
https://etherscan.io/address/0x505b5eda5e25a67e1c24a2bf1a527ed9eb88bf04
FLUX
https://etherscan.io/address/0x469eda64aed3a3ad6f868c44564291aa415cb1d9
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:
VRA
https://etherscan.io/address/0xf411903cbc70a74d22900a5de66a2dda66507255
AMP
https://etherscan.io/address/0xff20817765cb7f73d4bde2e66e067e58d11095c2
LUKSO
https://etherscan.io/address/0xa8b919680258d369114910511cc87595aec0be6d
SKL
https://etherscan.io/address/0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7
imBTC
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
CWEB
https://etherscan.io/address/0x505b5eda5e25a67e1c24a2bf1a527ed9eb88bf04
FLUX
https://etherscan.io/address/0x469eda64aed3a3ad6f868c44564291aa415cb1d9
When hooks happen
ERC20 tokens just update balances during transfers.
But ERC777 tokens do it this way:
It is well illustrated in the VRA token:
But ERC777 tokens do it this way:
- Make a hook call to an address chosen by the token sender
- Update balances
- 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.
Now, let’s examine the code responsible for these calls.
As you can see:
Let´s investigate this Registry and find out what implementers are.
- this function reads so-called implementer from _ERC1820_REGISTRY
- 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:
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:
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:
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:
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
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.
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:
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
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.
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
But we can check it with dune.com
It returns these addresses
0x1820a4b7618bde71dce8cdc73aab6c95905fad24
0xc0ce3461c92d95b4e1d3abeb5c9d378b1e418030
0x820c4597fc3e4193282576750ea4fcfe34ddf0a7
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.
https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca
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.
https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca
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:
DEX aggregators may experience problems if they calculate that the optimal swap path lies through some DEX pair with some ERC777 token.
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:
- Attacker finds a function in Target that allows arbitrary calls
- Attacker makes a Target call:
- registy1820.setInterfaceImplementer(Target, hookHash, Attacker)
- Now, our Attacker is an implementer for Target
- Attacker can call with every hookHash used in major ERC777 tokens
- Every time Target receives an ERC777 token, Attacker receives a hook call
- 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.
Protection
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 are better to restrict choosing Registry1820 as an address for arbitrary calls. As a result, no attacker is able to choose interface implementers.
Takeaways
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.
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.
Disclaimer
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