♻️Chain Reorganization (Re-org) Vulnerability
A chain re-org refers to a situation where the blockchain network temporarily forks into two competing chains, and after a certain number of blocks, one chain is discarded in favor of the other. This process effectively "reorganizes" the blockchain and can lead to transactions that were previously considered confirmed being reverted or lost. While re-orgs are generally rare and occur mostly due to network conditions, they can be exploited by malicious actors in certain scenarios, especially when dealing with smart contracts.
In this section, we'll explore the re-org vulnerability and how it can be leveraged by attackers to front-run, back-run, or manipulate the behavior of smart contracts, leading to potential theft of funds, loss of contract ownership, or double-spending attacks. Specifically, we will look at the risks associated with smart contract deployments, token transfers, and vault interactions during re-orgs.
How the Chain Re-org Vulnerability Works
In a blockchain, once a transaction is included in a block and several blocks are added on top, it is typically considered finalized. However, during a re-org, if the chain is restructured to favor a competing fork, a transaction that was part of the discarded chain can become invalid. This can create opportunities for attackers to exploit smart contracts by manipulating transaction ordering and altering expected outcomes.
Attack Flow:
Frontrunning the Deployment:
When a smart contract or vault is deployed using a standard
create()function, its deployment address is derived from the sender’s address and nonce. If a re-org occurs, an attacker can frontrun the deployment by quickly deploying a malicious contract at the same address as the intended contract. This can lead to the attacker taking control of the intended contract's address.
Backrunning the Deposit:
After frontrunning the deployment, an attacker can wait for the user to deposit assets into the compromised vault. Once the deposit is confirmed on the blockchain, the attacker can then backrun the transaction, pulling funds from the vault by exploiting the ownership they gained during the re-org. This leaves the victim believing their deposit was successful, but the funds are actually controlled by the attacker.
Taking Advantage of Pending Transactions:
During the re-org, attackers monitor pending transactions in the mempool. They can submit competing transactions that are more profitable to miners (via higher gas fees), causing miners to include their transactions in the newly organized chain, while the legitimate transactions are discarded.
Example Scenario
Let’s walk through an example to explain how this vulnerability can be exploited in a real-world context, using the deployment of a vault contract as an example.
Step-by-Step Attack Scenario:
User Deploys a Vault:
Alice wants to deploy a new vault contract using the
create()function. This vault will hold her deposited assets. The vault address is derived from the transaction sender's address and the current nonce.
Re-org Occurs:
A chain re-org happens, and the blocks that confirmed Alice's vault deployment are discarded. In the meantime, the attacker, Bob, who is monitoring the network, sees Alice's deployment in the discarded blocks.
Bob Frontruns the Deployment:
Bob quickly submits a new transaction to deploy a malicious vault contract at the same address derived from the nonce and Alice’s address. Since the chain was reorganized, Alice’s deployment is no longer valid, and Bob's transaction gets included in the new canonical chain.
Alice Deposits into Bob’s Vault:
Without realizing that her original vault deployment has been replaced, Alice proceeds with depositing tokens into what she believes is her vault. However, she’s actually interacting with Bob's malicious vault.
Bob Backruns and Drains the Vault:
After Alice’s deposit is confirmed, Bob can now withdraw the funds from his malicious vault using his full control over the contract. Alice’s deposit is effectively stolen, and she is left unaware that her assets were compromised.
Common Re-org Vulnerability Exploits
Ownership Theft: When a contract is deployed during a re-org, the attacker can take over the contract by deploying a malicious contract at the same address. The attacker then has full control over any interactions that take place with the contract, leading to theft of funds or manipulation of contract functionality.
Front-running Contract Creation: Attackers can monitor for contract creation transactions and deploy their own contracts during a re-org to take over the original intended contract address. This is particularly dangerous in cases where funds are immediately deposited into the contract.
Vault Fund Drain: During a vault deployment and deposit operation, an attacker can use a re-org to manipulate the contract creation and subsequently drain deposited funds by setting themselves as the owner of the vault.
Mitigation Strategies for Re-org Vulnerabilities
Use
create2()Instead ofcreate():One of the most effective ways to mitigate re-org vulnerabilities is by using the
create2()function instead ofcreate()for contract deployments. Thecreate2()function uses a salt to deterministically compute the contract address, making it less susceptible to address collisions during re-orgs.
Last updated