Ethereum’s CREATE2: A Double-Edged Sword in Blockchain Security

By Oded Vanunu, Dikla Barda, Roman Zaikin

Ethereum’s CREATE2 function is being exploited by attackers to compromise the security of digital wallets, bypassing traditional security measures and facilitating unauthorized access to funds.

The attack method involves tricking users into approving transactions for smart contracts that haven’t been deployed yet, allowing cybercriminals to later deploy malicious contracts and steal cryptocurrencies.

This vulnerability highlights the need for enhanced security measures in wallet security products to adapt to the evolving tactics of cybercriminals, ensuring the safekeeping of digital assets in the face of innovative exploits.

In the digital realm of blockchain and cryptocurrency, Ethereum stands out as a platform of innovation and versatility. Its capacity for adaptation and development makes it a critical player in the tech space. However, the very features that make Ethereum remarkable also expose it to potential vulnerabilities. One such feature is the CREATE2 function, which, while showcasing Ethereum’s advanced technological capabilities, has unfortunately also opened the door to new security threats against digital wallets.

The Intricacies of CREATE2

Introduced in Ethereum’s Constantinople upgrade, the CREATE2 function has been hailed for its ability to deploy smart contracts with deterministic addresses even before the creation of the contract’s bytecode. This function significantly enhances the predictability and efficiency of smart contract interactions, offering a boon for the complex ecosystems of decentralized applications (dApps). It allows for the pre-orchestration of interactions between multiple contracts, a feature critical for the seamless operation of dApps.

The Security Concern

However, the innovative CREATE2 function also presents a significant security loophole. Cybercriminals have quickly leveraged this function to bypass conventional wallet security measures, creating a new method for exploiting unsuspecting victims. The core of the vulnerability lies in CREATE2’s ability to deploy a smart contract at a known address in the future, enabling attackers to deceive users into approving transactions with a contract that doesn’t yet exist. Once the user grants approval, the attacker can deploy a malicious contract to that address, hijacking the transaction and draining the victim’s cryptocurrency wallet.

A Closer Look at the Attack Mechanism

1. The attacker begins by convincing the victim to approve or increase the allowance for a yet-to-be-deployed contract.

2. Since the contract hasn’t been deployed at the time of approval, it evades detection by security solutions, which cannot identify potential threats in non-existent contracts.

3. After securing the victim’s authorization, the attacker deploys the malicious contract, exploiting the victim’s funds.

This method not only underlines the creative misuse of Ethereum’s features by malicious entities but also highlights a critical challenge for security products. Most security solutions are calibrated to analyze and validate transactions based on existing contracts and known behaviors. CREATE2, by facilitating interactions with future contracts, effectively bypasses these security frameworks, leaving digital assets at risk.

The Technical Side of CREATE2

Delving into the technical aspects, CREATE and CREATE2 are both opcodes in Ethereum blockchain development that support the deployment of smart contracts. They differ primarily in how the address of the new contract is determined. While CREATE bases the contract’s address on the creator’s address and a nonce, CREATE2 allows for a more flexible approach by incorporating a user-specified salt, the creator’s address, and the contract’s initialization code into the address computation.

In the context of Ethereum blockchain development, both CREATE and CREATE2 are opcodes that facilitate the deployment of smart contracts, but they differ in how the address of the new contract is determined.

The CREATE opcode generates the address of the new contract based on the address of the creator (the sender of the transaction) and the nonce. On the other hand, CREATE2 offers a more flexible approach by allowing the contract’s address to be determined based on a user-specified salt, the creator’s address, and the contract’s initialization code.

The address of the contract in CREATE2 is computed by using 4 parameters:

keccak256(0xff + sender_address + salt + keccak256(initialization_code))

1. Constant prefix – A fixed prefix that is part of the hashing process, which is 0xff. This is used to differentiate CREATE2 addresses from those created with the CREATE opcode.
2. Sender’s Address – The address of the account creating the contract, typically a smart contract itself when using CREATE2.
3. Salt – A 32-byte (256-bit) value chosen by the creator. The salt allows the creator to deploy multiple contracts with the same initialization code to different addresses.
4. Initialization Code – The bytecode of the contract being created. This includes the bytecode that results from compiling the smart contract source code, along with any constructor arguments encoded into it.

To demonstrate how CREATE2 can deploy another contract with a deterministically computed address, we will use the below simple example that includes two Solidity contracts: Factory and Child. The Factory contract uses the CREATE2 function to deploy the Child contract to a specific precomputed address.

By deploying the Factory contract to the testnet and using 123456 as a salt, we will be able to precompute the child contract address:

Factory Contract Address is (https://goerli.etherscan.io/address/0xb74025567acdc922507821516014dc5fe659483f):

Now by using computeChildAddress function, we will be able to precompute the child address which is

0xe41Ba18D5e667b0B391b33b848520FA6F041C092:

This address does not exist yet because we didn’t deploy the contract:

Next, the attacker will try to trick the victim into approving this contract as a spender for a specific token he wants to steal, and because the contract has not been created yet, this transaction evades all forms of wallet security measures the victim possesses, which rely on the historical record of the contract address.

After the attacker tricks the user to sign the approval request, he will be able to deploy the contract by using the same salt 123456 in the function deployChild:

An Example from the Wild

A stark illustration of this vulnerability in action involved a user losing $3.5 million due to such an exploit. The victim approved a transaction for a contract that hadn’t been created yet. The contract was deployed shortly after the approval, and the attacker executed a function to transfer the victim’s funds to their own address.

At the time of the transaction, the contract a01dee645e4dbaaa8aa2089cc4b1cc34d36fa71c which is approved for the allowance had not been created yet:

https://etherscan.io/tx/0xb5f03259859c10243a85f7a9ca27d8b45e67ce6463800193634d27718ba162a0

This transaction executes an unverified function that performs various checks and then creates the approved contract address by using CREATE2 as we demonstrated before:

• Target – Which is, in this case, SUPER token
• callData – This is the bytedata of the function the attacker wants to perform.

in this situation, the attacker performs the transferFrom function and uses the allowance from before to transfer the balance from the victim to the following address 0x8f9278aab84290fe6e78515b7938b3136b89a1e2:

Securing the Digital Frontier

The exploitation of the CREATE2 function underscores the ongoing battle between innovation and security in the blockchain space. As Ethereum continues to evolve, so too must the security mechanisms designed to protect users from such sophisticated attacks. Awareness and education are the first steps in safeguarding digital assets against emerging threats. Blockchain developers and users alike must remain vigilant, continuously updating their knowledge and security practices to navigate this ever-changing landscape securely.

The Threat Intel Blockchain system, developed by Check Point, continues to accumulate valuable information on emerging threats, and this intelligence will be shared in the future. In this collaborative effort, we aim to empower investors with the knowledge needed to navigate the crypto space securely and protect themselves from potential pitfalls. For more information contact us at: [email protected]