Breaking Down the Meter Hack
Authored by Colin Adams
Bridge hacks are becoming increasingly commonplace in crypto, a fact that underscores how hard it is to move assets safely between chains. According to the Rekt leaderboard, there have been seventy-three big hacks since the start of 2021, with seven already this year, a few of which were notable bridge incidents like Wormhole, Qubit, and Meter.
Meter is of particular interest as it uses an unaffiliated fork of ChainBridge - ChainSafe's ConsenSys-audited modular, multi-directional blockchain bridge. We've been working on this cross-chain infrastructure since 2018, and ChainBridge has been integrated with likes of Palm, Phala, Demodyfi, Astar, Centrifuge, and many others.
ChainBridge is open source, so there's nothing stopping anyone from modifying our code. But that, of course, comes with the caveat that this should only be done responsibly, with consideration for user safety and testing.
With teams now using independently modified forks of ChainBridge without auditing their changes, it was only a matter of time before costly mistakes were made. In the case of Meter, their modifications to the ChainBridge code introduced a bug in the automatic wrap and unwrap of native tokens like BNB and ETH, which created an opening for a hacker to exploit.
While ChainBridge itself remains unaffected, it's worth unpacking what happened. To clarify this, here's the original bridge deposit flow:
-
User executes deposit() function in the Bridge specifying token and amount.
-
Bridge calls the handler contract asking it to transfer specified tokens from the user and lock/burn them.
-
Handler calls transferFrom() on the token contract, charging the user.
Now Meter wants to bridge native tokens. So they introduced a new function depositEth() in the bridge, and modify the handler contract to alter the flow:
-
User executes depositEth() function in the Bridge sending along the native token.
-
Bridge wraps the native token into ERC20 wrapper (like WETH) and immediately transfers it to the handler contract.
-
Bridge calls the handler contract asking it to transfer wrapped tokens from the user and lock/burn them.
-
Handler has a special condition for wrapped tokens, as they were already transferred by the Bridge in step 2, it doesn't charge user.
Meter also has the original deposit() function in place, which was used for the exploit, here's how it was executed:
-
Attacker executes deposit() function in the Bridge specifying wrapped token and amount.
-
Bridge calls the handler contract asking it to transfer specified tokens from the user and lock/burn them.
-
Handler has a special condition for wrapped tokens, it assumes they were already transferred by the Bridge, so it doesn't charge user.
The hacker noticed this faulty trust assumption and called the underlying ERC20 deposit function to fake a BNB or ETH transfer, thus depleting the bridge reserves for these tokens.
While Meter is left working on a compensation plan for victims, this is a reminder that a poorly designed or hastily modified bridge puts users at risk, often without their knowledge. It's also a reminder that sometimes developers need to exercise more caution, and users need to think carefully about which bridges to trust.
To learn more about ChainBridge, please visit our documentation page or hop into the ChainSafe Discord # 🌉 ChainBridge-general👋
About ChainSafe
ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for the decentralized web. Alongside client implementations for Ethereum, Polkadot, Filecoin, and Mina, we're building a portfolio of web3 products - Files, Storage, web3.unity, and more. As part of our mission to build innovative products for users and better tooling for developers, ChainSafe embodies an open source and community-oriented ethos. To learn more, click here.
Website |Twitter |Linkedin |GitHub |Discord |YouTube
Acknowledgments
Thanks to Taha Ben Esmael, Oleksii Matiiasevych, and Liesl Eichholz for their help writing this article.
