Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Background 2.1 Ethereum Primer 2.2 Whitelisted Address Verification 2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model Motivating Example and Challenges 3.1 Motivating Example 3.2 Challenges 3.3 Limitations of Existing Tools Design of AVVERIFIER and 4.1 Overview 4.2 Notations 4.3 Component#1: Code Grapher 4.4 Component#2: EVM Simulator 4.5 Component#3: Vulnerability Detector Evaluation 5.1 Experimental Setup & Research Questions 5.2 RQ1: Effectiveness & Efficiency 5.3 RQ2: Characteristics of Real-world Vulnerable Contracts 5.4 RQ3: Real-time Detection Discussion 6.1 Threats to Validity and 6.2 Limitations 6.3 Ethical Consideration Related Work Conclusion, Availability, and References Background 2.1 Ethereum Primer 2.2 Whitelisted Address Verification 2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model Background 2.1 Ethereum Primer 2.1 Ethereum Primer 2.2 Whitelisted Address Verification 2.2 Whitelisted Address Verification 2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model 2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model Motivating Example and Challenges 3.1 Motivating Example 3.2 Challenges 3.3 Limitations of Existing Tools Motivating Example and Challenges 3.1 Motivating Example 3.1 Motivating Example 3.2 Challenges 3.2 Challenges 3.3 Limitations of Existing Tools 3.3 Limitations of Existing Tools Design of AVVERIFIER and 4.1 Overview 4.2 Notations 4.3 Component#1: Code Grapher 4.4 Component#2: EVM Simulator 4.5 Component#3: Vulnerability Detector Design of AVVERIFIER and 4.1 Overview Design of AVVERIFIER and 4.1 Overview 4.2 Notations 4.2 Notations 4.3 Component#1: Code Grapher 4.3 Component#1: Code Grapher 4.4 Component#2: EVM Simulator 4.4 Component#2: EVM Simulator 4.5 Component#3: Vulnerability Detector 4.5 Component#3: Vulnerability Detector Evaluation 5.1 Experimental Setup & Research Questions 5.2 RQ1: Effectiveness & Efficiency 5.3 RQ2: Characteristics of Real-world Vulnerable Contracts 5.4 RQ3: Real-time Detection Evaluation 5.1 Experimental Setup & Research Questions 5.1 Experimental Setup & Research Questions 5.2 RQ1: Effectiveness & Efficiency 5.2 RQ1: Effectiveness & Efficiency 5.3 RQ2: Characteristics of Real-world Vulnerable Contracts 5.3 RQ2: Characteristics of Real-world Vulnerable Contracts 5.4 RQ3: Real-time Detection 5.4 RQ3: Real-time Detection Discussion 6.1 Threats to Validity and 6.2 Limitations 6.3 Ethical Consideration Discussion 6.1 Threats to Validity and 6.2 Limitations 6.1 Threats to Validity and 6.2 Limitations 6.3 Ethical Consideration 6.3 Ethical Consideration Related Work Related Work Related Work Conclusion, Availability, and References Conclusion, Availability, and References Conclusion, Availability, and References 5.4 RQ3: Real-time Detection We aim to deploy AVVERIFIER as a real-time detector. Thus, we measured several performance metrics (see §5.4.1). Additionally, we give a case study to illustrate how a vulnerability can be detected by AVVERIFIER before an attack (see §5.4.2). 5.4.1 Quantitative Analysis 5.4.1 Quantitative Analysis We measure two real-world performance metrics. First, we compare the rate of contract creation along block generation to the performance of AVVERIFIER, which can shed light on the responsiveness and real-time applicability of AVVERIFIER. Second, we illustrate the correlation between bytecode length and the consumed time taken for analysis. This metric indicates the scalability of AVVERIFIER with the increasing complexity and size of contracts. Rate on Contract Creation vs. Detection. We directed our attention to the data from Nov. 2022 to Jan. 2023, a period Rate on Contract Creation vs. Detection. of time when contracts are heavily deployed (illustrated in Fig. 3). According to our statistics, these three months cover blocks with the height from 15,870,000 to 16,518,000, accounting for 289,238 deployed contracts. In other words, 0.45 contract is deployed on average within each block. As for BSC, according to a widely known BSC browser, BscScan [15], we can calculate that a block is generated every 3s, and there are 2.1 contracts deployed in each BSC block on average. According to the results in RQ1, each Ethereum contract takes around 6.42s. Therefore, considering the number of contract deployed in each block and the speed of block generation in Ethereum, a single-core processor can be used to deploy AVVERIFIER as a real-time detector. As for BSC, each block spends around 6.42s ×2.1 = 13.48s, greater than the time taken by the block generation. However, the methodologies adopted by AVVERIFIER can be paralleled easily, like analyzing multiple suspicious functions simultaneously. Therefore, a multi-core machine is sufficient. s s Scalability. To evaluate the scalability of AVVERIFIER, we randomly sample 1,000 contracts from the ones deployed within the recent year. Figure 6 presents the relation between the bytecode length and the consumed time. Clearly, there does not exist a linear correlation or even an exponential one between these two metrics. We can also observe that most cases can be finished within 20s. Such a high detection efficiency can be attributed to two points. On the one hand, the detection logic is very efficient. For example, the Detector can effectively screen suspicious functions, and can stop the analysis in time when a vulnerability is encountered. On the other hand, the detection method has few performance bottlenecks. Unlike static symbolic execution techniques, the Simulator can quickly and accurately traverse paths that could lead to vulnerabilities. Therefore, the spent time of AVVERIFIER on each case is not directly proportional to bytecode length, illustrating its scalability. Scalability 5.4.2 Case Study: A Real-world Early-warning Case 5.4.2 Case Study: A Real-world Early-warning Case We illustrate a real-world case that is marked as vulnerable when AVVERIFIER is deployed as a real-time detector on BSC. As there is no source code for the case, Listing 4 illustrates its decompiled version. Moreover, due to the nondisclosure principle, we make a slight change syntactically without modifying its original semantics. As we can see, L2 indicates that the varg2 is an address passed from the external environment (satisfying P1). At L3, the function invokes slip, which takes the varg2 as the target address (satisfying P2). Then, at L4, a require checks the returned value (satisfying P3). Finally, at L5, the contract invokes transfer to transfer tokens to the address referred by varg0. Therefore, attackers can deploy a contract to bypass the verification on v0 to drain this contract out. P1 P2 P3 Notably, we detected this vulnerability on May 18th, 2023, at 6:10 UTC. An attack transaction was initiated 1.5 hours after, at 7:41 UTC. Such a time gap highlights that capability of AVVERIFIER. However, the absence of an automated exploit response mechanism within AVVERIFIER prevented timely intervention, leading to a user loss of $ 30K USD. This incident underscores the importance of designing an automated response tool to mitigate potential financial damages resulted from the address verification vulnerability. Authors: (1) Tianle Sun, Huazhong University of Science and Technology; (2) Ningyu He, Peking University; (3) Jiang Xiao, Huazhong University of Science and Technology; (4) Yinliang Yue, Zhongguancun Laboratory; (5) Xiapu Luo, The Hong Kong Polytechnic University; (6) Haoyu Wang, Huazhong University of Science and Technology. Authors: Authors (1) Tianle Sun, Huazhong University of Science and Technology; (2) Ningyu He, Peking University; (3) Jiang Xiao, Huazhong University of Science and Technology; (4) Yinliang Yue, Zhongguancun Laboratory; (5) Xiapu Luo, The Hong Kong Polytechnic University; (6) Haoyu Wang, Huazhong University of Science and Technology. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv
