Replay Attacks on Ethereum Smart Contracts
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Bai, Zhenxuan
Zheng, Yuwei
Chai, Kunzhe
Wang, Senhua
In this paper, a new replay attack based on Ethereum smart contracts is presented. In the token transfer, the risk of replay attack cannot be completely avoided when the sender's signatures are abused, which can bring the loss to users. And the reason is that the applying scope of the signatures is not properly designed in the smart contracts. To test and verify this loophole, we selected two similar smart contracts for our experiment, at the same time, we used our own accounts in these two contracts to carry out the experiment. Because the same signatures of the two contracts were used in the experiment, we got a double income from sender successfully. The experiment verified that the replay attack is really exist. Besides, the replay attack may exist in multiple smart contracts. We calculated the number of smart contracts with this loophole, as well as the corresponding transaction activities, which find some Ethereum smart contracts are risked for this loophole. According to the vulnerability of the contract signature, the risk level is calibrated and depicted. Furthermore, the replay attack pattern is extended to within contract, cross contract and cross chain, which provide the pertinence and well reference for protection. Finally, the countermeasures are proposed to fix this vulnerability.
 Good morning, Aria Wang. Morning. Thank you for attending our talk. This research is about replay attacks on S&M smart contracts. Now let me give a brief self-introduction. I must emphasize here that Zheng Xianbai is a primary researcher. He did more than half of the work, but for some issues of research, he can't attend this talk today. So the job is all to introduce the research to you. My name is Yiwei Zhang. I am a security researcher of the UNICON team, and this is my colleague, Kun Zhe Cai. UNICON team is a research group within 360 technology. The team was formed in 2014. We focused on the security issues in numerous types of wireless systems, but we also encouraged members to do other research that they are interested in. This is why we also have this topic. Today's talk can present four parts. At the beginning, we will introduce the background of blockchain smart contracts and Ethereum. Then we will discuss security issues about potential risks in smart contracts. Suddenly, we will talk about the key point, replay attack, and we are going to show why it exists and how it works. The last one is demonstration of replay attacks and statistical analysis of similar vulnerabilities. Now let Kun Zhe Cai show the first part. Hello. Hello, everyone. As you know, my name is Kun Zhe Cai. I come from China, so the first topic is in the background and mainly about the introduction of related files of replay attacks, like blockchain smart contracts or Ethereum. We have heard some news about blockchain, but what is blockchain? Blockchain is a large stack globally, directly, and users can interact with it by sending transitions. Each transition is messaged with cryptographic, central, and the order of. The currentization is defined by a mechanism called global conditions. The advantage of blockchain is that it has unified the test bus with the repair of the consulate which allows the system to be completed within three to 60 seconds, rather than three days or more. It offers a very large scale of fault tolerance in which the system can withstand 33 to 40%. The feature still operates under the control of hackers, but the chain does not really trust and is not controlled by any single administrator or organization, except for prevailed chain and crystal team chain. It is able to be audited, external observer can verify the history of transitions. It can operate auto-movements without any human involvement. Next, what actually can blockchain achieve? First, it can actually create a critical case which is digital asset on the blockchain. Right now, sorry, public chains offer their own tokens to remain the rate of updating transitions and the instrumentation of blockchain. Next, it has some non-monetary feature, including the record as a DNS based on blockchain and timestamp mechanism to create high value data. Then, blockchain systems for some other functionality, including concepts that can actually custom the digital asset exchange, digital assets offer options and physical derivatives and generally computer. Sorry, my poor English, so I try to relax. For now, we have no application of blockchain in the field of management. How about those things? About 2013, the public realized that blockchain can be used in hundreds of applications besides that and such as asset, domain name, organization and ownership, market for facetting internet of things, and so on. And how to realize those applications, we need smart contacts. What is smart contacts? It is a computer program running in a secure environment that actually, that automatically transfers the digital assets according to previous rules. For example, I will give you a tip. Support your bed with your girlfriend that she will give you 100 bucks if you can figure out what's inside her shopping bag. Maybe that is a dress or a t-shirt. And you made it, but your girlfriend will not pay you anything. You have to accept it because you have no other way to get your reward. However, if there is a smart contact, once you made your guess current and the code will automatically be enforced and there's a risk and there's a reward. Your solution might be digital token will come into your pocket. So smart contacts are a place of code are living in the blockchain and enforcing certain functionalities. How do you construct the secure environment for smart contacts? Certainly, there are many public chain support smart contacts. And let's see the most popular one. SM. What is SM? It's a blockchain with built-in programming language and it offers maximum app server and work statel. So it is very ideal to process smart contracts. SM has a secure operation system called SM. SM virtual machine also known as EVM. This is not encapsulated by a sandbox, but in fact it is completely isolated. So that is the code that runs inside the EVM does not have access to the network or five system or another process. Even smart contracts have limited contact with another or other smart contracts. With EVM. So our smart contacts can be used in many things. One of them is phantasy including hedging, contact saving, wallet and other now phantasy includes online wallet, decentralized managing and DINS. However, with increasing speed of application of SM and smart contacts, many security issues come along. According to analytics, 100 and 100 new users join as ecosystem on the average. They are quite active and in for delay transitions over one million times on the SM. This is increasing many eyes from hackers and security issues come up for more frequently. In many parts of our ecosystem such as exchange, wallet and smart con ATC, there are several security issues come up including attack and wallet hijacking and overflow attack in smart contacts. As to smart contact which is most one-binable in the system, there are also many security issues. Just for 2018 in April, contact such as BS were detected with one-binity. In May, security attacks to several contacts like EDU or other. In June, there are another security issues reported to smart contact like SNS or this open air loophole made a huge impact on the module exchange affecting several functions including talking as nature. Talking with draw. According to the most recent research papers from University College London after organizing the SM, it was reported that the SM would be close to one million smart contacts and 34,200 of them are one-binable to hacking. So in the case of smart contact and phone, it's at 8 and 9% of the current low-post. How to lower the probability of loss? First, we require complete and objective doubt for our contact. And second, when any low-post is found, we need to make any emergency response so that we could now at first time, this contact is beginning attack. And third, there need to be some reverse for those who detect and report any bugs to perspective, and send the whole system is operate. And so next part is my college, my, has some guy, and by the way, I'm very sorry my English. So, so, give you next good one. Hi, I'm back now. Next, we are going to focus on the issue of replay attacks in smart contract. Now let me explain the concept of replay attack. Distinguished from replay attack in traditional network world, it's not to capture and impact. If transaction is legitimate on one blockchain, it's also legitimate on another blockchain. So when you transfer BTC1, your BTC2 or BTC3 may be transferred at the same time. That is the replay attack in blockchain. To replay attack, we found that many smart contracts adopted the same way to verify the validity of the signature. And it's possible for replay attack. Our motivation is that we propose replay attack all smart contracts and we should attract the user's attention. We try to detect the vulnerability in smart contracts and make them more secure. Finally, we want to enhance the risk awareness for contract creator and ensure interest of the users. To achieve our goal, we have done several things that we found that the replay attack problem exists in 52 smart contracts. And we analyzed the smart contract example to verify the replay attack. We analyzed the source and process of replay attack to expand the feasibility of replay attack in principle. We also verified the replay attack based on the signature vulnerability. And finally, we proposed defense strategy to prevent this problem. Then I'm going to show you something. The first item is vulnerability scanning. Our aim is to get the name and the number of vulnerability or replay attack in smart contracts. And we set the three scanning lines to discover the smart contracts which have the vulnerability. First, judging whether the contract is accorded with the BRC20 standard, this requires the total supply to be greater than zero. Second, get the name of the contract to determine whether the name is valid. Thirdly, failed smart contract is vulnerable to replay attack. The SORM provides easy recovery function to verify signature. If a contract is used to recover function, it will market as suspicious. This scanning program can be found at the following site. It's in our GitHub storage. After we audited and verified the scanning output, we found 52 risk targets. And this is coded to scan ERC20 token contract. You can get it from our GitHub storage. Why does the replay attack occur? The signature of a user will utilize the smart contracts. If the contents of the signature were not correctly limited by the smart contracts, there is possibility of replay attack, such as the interface transfer proxy. Here is an example. The contents of the MTC contract signature and the contents of the UGT contract signature are exactly the same. This is an example. In the contract, the issue lines like this line, the KECC, a K256 function, calculate the hash. And the hash is the input of the signature. So we can see in the parameter of this function, it's just a form, tool, value, fit, and announce. There is nothing related to the contract itself exactly. So we explain the attack process. When separate the transaction in a contract one, user A wanted to transfer 100 tokens to user B through proxy C. And the access address through token should be paid for proxy C as service fee. In this process, the input of the signature of user A should be A, B, 103, and the latest month one. Then the transfer was carried by proxy C. After this transaction being completed, user B can get 100 tokens from user A. Whereas suppose user A doesn't carry out the transfer on a contract two through proxy C. So the latest month is also one. Whereas suppose user A, now the replay attack starts. After we see 100 tokens from user A, user B replays the signature of user A from I, I contract one in I contract two. Now he can get another 100 tokens in I contract two without the permission of user A. That is to say the smart contract, I contract two were attacked by user B and 100 tokens of user A were stolen. Next, to verify the existence of this vulnerability, we conducted an experiment. The experiment condition at least as a follow. We choose two ERC 20 smart contracts, the UGT contracts and the MTC contract. Then we create two accounts, Alice and Bob. Then we deposit some tokens in the two accounts in corresponding contracts. And the procedure of this verification is that in step one, the normal transaction records on the Ethereum were scanned to find out accounts which had both UGT tokens and MTC tokens. But here we use two accounts, Alice and Bob. In step two, Bob induced Alice to send him to UGT's tokens and the transaction input data is shown below. The length 0 to 6 corresponds to the augmentation of the function transfer proxies. In step three, Bob takes out the input data of this transaction on the blockchain. The parameter from two values, phi, r, v and s, where it is extracted from this method. The following is the implementation of the transfer function. In step four, Bob uses the input data in step two to execute another transfer in the smart contract of MTC. The result of this transaction is shown below. In step five, Bob got not only two UGT tokens, but also two MTC tokens from Alice. In this procedure, the transfer of two MTC tokens was not authorized by Alice. Now we come into the final part, demonstration and analytics. To begin with the demonstration, we select two contracts, the UGT contracts and the MTC contracts. Then we set two of our own accounts, Alice and Bob. Alice is the sender and Bob is the receiver. Both the two accounts own some tokens for transferring. Next, this is the port code. It encodes the parameter from two values, phi, v, r, s, all acquired from UGT. This is the caller parameter read from the chain. The parameter r, s, and v are signatures. In another token replay from two, phi are exactly the same as the last call. The simple proxy transfer scenario is that firstly, UGA delegates to the start party to help him transfer tokens. Then UGA gets the address of the contract and creates the instance of the token to be transferred. After that, they will get the signature from UGA and invoke the transfer function provided by the contractor to send the token to the token receiver, UGA B. Then the proxy C. We are waiting for the information that the miner has down the package process and finally, the transaction process finishes. Now let me show you the demo. For comparison, I curious the balance of Bob on both UGT contracts and MTC contracts. He has six tokens on both the two contracts. Now I transfer three tokens from Alice to Bob on UGT contracts through a cross-area. We have few seconds for the miner to pack. Now I curious the signature. I curious the balance of Bob on both UGT contracts and MTC contracts again. The balance on UGT is 9, but on MTC is still 6. I copy the parameters from UGT to MTC and start the replay attack. You can see here I just need to input the password of the proxy. I don't need to input the password of Alice. It means that we don't need the pan-miching of Alice. It's finished. Now I curious the balance of Bob on MTC. We can see the balance is 9 now. Bob stole three tokens on MTC contracts. To show you the impact of this vulnerability, we also made some related statistics and analysis. By April 27, the vulnerability of this replay attack risked in 52 Ethereum smart contracts. Finally, according to the vulnerability of the replay attack, we divided these contracts into three groups. The group 1, there are 10 contracts. No specific information is contained in the signature of smart contracts. So the signature can be fully realized. In the group 2, there are 37 contracts. In these contracts, specific string is added to the input of the signature, but the signature can still be realized. In the group 3, the address of the contract or the address of the sender is contained in the signature of smart contracts. But there are strong restrictions that they still have the possibility of replay attack. Secondly, we classified these contracts by feasible replay attack approach. Now, contracts can be replayed in the specific contract itself. And another 45 contracts can be replayed between different contracts. Besides, we divided these 45 contracts into three groups for the specific prefix data used in the signature. All contracts replays may happen among any contracts as long as they are in the same group. The group 1 and the group 2 both add specific identical data to the input of the signature. We mark the specific prefix data used in group 1 as data 1. And we mark the specific prefix data used in group 2 as data 2. For example, you can see that in these contracts, the same string is the ashram sender message. In group 3, they don't add any prefix data to the input of the signature just from to value 3 and non-s. And there are two chains that can be replayed between test chain and main chain. Sadly, according to the trading frequency of above mentioned contracts, by April 13, 24 contracts were found, which had the transaction records within one week. And the nine contracts were found, which have the transaction records from one week to one month. The proportion of nearly 20% of the total number of the contracts is active. 16 contracts were found, which have the transaction records beyond one month. And three contracts only have the records for deployment. So according to the comprehensive analysis, 16% of the contract transactions are still active. The reason for replay attacking smart contracts is that they misuse the signature when constructing the contractor. So our countermeasures are listed here. First, the designers of smart contracts should always conform the suitable range of digital signature when designing smart contracts. Second, the smart contracts deployed on public chain should add in the specific information of the public chain, such as the chain ID, and the name of the public chain, and other identical information. Finally, the user of smart contracts needs to pay attention to news and reports concerning the vulnerability disclosure. And the conclusion is that the security problems of smart contracts have been widely concerned. As long as the signature was misused in smart contracts, there is possibility of replay attack. We believe that the vulnerabilities on the Ethereum smart contracts have not totally come to light. Thank you for listening to our call. If some guys have some questions about this attack, you can send the mail to us. Thank you.
 Good morning, Aria Wang.  Morning.  Thank you for attending our talk.  This research is about replay attacks on S&M smart contracts.  Now let me give a brief self-introduction.  I must emphasize here that  Zheng Xianbai is a primary researcher.  He did more than half of the work,  but for some issues of research, he can't attend this talk today.  So the job is all to introduce the research to you.  My name is Yiwei Zhang.  I am a security researcher of the UNICON team,  and this is my colleague, Kun Zhe Cai.  UNICON team is a research group within 360 technology.  The team was formed in 2014.  We focused on the security issues in numerous types of wireless systems,  but we also encouraged members to do other research that they are interested in.  This is why we also have this topic.  Today's talk can present four parts.  At the beginning, we will introduce the background of blockchain smart contracts and Ethereum.  Then we will discuss security issues about potential risks in smart contracts.  Suddenly, we will talk about the key point, replay attack,  and we are going to show why it exists and how it works.  The last one is demonstration of replay attacks  and statistical analysis of similar vulnerabilities.  Now let Kun Zhe Cai show the first part.  Hello.  Hello, everyone. As you know, my name is Kun Zhe Cai.  I come from China, so the first topic is in the background  and mainly about the introduction of related files of replay attacks,  like blockchain smart contracts or Ethereum.  We have heard some news about blockchain, but what is blockchain?  Blockchain is a large stack globally, directly,  and users can interact with it by sending transitions.  Each transition is messaged with cryptographic, central, and the order of.  The currentization is defined by a mechanism called global conditions.  The advantage of blockchain is that it has unified the test bus with  the repair of the consulate which allows the system to be completed within three to 60 seconds,  rather than three days or more.  It offers a very large scale of fault tolerance in which the system can withstand 33 to 40%.  The feature still operates under the control of hackers,  but the chain does not really trust and is not controlled by any single administrator or organization,  except for prevailed chain and crystal team chain.  It is able to be audited, external observer can verify the history of transitions.  It can operate auto-movements without any human involvement.  Next, what actually can blockchain achieve?  First, it can actually create a critical case which is digital asset on the blockchain.  Right now, sorry, public chains offer their own tokens to remain the rate of updating transitions  and the instrumentation of blockchain.  Next, it has some non-monetary feature, including the record as a DNS based on blockchain  and timestamp mechanism to create high value data.  Then, blockchain systems for some other functionality, including concepts that can actually  custom the digital asset exchange, digital assets offer options and physical derivatives and generally computer.  Sorry, my poor English, so I try to relax.  For now, we have no application of blockchain in the field of management.  How about those things?  About 2013, the public realized that blockchain can be used in hundreds of applications  besides that and such as asset, domain name, organization and ownership, market for facetting  internet of things, and so on.  And how to realize those applications, we need smart contacts.  What is smart contacts?  It is a computer program running in a secure environment that actually, that automatically  transfers the digital assets according to previous rules.  For example, I will give you a tip.  Support your bed with your girlfriend that she will give you 100 bucks if you can figure  out what's inside her shopping bag.  Maybe that is a dress or a t-shirt.  And you made it, but your girlfriend will not pay you anything.  You have to accept it because you have no other way to get your reward.  However, if there is a smart contact, once you made your guess current and the code will  automatically be enforced and there's a risk and there's a reward.  Your solution might be digital token will come into your pocket.  So smart contacts are a place of code are living in the blockchain and enforcing certain  functionalities.  How do you construct the secure environment for smart contacts?  Certainly, there are many public chain support smart contacts.  And let's see the most popular one.  SM.  What is SM?  It's a blockchain with built-in programming language and it offers maximum app server and  work statel.  So it is very ideal to process smart contracts.  SM has a secure operation system called SM.  SM virtual machine also known as EVM.  This is not encapsulated by a sandbox, but in fact it is completely isolated.  So that is the code that runs inside the EVM does not have access to the network or five  system or another process.  Even smart contracts have limited contact with another or other smart contracts.  With EVM.  So our smart contacts can be used in many things.  One of them is phantasy including hedging, contact saving, wallet and other now phantasy  includes online wallet, decentralized managing and DINS.  However, with increasing speed of application of SM and smart contacts, many security issues  come along.  According to analytics, 100 and 100 new users join as ecosystem on the average.  They are quite active and in for delay transitions over one million times on the SM.  This is increasing many eyes from hackers and security issues come up for more frequently.  In many parts of our ecosystem such as exchange, wallet and smart con ATC, there are several  security issues come up including attack and wallet hijacking and overflow attack in smart  contacts.  As to smart contact which is most one-binable in the system, there are also many security  issues.  Just for 2018 in April, contact such as BS were detected with one-binity.  In May, security attacks to several contacts like EDU or other.  In June, there are another security issues reported to smart contact like SNS or this open  air loophole made a huge impact on the module exchange affecting several functions including  talking as nature.  Talking with draw.  According to the most recent research papers from University College London after organizing  the SM, it was reported that the SM would be close to one million smart contacts and 34,200  of them are one-binable to hacking.  So in the case of smart contact and phone, it's at 8 and 9% of the current low-post.  How to lower the probability of loss?  First, we require complete and objective doubt for our contact.  And second, when any low-post is found, we need to make any emergency response so that  we could now at first time, this contact is beginning attack.  And third, there need to be some reverse for those who detect and report any bugs to  perspective, and send the whole system is operate.  And so next part is my college, my, has some guy, and by the way, I'm very sorry my English.  So, so, give you next good one.  Hi, I'm back now.  Next, we are going to focus on the issue of replay attacks in smart contract.  Now let me explain the concept of replay attack.  Distinguished from replay attack in traditional network world, it's not to capture and  impact.  If transaction is legitimate on one blockchain, it's also legitimate on another blockchain.  So when you transfer BTC1, your BTC2 or BTC3 may be transferred at the same time.  That is the replay attack in blockchain.  To replay attack, we found that many smart contracts adopted the same way to verify the  validity of the signature.  And it's possible for replay attack.  Our motivation is that we propose replay attack all smart contracts and we should attract  the user's attention.  We try to detect the vulnerability in smart contracts and make them more secure.  Finally, we want to enhance the risk awareness for contract creator and ensure interest of  the users.  To achieve our goal, we have done several things that we found that the replay attack  problem exists in 52 smart contracts.  And we analyzed the smart contract example to verify the replay attack.  We analyzed the source and process of replay attack to expand the feasibility of replay  attack in principle.  We also verified the replay attack based on the signature vulnerability.  And finally, we proposed defense strategy to prevent this problem.  Then I'm going to show you something.  The first item is vulnerability scanning.  Our aim is to get the name and the number of vulnerability or replay attack in smart  contracts.  And we set the three scanning lines to discover the smart contracts which have the vulnerability.  First, judging whether the contract is accorded with the BRC20 standard, this requires the  total supply to be greater than zero.  Second, get the name of the contract to determine whether the name is valid.  Thirdly, failed smart contract is vulnerable to replay attack.  The SORM provides easy recovery function to verify signature.  If a contract is used to recover function, it will market as suspicious.  This scanning program can be found at the following site.  It's in our GitHub storage.  After we audited and verified the scanning output, we found 52 risk targets.  And this is coded to scan ERC20 token contract.  You can get it from our GitHub storage.  Why does the replay attack occur?  The signature of a user will utilize the smart contracts.  If the contents of the signature were not correctly limited by the smart contracts, there is  possibility of replay attack, such as the interface transfer proxy.  Here is an example.  The contents of the MTC contract signature and the contents of the UGT contract signature are  exactly the same.  This is an example.  In the contract, the issue lines like this line, the KECC, a K256 function, calculate the hash.  And the hash is the input of the signature.  So we can see in the parameter of this function, it's just a form, tool, value, fit, and announce.  There is nothing related to the contract itself exactly.  So we explain the attack process.  When separate the transaction in a contract one, user A wanted to transfer 100 tokens to user B  through proxy C. And the access address through token should be paid for proxy C as service fee.  In this process, the input of the signature of user A should be A, B, 103, and the latest month one.  Then the transfer was carried by proxy C. After this transaction being completed, user B can get 100 tokens from user A.  Whereas suppose user A doesn't carry out the transfer on a contract two through proxy C.  So the latest month is also one.  Whereas suppose user A, now the replay attack starts.  After we see 100 tokens from user A, user B replays the signature of user A from I, I contract one in I contract two.  Now he can get another 100 tokens in I contract two without the permission of user A.  That is to say the smart contract, I contract two were attacked by user B and 100 tokens of user A were stolen.  Next, to verify the existence of this vulnerability, we conducted an experiment.  The experiment condition at least as a follow.  We choose two ERC 20 smart contracts, the UGT contracts and the MTC contract.  Then we create two accounts, Alice and Bob.  Then we deposit some tokens in the two accounts in corresponding contracts.  And the procedure of this verification is that in step one, the normal transaction records on the Ethereum were scanned to find out accounts  which had both UGT tokens and MTC tokens.  But here we use two accounts, Alice and Bob.  In step two, Bob induced Alice to send him to UGT's tokens and the transaction input data is shown below.  The length 0 to 6 corresponds to the augmentation of the function transfer proxies.  In step three, Bob takes out the input data of this transaction on the blockchain.  The parameter from two values, phi, r, v and s, where it is extracted from this method.  The following is the implementation of the transfer function.  In step four, Bob uses the input data in step two to execute another transfer in the smart contract of MTC.  The result of this transaction is shown below.  In step five, Bob got not only two UGT tokens, but also two MTC tokens from Alice.  In this procedure, the transfer of two MTC tokens was not authorized by Alice.  Now we come into the final part, demonstration and analytics.  To begin with the demonstration, we select two contracts, the UGT contracts and the MTC contracts.  Then we set two of our own accounts, Alice and Bob. Alice is the sender and Bob is the receiver.  Both the two accounts own some tokens for transferring.  Next, this is the port code. It encodes the parameter from two values, phi, v, r, s, all acquired from UGT.  This is the caller parameter read from the chain. The parameter r, s, and v are signatures.  In another token replay from two, phi are exactly the same as the last call.  The simple proxy transfer scenario is that firstly, UGA delegates to the start party to help him transfer tokens.  Then UGA gets the address of the contract and creates the instance of the token to be transferred.  After that, they will get the signature from UGA and invoke the transfer function provided by the contractor to send the token to the token receiver, UGA B.  Then the proxy C. We are waiting for the information that the miner has down the package process and finally, the transaction process finishes.  Now let me show you the demo.  For comparison, I curious the balance of Bob on both UGT contracts and MTC contracts.  He has six tokens on both the two contracts.  Now I transfer three tokens from Alice to Bob on UGT contracts through a cross-area.  We have few seconds for the miner to pack.  Now I curious the signature.  I curious the balance of Bob on both UGT contracts and MTC contracts again.  The balance on UGT is 9, but on MTC is still 6.  I copy the parameters from UGT to MTC and start the replay attack.  You can see here I just need to input the password of the proxy.  I don't need to input the password of Alice.  It means that we don't need the pan-miching of Alice.  It's finished.  Now I curious the balance of Bob on MTC.  We can see the balance is 9 now.  Bob stole three tokens on MTC contracts.  To show you the impact of this vulnerability, we also made some related statistics and analysis.  By April 27, the vulnerability of this replay attack risked in 52 Ethereum smart contracts.  Finally, according to the vulnerability of the replay attack, we divided these contracts into three groups.  The group 1, there are 10 contracts.  No specific information is contained in the signature of smart contracts.  So the signature can be fully realized.  In the group 2, there are 37 contracts.  In these contracts, specific string is added to the input of the signature, but the signature can still be realized.  In the group 3, the address of the contract or the address of the sender is contained in the signature of smart contracts.  But there are strong restrictions that they still have the possibility of replay attack.  Secondly, we classified these contracts by feasible replay attack approach.  Now, contracts can be replayed in the specific contract itself.  And another 45 contracts can be replayed between different contracts.  Besides, we divided these 45 contracts into three groups for the specific prefix data used in the signature.  All contracts replays may happen among any contracts as long as they are in the same group.  The group 1 and the group 2 both add specific identical data to the input of the signature.  We mark the specific prefix data used in group 1 as data 1.  And we mark the specific prefix data used in group 2 as data 2.  For example, you can see that in these contracts, the same string is the ashram sender message.  In group 3, they don't add any prefix data to the input of the signature just from to value 3 and non-s.  And there are two chains that can be replayed between test chain and main chain.  Sadly, according to the trading frequency of above mentioned contracts, by April 13, 24 contracts were found,  which had the transaction records within one week.  And the nine contracts were found, which have the transaction records from one week to one month.  The proportion of nearly 20% of the total number of the contracts is active.  16 contracts were found, which have the transaction records beyond one month.  And three contracts only have the records for deployment.  So according to the comprehensive analysis, 16% of the contract transactions are still active.  The reason for replay attacking smart contracts is that they misuse the signature when constructing the contractor.  So our countermeasures are listed here.  First, the designers of smart contracts should always conform the suitable range of digital signature when designing smart contracts.  Second, the smart contracts deployed on public chain should add in the specific information of the public chain,  such as the chain ID, and the name of the public chain, and other identical information.  Finally, the user of smart contracts needs to pay attention to news and reports concerning the vulnerability disclosure.  And the conclusion is that the security problems of smart contracts have been widely concerned.  As long as the signature was misused in smart contracts, there is possibility of replay attack.  We believe that the vulnerabilities on the Ethereum smart contracts have not totally come to light.  Thank you for listening to our call.  If some guys have some questions about this attack, you can send the mail to us.  Thank you.
DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_0_95.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_96_431.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_432_3443.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_3444_3491.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_3492_3791.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_3792_3959.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_3960_4811.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_4812_6887.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_6888_7151.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_7152_12527.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_12528_13379.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_13380_15311.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_15312_15659.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_15660_19967.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_19968_20867.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_20868_22043.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_22044_22091.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_22092_22247.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_22248_22295.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_22296_22463.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_22464_23375.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_23376_23567.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_23568_23951.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_23952_24035.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_24036_27239.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_27240_28655.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_28656_28943.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_28944_29063.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_29064_30299.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_30300_31439.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_31440_36335.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_36336_37031.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_37032_37547.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_37548_37667.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_37668_37895.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_37896_38567.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_38568_39179.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_39180_39419.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_39420_40283.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_40284_42443.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_42444_45443.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_45444_48143.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_48144_50447.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_50448_51731.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_51732_54611.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_54612_57971.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_57972_58031.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_58032_58367.png DEF_CON_26_-_Zhenxuan_Bai_and_Panel_-_Replay_Attacks_on_Ethereum_Smart_Contracts_uBU3Myiauls_58368_58575.png