SlowMist: Ethereum Smart Contracts Replay Attack Details Analysis (Released in 2018)
At the recently concluded Defcon 26 global hacker conference, Zhenzuan Bai and Yuwei Zheng from the 360 UnicornTeam presented the topic “Your May Have Paid More than You Imagine: Replay Attacks on Ethereum Smart Contracts”. After studying and testing the content, the SlowMist Security Team compiled this article for everyone to discuss and reference.
Background of the Attack
In asset management systems, delegation management is common where the asset owner delegates their assets to a trustee for management, and the owner pays a fee to the trustee. This business scenario is also common in smart contracts.
Contract Design
Roles involved in the transferProxy method design are:
- Role 1: The person who needs to transfer the token but doesn’t have ETH in their wallet, referred to as _from in the contract.
- Role 2: The person who helps Role 1 transfer the token and pays the gas fee in ETH, referred to as msg.sender in the contract. This is the person who calls the contract.
- Role 3: The recipient of the token, referred to as _to in the contract.
The purpose of the transferProxy method is:
Role 1 wants to transfer tokens to Role 3, but he doesn’t have enough ETH to pay the transaction fee. So, Role 1 finds someone with enough ETH, Role 2, and gives him some tokens as payment for using their ETH to pay the transaction fee. Role 2 then calls the transferProxy method to transfer the tokens from Role 1 to Role 3.
Implementation of the Contract
The key points in the function are keccak256 and ecrecover, which are the elliptic curve cryptography digital signature algorithm (ECDSA) function and verification function, respectively. Keccak256 is equivalent to sha3.
The signing and verification processes are as follows:
- Role 1 (_from) first uses the sha3 function to process _from, _to, _value, _fee, nonce, and address(token) to obtain the msg value, and then uses web3.eth.sign(address, msg) to obtain the signature;
- Take the first 0–66 bytes of the signature as r, bytes 66–130 as s, and bytes 130–132 as v. Then convert v to an integer. Role 1 informs Role 2 of this information, and Role 2 calls the transferProxy function in the contract to transfer the token;
- The ecrecover function in the contract takes the signed data hash value and r/s/v parameters as input, and returns the account address that implements the signature;
- Verify whether the account address obtained in step 3 matches _from.
Note
Roles 1 and 2 need to communicate the nonce and _fee in advance. The nonce is defined in the contract, starting from 0 and incrementing, and can be queried using the getNonce(address _addr) function of the contract.
Attack Process
Due to the fact that all the call data (function parameters) of the contract is publicly available and searchable on the chain, it is possible to extract all signature information from the Transaction.
Flowchart
In smart contract replay attacks, based on the logic of elliptic curve digital signature algorithm (ECDSA) and verification, the same transferProxy can be used in different contracts. The attacker extracts the signature information from the Transaction of Contract A and replays it in Contract B. Since all the parameters involved in the signature are the same, the attacker can call Contract B directly and broadcast it to the blockchain.
The prerequisite for a successful attack is that the nonce value of the _from account in the two contracts is the same, which ensures that the hash value after the signature is the same.
Testing tool: https://github.com/nkbai/defcon26/tree/master/trproxy
Impact of the Vulnerability
According to the presentation “Your May Have Paid More than You Imagine: Replay Attacks on Ethereum Smart Contracts”, as of April 27th, about 52 contracts have been affected by replay attacks, including 10 high-risk, 37 medium-risk, and 5 low-risk contracts.
From the perspective of attack targets, 5 contracts can be attacked within their own contract due to their non-designated design, while the other 45 contracts can be attacked through cross-contract replay attacks.
A detailed list of affected contracts can be found in the presenter’s PDF.
Defense Suggestions
- The nonce generation algorithm should not use the same design as the practice of starting from 0 to avoid being the same as the scenario;
- Remove the transferProxy function and use other methods to implement the proxy requirements;
- The SlowMist Security Team’s contract audit items have been included in the audit of this type of issue.
References
Presenter
Presenter’s Open Document: https://github.com/nkbai/defcon26/blob/master/docs/Replay%20Attacks%20on%20Ethereum%20Smart%20Contracts.md
Presenter’s Open Tools: https://github.com/nkbai/defcon26/tree/master/erc20finder
Presenter’s Open Tools: https://github.com/nkbai/defcon26/tree/master/proxytoken
About SlowMist
SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, etc.
Website：
https://www.slowmist.com
Twitter：
https://twitter.com/SlowMist_Team
Github：
https://github.com/slowmist/
