#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability

On December 5, 2023, the prominent Web3 development platform Thirdweb disclosed significant smart contract security vulnerabilities affecting its pre-built contracts. This critical flaw impacted all ERC-20, ERC-721, and ERC-1155 tokens deployed using these specific vulnerable contracts. In the days following the disclosure, tokens deployed with these vulnerable contracts were progressively exploited in a series of attacks, underscoring the severity of the underlying incompatibility.

Understanding the ThirdWeb Smart Contract Vulnerability

The root cause of the ThirdWeb incident lies in the unexpected interaction between two fundamental components of smart contract development: ERC-2771 and OpenZeppelin's Multicall implementation. To fully grasp the vulnerability, it's essential to understand each component individually and then how their interaction created an exploitable pathway.

ERC-2771: Meta-Transactions and Trusted Forwarders

EIP-2771 defines a contract-level protocol that enables Recipient contracts to accept meta-transactions via trusted Forwarder contracts. This standard is crucial for improving user experience by allowing third parties (forwarders) to pay gas fees on behalf of users, abstracting away the need for users to hold native blockchain tokens.

In practice, OpenZeppelin's ERC2771Context is a widely adopted implementation. Its core functionality involves treating the last 20 bytes of calldata from a trusted forwarder as the effective _msgSender(). For developers using this library, the common practice is to replace all direct uses of msg.sender with _msgSender() to ensure compatibility with meta-transactions. Similarly, _msgData() is used to retrieve the original transaction data, excluding the appended sender information.

function _msgSender() internal view virtual override returns (address) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return address(bytes20(msg.data[calldataLength - contextSuffixLength:]));
    } else {
        return super._msgSender();
    }
}

function _msgData() internal view virtual override returns (bytes calldata) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return msg.data[:calldataLength - contextSuffixLength];
    } else {
        return super._msgData();
    }
}

Multicall: Batching Transactions for Efficiency

Multicall functionality allows users to bundle multiple function calls into a single transaction, significantly reducing gas costs and improving transaction efficiency. OpenZeppelin's MulticallUpgradeable is a popular implementation for this purpose. It takes an array of calldata bytes and performs a delegatecall for each entry, executing them within the context of the calling contract.

function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
    results = new bytes[](data.length);
    for (uint256 i = 0; i < data.length; i++) {
        results[i] = _functionDelegateCall(address(this), data[i]);
    }
    return results;
}

(Note: The bug discussed here has since been fixed in later versions of OpenZeppelin's Multicall.)

The Incompatibility: ERC-2771 and Multicall Conflict

The core of the ThirdWeb incident's smart contract vulnerability emerged from a critical inconsistency in how calldata is processed by ERC-2771 and Multicall. ERC-2771 expects the trusted forwarder to pack the message data and sender information together. The recipient contract then uses _msgData() and _msgSender() to correctly unpack this information.

However, the Multicall function, in its vulnerable implementation, was not designed to be compatible with how ERC-2771 packs data for meta-transactions. Specifically, when Multicall processes a batch of calls, it should have correctly extracted the _msgSender() from the initial meta-transaction and then appended this sender information to each individual call's calldata before executing them. This crucial step was missing.

Without the sender information being correctly appended to the calldata within each sub-call processed by Multicall, the ERC-2771 context within the target contract would attempt to unpack sender information from the last 20 bytes of the _msgData() of the sub-call. Crucially, an attacker could control these last 20 bytes. This allowed a malicious actor to craft specific calldata that, when processed by Multicall and then interpreted by an ERC-2771-enabled contract, would execute arbitrary logic with a manipulated _msgSender() value (e.g., an address controlled by the attacker or even a protocol's own pool address). This effectively bypassed the intended security checks and violated the expectations set by both specifications, leading to unauthorized actions.

ThirdWeb Incident: Attack Analysis and Exploitation

Let's examine a real-world example of the ThirdWeb incident's smart contract vulnerability exploitation, using an attack transaction analyzed by BlockSec's Phalcon platform.

The attacker's strategy involved manipulating the _msgSender() to impersonate a Uniswap pool, thereby draining its token balance.

• Step 1: Initial Token Acquisition. The attacker began by swapping 5 WETH for 3,455,399,346 TIME tokens on a decentralized exchange. This provided the necessary tokens for the subsequent manipulation.

• Step 2: Malicious Multicall Execution. This is the core of the exploit. The attacker invoked a trusted forwarder with carefully crafted calldata designed to exploit the ERC-2771/Multicall incompatibility. When this calldata was parsed by the Multicall function, it resulted in the burn function of the TIME token contract being called. Crucially, due to the vulnerability, the _msgSender() was incorrectly interpreted as the Uniswap Pool address. This allowed the attacker to effectively burn a significant portion of the TIME tokens held by the Uniswap pool, without actual authorization. The BlockSec Phalcon platform provides detailed transaction tracing to visualize this flow.

  

  The image above illustrates how the attacker's Forwarder.execute call is processed. The multicall function receives an array of bytes, which then leads to the burn function being called with the manipulated _msgSender().

  

  This detailed view from Phalcon shows the bytes[] of length 1 being used as data to call the contract, leading to the burn function execution under the false _msgSender().

• Step 3: Price Manipulation. By burning a large quantity of TIME tokens from the Uniswap pool, the attacker drastically reduced the pool's liquidity for TIME. This artificial scarcity caused the price of TIME relative to WETH to skyrocket within the pool.

• Step 4: Profitable Arbitrage. With the price of TIME artificially inflated, the attacker then swapped their remaining 3,455,399,346 TIME tokens back for 94 WETH, realizing a substantial profit from the manipulated price.

This sequence of events demonstrates a sophisticated attack leveraging a subtle smart contract vulnerability stemming from module incompatibility.