How to Find Smart Contract Vulnerabilities Before Exploit Happen | HackerNoon

Table of Links

Abstract and 1. Introduction

2. Background

   2.1 Ethereum Primer

   2.2 Whitelisted Address Verification

   2.3 Taint Analysis on Smart Contracts and 2.4 Threat Model

3. Motivating Example and Challenges

   3.1 Motivating Example

   3.2 Challenges

   3.3 Limitations of Existing Tools

4. 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

5. 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

6. Discussion

   6.1 Threats to Validity and 6.2 Limitations

   6.3 Ethical Consideration

7. Related Work

8. 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

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

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.

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.

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.

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.