Background
On December 5, 2023, thirdweb, a Web3 foundational development platform, reported security vulnerabilities in its pre-built smart contracts. This issue affects all tokens deployed using these pre-built smart contracts, including ERC20, ERC721, and ERC1155 tokens. (For specific details on the affected contract code versions, refer to: Thirdweb’s security vulnerability blog post.
Based on the research from the SlowMist security team, on December 7, 2023, the Time token on the Ethereum mainnet was attacked due to this vulnerability, resulting in the attacker stealing approximately $190,000. Currently, many vulnerable token contracts are still under attack. The immediately investigated this incident and these are our findings:
Preliminary Knowledge
1. ERC-2771 is a standard for meta-transactions. It allows users to delegate the execution of transactions to a third party, known as a Forwarder, commonly referred to as a relay or forwarder.
In typical contract interactions, the address of the direct caller is obtained using `msg.sender`. However, in the case of ERC-2771 implementation, if `msg.sender` is a forwarder role, the contract will truncate the incoming `calldata` and extract the last 20 bytes to use as the direct caller’s address for the transaction.
2. Multicall is a smart contract library designed to allow the batch execution of multiple function calls, thereby reducing transaction costs. This library is commonly used to optimize the performance and user experience of DApps, especially when multiple read operations are required.
From the code analysis, it can be observed that the vulnerable contracts in the thirdweb project utilize the Multicall library by executing other functions in the contracts that reference this library through a loop of `DelegateCall` function calls. This approach is a key factor in how the contracts interact with and process batched function calls.
Root Cause
The root cause of the vulnerability lies in the token contracts’ simultaneous use of ERC-2771 and the Multicall library. The attacker exploits this by calling the `execute` function of the Forwarder contract to invoke the `multicall` function of the token contract, thereby executing other functions within the contract (such as burning tokens). This method successfully passes the `isTrustedForwarder` check of ERC-2771, ultimately interpreting the function caller as the last 20 bytes of the malicious `calldata`. As a result, the attacker deceives the contract into mistakenly recognizing the caller as another user’s address, leading to the burning of tokens belonging to other users.
Steps in the Attacks
Using the attack transaction 0xecdd11…f6b6 as an example, let’s analyze the steps involved:
1. The attacker first exchanges 5 WETH (Wrapped Ethereum) for 345,539,9346 Time tokens in a Uniswap V2 liquidity pool.
2. Next, the attacker calls the `execute` function of the Forwarder contract, constructing malicious `data` to invoke the `multicall` function of the token contract. At this point, the token contract performs a `delegateCall` using the attacker’s malicious `data` to execute its `burn` function, resulting in the burning of 62,227,259,510 Time tokens from the pool’s address.
3. As a result of the previous step, where a significant amount of Time tokens in the pool were burned, the price of Time tokens was instantly driven up. Consequently, the attacker then reverses the initial swap of Time tokens acquired in the first step, effectively draining 94 WETH from the pool.
Analysis of Attack Method
In the `execute` function of the Forward contract, after verifying the signature of `req.from`, it interacts with `req.to` (the token address) using `call`. The `req.data` provided by the attacker in this instance is:
The reason `0xac9650d8` is mentioned is because it is the function signature of the `multicall` function. Thus, it triggers the call to the token contract’s `multicall` function. The `data` value passed into the `multicall` function is `0x42966c680000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf84`.
Why doesn’t the `data` value passed into the `multicall` function include `req.from`? This is because, at the EVM (Ethereum Virtual Machine) level, when processing a `call` invocation, the necessary values are truncated based on the offset within the call. The attacker’s `calldata` sets the offset at 38, with a length of 1, so the exact truncated `data` value ends up being `42966c680000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf84`.
For a detailed understanding, refer to the EVM opcode description of call (EVM Opcode Documentation).
Since 0x42966c68 is the function signature for the burn function, the attacker’s constructed data value triggers a delegatecall to the token contract’s burn function.
The _msgSender() function is overridden by the ERC-2771 library.
Because the multicall is invoked via delegatecall, the msg.sender passed to isTrustedForwarder is actually the address of the Forward contract. This successfully bypasses the check, ultimately leading _msgSender() to return the last 20 bytes of the input calldata, which is the pool’s address 0x760dc1e043d99394a10605b2fa08f123d60faf84.
Conclusion
The fundamental cause of this attack lies in the contract’s simultaneous use of Multicall and ERC2771Context. Attackers can insert malicious `calldata` into forwarding requests, exploiting the `delegatecall` functionality of Multicall to pass through trusted forwarder checks, and manipulate the interpretation of `_msgSender()` in sub-calls. This enables them to control tokens belonging to any user.
The SlowMist security team advises developers not to use Multicall and ERC2771Context together when programming token contracts. If there is a need to reference both, it is crucial to check whether the `calldata` length meets the expectations or to use the latest official versions of Multicall and ERC2771Context contracts from OpenZeppelin.
References
Attacker’s address: 0xfde0d1575ed8e06fbf36256bcdfa1f359281455a
Attack contract: 0x6980a47bee930a4584b09ee79ebe46484fbdbdd0
Related attack transaction: https://etherscan.io/tx/0xecdd111a60debfadc6533de30fb7f55dc5ceed01dfadd30e4a7ebdb416d2f6b6
Details of affected versions: https://blog.thirdweb.com/security-vulnerability/
Mitigation tool: https://mitigate.thirdweb.com/
About SlowMist
At SlowMist, we pride ourselves on being a frontrunner in blockchain security, dedicating years to mastering threat intelligence. Our expertise is grounded in providing comprehensive security audits and advanced anti-money laundering tracking to a diverse clientele. We’ve established a robust network for threat intelligence collaboration, positioning ourselves as a key player in the global blockchain security landscape. We offer tailor-made security solutions that span from identifying threats to implementing effective defense mechanisms. This holistic approach has garnered the trust of numerous leading and recognized projects worldwide, including names like Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, and Cheers UP. Our mission is to ensure the blockchain ecosystem is not only innovative but also secure and reliable.
SlowMist offers a variety of services that include but are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. They offer AML (Anti-money laundering) software, Vulpush (Vulnerability monitoring) , SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) , Safe Staking and other SaaS products. They have partnerships with domestic and international firms such as Akamai, BitDefender, FireEye, RC², TianJi Partners, IPIP, etc.
By delivering a comprehensive security solution customized to individual projects, they can identify risks and prevent them from occurring. Their team was able to find and publish several high-risk blockchain security flaws. By doing so, they could spread awareness and raise the security standards in the blockchain ecosystem.
