5 min read

Overview

Replay attacks on Ethereum (and other EVM-chains) have cost users millions of dollars, yet they still occur. In this guide, we'll teach you more about replay attacks, covering what they are and how they occur. Later, we'll provide you with knowledge to better protect your smart contract from a replay attack.

What You Will Need

• Basic understanding of Ethereum and smart contracts
• Previous experience with Solidity (Gain experience here)

What You Will Do

• Recap the inner workings of an Ethereum transaction
• Learn about Replay attacks
• Learn techniques to prevent a replay attack

Transactions on Ethereum

Before diving into replay attacks, let's first understand how transactions on Ethereum work. There are different types of transactions on Ethereum (e.g., type-0 (legacy) or type-2), but all transactions must conform to some compliant standard in order for a node to accept it and include it in the mempool of pending transactions. This signed transaction must generally include the following fields: to, value, gasprice, data, (v, r, s), chainId, and nonce in its payload. Type II transactions include new gas fields such as maxFeePerGas and maxPriorityFeePerGas.

All these fields are composed to generate a signed transaction payload, which is represented in a long string of hexadecimal values such as:

0xf86b80850ba43b7400825208947917bc33eea648809c285607579c9919fb864f8f8703baf82d03a0008025a0067940651530790861714b2e8fd8b080361d1ada048189000c07a66848afde46a069b041db7c29dbcc6becf42017ca7ac086b12bd53ec8ee494596f790fb6a0a69

Now, let's focus on two of these fields.

Nonce

A nonce is a sequentially numbered value included when generating a signed transaction that keeps track of the number of transactions an address has sent. This counter of transactions (i.e., nonce) is recorded in the world state of Ethereum, which nodes hold state for.

Given that each transaction (i.e., confirmed transaction) has a unique nonce, this also results in a unique signature. This means a malicious actor can't take your valid signed transaction and try to broadcast it again (replaying) since it'll need to have a different nonce. To learn more about nonces, check out this guide: What is a Nonce? Management Techniques for Your Ethereum Transactions.

Chain ID

A chain ID is used to specify which blockchain the transaction is meant for. This value isn't unique to each transaction but is unique to each blockchain (e.g., Ethereum, Optimism, Polygon). For example, the Ethereum mainnet uses 1, the Optimism mainnet uses 10, Polygon PoS uses 137, and so on. If a user tries to submit a transaction on a network the chain ID was not meant for, the node will not accept it. This is also a preventative measure where malicious actors cannot take signed transactions (already executed) and try to resubmit them on another chain.

This specific safeguard was introduced because of the Ethereum Classic hard fork, as EIP-155, which looked to prevent these replay attacks between Ethereum and the forked version, Ethereum Classic. There is also a network ID field, which isn't used with transaction verification but instead is used between node communication on a network level.

To learn more about transactions on Ethereum, take a look at this in-depth guide: What are Ethereum Transactions. Now, keep this information in mind as we'll dive into how a malicious actor takes advantage of a signed transaction using a replay attack.

What are Replay Attacks?

At a high level, a replay attack in a blockchain context consists of taking advantage of a signed transaction at a blockchain level or smart contract level. This type of vulnerability was originally introduced at a blockchain level where malicious actors would take valid signed transactions on one chain and try to resubmit them on another blockchain for illicit intent. This type of attack occurs when blockchain clients (e.g., geth, nethermind) or smart contracts do not have proper security measures in place, which results in a valid transaction being used again for malicious purposes.

How does this happen? As we discussed in the Transactions on Ethereum section, transactions are composed of multiple fields, including receiver address, amount, gas price, nonce, chain ID, and a signature. With these fields, one could generate a valid transaction payload. However, if this signed transaction isn't properly secured (i.e., it doesn't use enough unique or random data) or the blockchain client accepting it doesn't verify that if it hasn't been used, the transaction could be accepted again, leading to potential unauthorized access to funds or data state manipulation.

It is important to recognize that replay attacks aren't native to blockchain and have been known in the world of networking and security before. Nevertheless, in a blockchain context, let's dive deeper into the present attack vectors:

Replay Attack on a Blockchain level

A malicious actor can replicate and broadcast a valid transaction from one blockchain to another, seeking unauthorized access to funds or contract state manipulation. This type of attack exploits the similarities in transaction structures or signatures between different chains, taking advantage of weaknesses in cross-chain transaction validation.

Mitigation Strategies

• Chain-specific signatures: Implementing a unique ID such as chainID can prevent transactions from being replayed on another chain (EIP-155)
• Nonce: Combine nonces in transactions to ensure each transaction is unique

Replay Attack on a Smart Contract level

Replay attacks on a smart contract level involve exploiting vulnerabilities within the same chain. This most commonly occurs when a smart contract with a custom signing scheme does not securely write its logic. To prevent this, you can look to implement a similar mechanism to transactions such as the nonce. Alternatively, another approach is to store the log of signatures and reject a signed transaction already used.

Mitigation Strategies

• Nonce: Implement a count of each account's transaction history, rejecting any signatures with an already used nonce
• Unique smart contract identifier: Hashing other contract-specific values such as the contract address or ABI to ensure the same signature can't be replayed on a different smart contract
• Code audits: Getting the services of a reputable auditing firm to look over contract logic and signing schema

Final Thoughts

Replay attacks can be costly; however, with the knowledge you have just learned, you will be better prepared to identify and protect against replay attacks.

If you have questions, check out the QuickNode Forum for help. Stay up to date with the latest by following us on Twitter (@QuickNode) or Discord.

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.