Replay Attack
Defining Replay Attack
Replay attacks that occur on blockchains are performed by taking a transaction and maliciously or fraudulently repeating it on a contract. In a normal transaction a user signs the information, uploads it to the contract, and the contract verifies the signature. This means that the user's signature information is online where an attacker can intercept it. The main cause of replay attacks on the blockchain are how the digital signature is processed within the smart contract. One scenario where an attack can occur is when a malicious attacker intercepts a signature from a transaction and uses it to authorize a second action on the same contract. This can happen if signatures were exchanged between two users off-chain and one user executed the same transaction multiple times. Some other scenarios were replay attacks can occur are:
Executing the same transaction at a different address
After self-destructing a contract a new contract can be created at the same address and the reuse of the old messages again
Incorrect handling of a TransferProxy
TransferProxy Example
In the example above we take two ERC20 smart contracts with a UGT contract and a MTC contract. Say a sender (Alice) wants to send 2 UGT tokens to a receiver (Bob). Alice sends Bob 2 UGT tokens and Bob extracts the parameters from the transferproxy request. Bob then can take those parameters and execute another transfer in the smart contract of MTC which would result in Alice sending Bob 2 MTC token which was not unauthorized by Alice.
Hard Fork
A hard fork occurs on a blockchain where some user don't merge to the new chain and continue on the original blockchain creating opportunities for replay attack. An example of this occurred in 2016 where Ethererum hard-forked into Ethereum (ET) and Ethereum Classic (ETC). Now every transaction sent to the Ethereum network can be replayed on the Ethereum Classic network or vice versa. Since the structure is similar and depending on how the smart contract deployed on the blockchain handles signatures, the contracts are vulnerable to replay attacks. If a transaction occurs on Ethereum network from an account that was created before the fork, an attacker can replay the transaction on Ethereum Classic network and take the equivalent amount on that chain or vice versa.
First we need to deploy the Micropayment contract. In this example we will deploy the contract with 10 Wei. We recommend using the Remix Online IDE with setup instruction found here. The owner is set and constructor is payable.
To avoid fees associated with transactions on the blockchain the two parties involved in this transfer will exchange their signature and message off chain. The message will include the address of the receiver and the payment amount (5 Wei). We will use the Web3 library and MetaMask to do the signing. Using "web3.utils.soliditySha3(recipient, amount)" to hash to a fixed length of 32 bytes. Next sign the hash using "web3.eth.personal.sign(HASH, ACCOUNT_TO_SIGN_WITH, CALLBACK_FUNCTION )". The signing can be done by executing the JavaScript function below or using the console on the Remix IDE and call the web3.eth.personal.sign().
Now that the message is signed this would be sent to the receiver of the payment to present to the contract and withdraw the payment amount. The claimPayment() function is used to verify the signature and distribute the 5 Wei. Since the signature only contains the address of the receiver and the amount it is vulnerable to replay attacks. The claimPayment() function can be called again with the same message and withdraw another 5 Wei as long as there is still funds in the contract. The signature will remain valid without the proper checks within the contract.
There are multiple ways to prevent replay attacks. In the case of the demonstration above a nonce and contract address are used to prevent replay attacks. The nonce is agreed upon by the two parties off chain and can only be used once. The used nonces are stored within the contract using a map data structure. The contract address prevents the signature from being taken to a similar contract and used to withdraw funds. If the contract were to be destroyed by the owner and then re-deployed having the contract address prevents the signature from being used again on the new contract.
Solutions Available
Thus to prevent these replay attacks it is important to understand how the smart contract processes a signature and updates the contract if needed. Designers of smart contracts should confirm the suitable range of a signature.
Nonce: Passing a nonce as an input to the transfer function. This creates a unique message has or signature each time, preventing a replay attack on the same contract. Starting the nonce at a value higher than 0.
Address(this) in keccak256: Using the address as a parameter to calculate the message hash. This also results in a unique or contract message hash which prevents an attack on a different address.
Chain ID/Name: Contracts deployed on the public chain should use information about the public chain such as the chain id or name to ensure the transaction is taking place on the correct chain. Adding information to be hashed with signature increases security of the transaction.
References
Being, J. | H. (2018, September 19). Replay attack vulnerability in Ethereum Smart contracts
introduced by transferproxy(). Medium. Retrieved October 13, 2022, from
https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts
-introduced-by-transferproxy-124bf3694e25
Duan, L., Sun, Y., Zhang, K., & Ding, Y. (2022). Multiple-layer security threats on the
Ethereum blockchain and their countermeasures. Security and Communication Networks,
2022, 1–11. https://doi.org/10.1155/2022/5307697
Kulkarni, Y. (n.d.). Yogesh Kulkarni. Finxter. Retrieved October 13, 2022, from
https://blog.finxter.com/smart-contract-replay-attack-solidity/
Nkbai. (2018, September 29). Defcon26/replay attacks on Ethereum Smart Contracts.md at
master · NKBAI/DEFCON26. GitHub. Retrieved October 13, 2022, from
https://github.com/nkbai/defcon26/blob/master/docs/Replay%20Attacks%20on%20Ether
eum%20Smart%20Contracts.md