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
  0x4076be6ebb1170211f8f753a0b01e63c43ec83c7621cd028e27c837dc342ea88
#2 0x01a2eb8e9611ad9f7754c304c04362faea7163ec3bb826bf7501dbd8154f2f32
  0x84162d25fee68442fc93219a9b10a44bd7da40d60d04ce7089e276678d0dabd7
  0xe8e7705733edb11050b777c6d7124ec39da0fbc787130bb9560e93c7e02abc6c
#3 0x1abab4c8db9a30e703114528e31dee129a3a758f7f8abc3b6494aad3d304e43f
  0xe75e0fe6e815e43f32994621c0adb8c286d13b6ef0f26e62e98dd983dab0d5e5
  0xdf1f045f0c788a8fa3b8ebc6261201ff143394a1487d40672f23dd5739c0306c
#4 0x6da5bf2540d1c6734f0a671ccabb99219e8ef788cf3dfacd73f7af5792c4ac2f
  0x1be7455eb4d6457f2b3d29465f46c6b92a17631a81c10f7ccbd536c9737ec3e1
#5 0x0505b20807970f70e474d61806cebd9753adc2104202fd69136f92ecbf16d4e3
  0x9090114be20c349588f6000a197af36cd982bf63c6e8048fecc23d9eb8203696
#6 0xcb74253c017969d62e672764332f8470502cc1bab47e3c2ef4230a4ae94cdc13
  0x11729fd699eaab9dc5abbe00f90cb9baf35532f9e087045cd3a0e9345c88efb1
#7 0x580a11c94f63e5d62df611384acbea8fd94a261c4b334ac8bc7e11906b46b32e
  0xe0ac08f53c808cfdc19766667ffdf0f154aa939c955b5a92908bace0e5d71506
  0x788d12d6d05934dc4d17ea52b4afa1b997e2086cecbc2c15424fb934ea5cb491

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.

References