On Aug 11, Zhenxuan Bai et al. presented Replay Attacks on Ethereum Smart Contracts[1] at DEF CON26, which uses two proxyOverflow-affected smart contracts as an example[2]. Researchers at PeckShield did a follow-up research and found multiple replay attacks in the wild. Also, we identified more smart contracts prone to Replay Attack which are deployed on the Ethereum mainnet.

We start from a recap of the effort of Zhenxuan Bai et al. The basic idea behind is monitoring a signed message sent to one contract and replaying that message on the victim contract. When both contracts have identical algorithm on validating the signed message, the attacker could impersonate someone else in the context of the victim contract.

Figure 1: Replay Attack Example (from https://github.com/nkbai/defcon26)

Figure 1 illustrates the replay attack mentioned above. In the UGT contract, the signed message Sig(A, B, 100, 3) is included in the transaction issued by A for sending 100 UGT from A to B and 3 UGT fee from A to C. The interesting thing is that Sig(A, B, 100, 3) works for MTC contract as well. Therefore, the attacker can replay the message on the MTC contract for sending 100 MTC from A to B and 3 MTC fee from A to C.

Figure 2: A proxyOverflow-affected Smart Contract Also Affected by Replay Attacks

The magic under the hood is in line 209-210 in Figure 2. Both contracts validates _from by checking the hash of (_from, _to, _value, _fee, nonce) with (_v, _r, _s). Since the nonce is predictable (line 221), the attacker could replay the signed message on any contract using the same validation mechanism, which leads to the saying “you may have paid more than you imagine” [1].

Figure 3: Replay Attacks In-the-Wild

Researchers at PeckShield analyzed the on-chain data and observed at least seven cases of replay attack in-the-wild. Figure 3 shows one of the cases that eavesdrops the input data embedded in a transaction designated to the UGT contract (TX1) and replays it on the smart contract in another transaction (TX2). The following table shows the transaction hashes in the seven cases of replay attacks we identified:

Case ID TX Hashes
#1 0x66b6cc72509695b565151a3ee85c0e4f6429113e2a1627d8754cf25c6bacf986
#2 0x01a2eb8e9611ad9f7754c304c04362faea7163ec3bb826bf7501dbd8154f2f32
#3 0x1abab4c8db9a30e703114528e31dee129a3a758f7f8abc3b6494aad3d304e43f
#4 0x6da5bf2540d1c6734f0a671ccabb99219e8ef788cf3dfacd73f7af5792c4ac2f
#5 0x0505b20807970f70e474d61806cebd9753adc2104202fd69136f92ecbf16d4e3
#6 0xcb74253c017969d62e672764332f8470502cc1bab47e3c2ef4230a4ae94cdc13
#7 0x580a11c94f63e5d62df611384acbea8fd94a261c4b334ac8bc7e11906b46b32e

We collected above data by grouping all Ethereum transactions with the same input patterns that are likely to be (v, r, s). Besides, we also identified new replay attacks affected contracts that were not included in the report of Zhenxuan Bai et al.

Figure 4: Replay Attacks Affected Smart Contract

So far, the analysis is not finished yet. We believe that there are more cases of replay attacks to be dug out.

About Us

PeckShield Inc. is a leading blockchain security company with the goal of elevating the security, privacy, and usability of current blockchain ecosystem. For any business or media inquires (e.g., smart contract auditing), please contact us at telegram, twitter, or email.