EVulHunter: Detecting Fake Transfer Vulnerabilities for EOSIO's Smart Contracts at Webassembly-level

by   Lijin Quan, et al.

As one of the representative Delegated Proof-of-Stake (DPoS) blockchain platforms, EOSIO's ecosystem grows rapidly in recent years. A number of vulnerabilities and corresponding attacks of EOSIO's smart contracts have been discovered and observed in the wild, which caused a large amount of financial damages. However, the majority of EOSIO's smart contracts are not open-sourced. As a result, the WebAssembly code may become the only available object to be analyzed in most cases. Unfortunately, current tools are web-application oriented and cannot be applied to EOSIO WebAssembly code directly, which makes it more difficult to detect vulnerabilities from those smart contracts. In this paper, we propose , a static analysis tool that can be used to detect vulnerabilities from EOSIO WASM code automatically. We focus on one particular type of vulnerabilities named fake-transfer, and the exploitation of such vulnerabilities has led to millions of dollars in damages. To the best of our knowledge, it is the first attempt to build an automatic tool to detect vulnerabilities of EOSIO's smart contracts. The experimental results demonstrate that our tool is able to detect fake transfer vulnerabilities quickly and precisely. EVulHunter is available on GitHub[Tool and benchmarks: https://github.com/EVulHunter/EVulHunter] and YouTube[Demo video: https://youtu.be/5SJ0ZJKVZvw].


Security Analysis of EOSIO Smart Contracts

The EOSIO blockchain, one of the representative Delegated Proof-of-Stake...

DEPOSafe: Demystifying the Fake Deposit Vulnerability in Ethereum Smart Contracts

Cryptocurrency has seen an explosive growth in recent years, thanks to t...

ESBMC-Solidity: An SMT-Based Model Checker for Solidity Smart Contracts

Smart contracts written in Solidity are programs used in blockchain netw...

Precise Attack Synthesis for Smart Contracts

Smart contracts are programs running on top of blockchain platforms. The...

SmartBugs: A Framework to Analyze Solidity Smart Contracts

Over the last few years, there has been substantial research on automate...

Vulnerabilities and Open Issues of Smart Contracts: A Systematic Mapping

Smart Contracts (SCs) are programs stored in a Blockchain to ensure agre...

Characterizing Code Clones in the Ethereum Smart Contract Ecosystem

In this paper, we present the first large-scale and systematic study to ...

I Introduction

With the growing prosperity of cryptocurrencies like Bitcoin, blockchain techniques has become more attractive and been adopted by different aeras, such as financial and logistical systems. Due to the limited throughput (e.g., Transaction Per Second, aka TPS) derived from the essence of the Proof-of-Work (PoW) consensus, traditional blockchain platforms (e.g., Bitcoin and Ethereum), cannot be used to support high-performing applications. Researchers proposed different consensuses, such as Proof-of-Share (PoS) and Delegated Proof-of-Stake (DPoS), to resolve the performance issue.

As one of the most representative DPoS platforms and the first decentralized operating system, EOSIO [2] has become one of the most active communities all over the world. EOSIO adopts a multi-threaded mechanism based on its DPoS consensus protocol [6]. EOSIO claims that it is capable of achieving millions of TPS. The main native token of EOSIO is called EOS. The amount of EOS tokens of the holders are used to allocate system resources (e.g., bandwidth and storage), vote and participate in the on-chain governance, according to the corresponding proportion of the total stake. Briefly speaking, 21 Block Producers (BPs) are voted during its launch, and a validate block is generated every 500 ms block time by those BPs in a round-robin schedule.

Smart contract is a computer protocol which allows users to digitally negotiate an agreement in a convenient and secure way [3]. In contrast to the traditional contract law, the transaction costs of the smart contract are dramatically reduced, and the correctness of its execution is ensured by the consensus protocol. EOSIO’s smart contracts can be written in C++ , which will be compiled down to WebAssembly (aka WASM) and executed in EOSIO WASM virtual machine. WASM is a web standards specifying the binary instruction format for a stack-based virtual machine, and it can be run in modern web browsers and other environments [5].

However, it is not easy to guarantee the security of the implementation of smart contracts, new platforms in particular. A number of vulnerabilities have been discovered from EOSIO’s smart contracts, including fake EOS transfer, fake transfer notice and flawed random numbers generators. As such, severe attacks have been observed in the wild, which caused a large amount of financial damages.

Unfortunately, most Decentralized Applications (DApps) projects on EOSIO are not open-sourced, while the web-application oriented analyzed tools cannot be applied to EOSIO WASM code directly, which makes it more difficult to detect vulnerabilities from those smart contracts. Specifically, there does exist two major challenges must be overcome. First of all, since the EOSIO WASM code does not contain context information (e.g., symbols, function names and type information), we have to infer the indexes of the functions we are interested in, including relevant system functions and functions implemented by the developer. Secondly, the Contract Development Toolkit (CDT) of EOSIO has been evolving ever since the launch of the mainnet, and we have to cover variants because of the changes caused by CDT(s).

In this paper, we propose a static analysis tool named EVulHunter which can be used to detect vulnerabilities from EOSIO WASM code automatically. Specifically, it first traverses the WASM code and constructs the corresponding Control Flow Graphs (CFGs), and then detects the existence of vulnerabilities based on predefined patterns. To facilitate the deep analyses, EVulHunter also contains a WASM Simulator module which is capable of performing the simulated code execution. Besides, we focus on one particular type of vulnerabilities named fake-transfer with two variants,  fake EOS transfer and fake transfer notice. The exploitation of fake-transfer vulnerability has led to millions of dollars in damages from gambling DApps.

To the best of our knowledge, our work is the first attempt to build an automatic tool to detect vulnerabilities of EOSIO’s smart contracts. The experimental results demonstrate that our system is able to detect target vulnerabilities quickly and precisely with low false positives. Our efforts can positively shed some light on the exploration of vulnerability detection of EOSIO’s smart contracts.

Ii Background

Ii-a EOSIO’s Smart Contract

In EOSIO, an action (a base32 encoded 64-bit integer) is used to represent a single operation, which can be sent individually, or in a combined form, to serve the purpose of communication between a smart contact and an account [4]. A transaction is composed of one or more actions.

In order to handle requested actions, an apply function is necessary to dispatch corresponding action handlers for any validate smart contract. Specifically, apply function listens to all incoming actions and execute the concrete action handlers accordingly. To this end, the input parameters of apply function, i.e., the receiver (the account that is currently processing the action), code (the account that authorized the contract), and action (the ID of the currently running action), are used as filters to map to the desired functions that implement particular actions [4].

As one of the 5 fundamental smart contracts of EOSIO333Namely EOSIO.contracts, i.e., eosio.bios, eosio.token, exchange, eosio.msig, eosio.system, eosio.token contract is a token standard (like Ethereum’s ERC20 standard) contract which enables the creation of many different tokens all running on the same contract but potentially managed by different users [1]. It can be used to create, issue and transfer tokens [4], and the transfer functionality is related to the target fake-transfer vulnerabilities.

Ii-B Fake-Transfer Vulnerabilities

Figure 1 shows the lifecycle of a transfer action. Firstly a user sends the transfer action to the eosio.token contract. After that, the eosio.token contract will modify the balances accordingly, and then launch the following two invocations: require_recipient (from) and require_recipient (to), from and to are source account and destination account respectively. Finally, if any account has been deployed with a contract, and there does exist a pre-defined transfer action handler in this contract, the handler would be invoked.

Fig. 1: The lifecycle of a transfer action.

Fake EOS Transfer. As mentioned earlier, the code parameter of the apply function represents the account that authorized the contract. Obviously, the code parameter of the apply function of the victim (i.e., the recipient to) should be eosio.token in a normal transfer action. However, if an implementation of the apply function did not verify the code parameter properly, it might be deceived into receiving fake EOS tokens and then executing the further code logic.

Fake EOS Notice. It is an advanced variant of fake-transfer vulnerabilities with a well-implemented apply function. However, two parameters of the transfer function, i.e., to and _self, have not been checked for equality. Specifically, the attacker was able to create an intermediate contract that forwarding the incoming transfer action to the victim contract. As such, the victim contract would be misled into believing it was receiving EOS tokens.

Iii Approach

In this section, we will first introduce the overall design of the proposed EVulHunter system, and then depict each component individually.

Fig. 2: Overview of EVulHunter.

Iii-a Overview

Figure 2 illustrates the framework of the proposed system, which accepts the EOSIO WASM code as the input. EVulHunter is composed of three modules, including CFG Builder, WASM Simulator and Detector Engine.

We first build the CFGs based on Octopus444https://github.com/quoscient/octopus, an open source project that is able to parse EOSIO WASM code. Specifically, the CFGs of the apply function will be generated in our CFG builder. After that, the entire CFGs will go through the Detector Engine module. To facilitate the analyses, specific Basic Blocks (BBs) might be selected to be executed by the WASM Simulator on demand, where the stack the linear memory would be rebuilt to serve the purpose.

We will describe WASM Simulator and Detector Engine in the following subsections, III-B and III-C respectively.

Iii-B WASM Simulator

WASM Simulator is designed to be a simple, concise and generic Virtual Machine (VM) to support further analyses with high extensibility. Basically, this VM keeps a Stack and Memory structure, which will be modified during tracing instructions of the WASM code. To facilitate the analysis, several special patterns have been observed and summarized, including _self, from, to and strings in a format of 32-bit encoding integer, so that the simulator is able to recover the semantic type information by mimicking the code execution. For example, get_local 7 means a popped value from the stack will be assigned to a variable named local7, even without the knowledge of the value type. After simulated execution, it is possible to determine that local7 represents a base32 encoded 64-bit integer and is exactly the “eosio.token” in the context.

Locating Indirect Call Functions. The WASM Simulator can be used to locate indirect call functions in the apply function, which is the first challenge mentioned in Section I. Specifically, the link between the apply function and the target function is implemented with the indirect call mechanism by using an API named execute_action() in all the versions of CDT. Although different CDT may have different implementations, the invariant feature is that the indirect call function pointer is always the last parameter of the execute_action() function. As the top item in the stack is always the index number of the indirect call function when calling execute_action, we can use this feature to determine the indexes of the functions in the corresponding WASM code.

Iii-C Detector Engine

All detectors are wrapped in the Detector Engine module, which may conduct deep analyses by interacting with the WASM Simulator when necessary. We have implemented two detectors for fake EOS transfer and fake transfer notice vulnerabilities respectively, as follows:

  • In case of fake EOS transfer, if none of the functions pre-defined by the developer is likely to be invoked when the incoming action is not authorized by eosio.token, which further suggests that the transfer function won’t be invoked as well, therefore it is not vulnerable to fake EOS transfer vulnerability; otherwise it is tagged as a vulnerable contract.

  • In case of fake transfer notice, if there exists a comparison between to and _self in the transfer function, it is not vulnerable to fake transfer notice vulnerability; otherwise it is tagged as a vulnerable contract.

Covering Variants. We have to handle two types of variants. Firstly, variants derived from the the evolutions of CDT. Secondly, variants come from one specific verion of CDT, by which even the same logic might be served by different groups of WASM instructions. We have tried our best to summarize and cover cases as many as possible, if not all, to make the detectors robust and complete. All variants being analyzed are summarized in Fig. 3, including comparison patterns, comparison pairs and corresponding descriptions of elements being compared shown in elliptical boxes. There are 3 comparison patterns and 2 comparison pairs respectively, implying 6 combinations in total.

Fig. 3: Summary of Covering Variants.

Iv Evaluation

# Vulnerable # Non-vulnerable # Total
Fake EOS Transfer 75 109 184
Fake EOS Notice 141 54 195
Total 159 82 241
TABLE I: The Distribution of our benchmark.
True Positive False Positive True Negative False Negative Precision Recall Accuracy
Fake EOS Transfer 75 26 83 0 74.26% 100% 85.87%
Fake EOS Notice 141 0 54 0 100% 100% 100%
Total 216 26 137 0 89.26% 100% 93.14%
TABLE II: The Overall Experiment Result.

Iv-a Benchmark

It appear that no available benchmarks on vulnerable EOS smart contracts in our community could be used for evaluation. Thus, we propose to manually craft a benchmark from the known reported vulnerable Dapps555https://github.com/peckshield/EOS/tree/master/known_dapp_attacks. For example, it is reported that EOSBet contract was attacked by exploiting the fake EOS transfer vulnerability in September 2018, and it suffered from the fake EOS notice vulnerability in October 2018. In this way, we seek to identify the corresponding vulnerable versions of the reported smart contracts, and then collect the patched ones with no vulnerabilities.

At last, we have collected 241 EOS smart contracts in total (with 159 vulnerable ones), 184 of them were used as the benchmark of fake EOS transfer vulnerability, and 195 of them were used to evaluate the fake EOS notice vulnerability detection. The distribution of our benchmark is shown in Table I. Note that one smart contract could have both fake EOS transfer and fake EOS notice vulnerabilities.

Iv-B Detection Result

Overall Result. Table II

shows the overall detection result. For the fake EOS transfer vulnerability, our tool could achieve an overall accuracy of 86%, while for the fake EOS notice vulnerability, we could achieve an overall accuracy of 100%. This result suggests that EVulHunter is able to detect the fake notice vulnerabilities with high precision and recall. No false negatives were found in our evaluation, while 26 false positives were found when detecting fake EOS transfer vulnerability.

False Positives. We have conducted a manual investigation for all the 26 false positives, which were finally attributed to the history versions of contract “eosbetdice11”. Specifically, besides the account eosio.token, these contracts acknowledge the legality of an extra account named eosbettokens 666Probably related to tokens they issued to support their own business., which breaks our rules introduced in III-C.

In EOSIO platform, any account can deploy a token contract, however, it is not trivial for us to collect all possible legal accounts in an anonymous audit. To alleviate this issue, our system could be easily extended to support a whitelist mechanism which allows developers to customize extra legal accounts by themselves.

Iv-C Performance

We further evaluate the performance of EVulHunter, e.g., the time cost to detect fake transfer vulnerabilities in a given smart contracts. For the 242 smart contracts in our benchmark, we have recorded the detection time of each contract, and then analyzed the correlation between the size of smart contract and the detection time.

As shown in Figure 4, it is obvious that time consumption of vulnerability detection increased linearly with the increasing of the size of smart contract, although the increasing rate is very small. In general, the detection time rages from 1 second to 3 seconds. This result suggests that EVulHunter is efficient to flag the vulnerabilities in EOS smart contracts, which could be easily scale to thousands of smart contracts.

Fig. 4: The Performance Evaluation of EVulHunter.

V Related Work

The security vulnerabilities of smart contracts have attracted great attention of our research community. However, almost all of the previous studies focus on analyzing the vulnerabilities in the Ethereum smart contracts [9, 7, 10, 11, 8, 12], as a large number of smart contracts in the Ethereum ecosystem are open-sourced, and a number of analyzing tools could be leveraged. For example, Liu et al. [9] presented an analyzer aimed at reentrancy, the type of vulnerability which cause ‘TheDAO’ hard fork on Ethereum. Atzei et al. [7] covered more security vulnerabilities and showed a series of attack which allow attacker to steal money from smart contract. Luu et al. [10] built a sysbolic execution tool to find potential security bugs. Tikhomirov et al. [11] provided a static analysis tool to detect problematic language constructs. Our work is the first attempt to detect fake transfer vulnerabilities for EOSIO’s smart contracts. We believe our efforts could shed some light on the detection of vulnerabilities in the EOSIO’s smart contracts.

Vi Conclusion

In this work, we present the first systematic attempt to automatically detect fake-transfer vulnerabilities from EOSIO WASM code. Specifically, it first traverses the WASM code and constructs the corresponding Control Flow Graphs (CFGs), and then detects the existence of vulnerabilities based on predefined patterns. The evaluation results demonstrate the system performance, including speed and accuracy.

There are a number of future lines of work we will explore. For example, our detection simply relies on constant patterns, which may not be suitable to model the characteristics of other types of vulnerabilities. As such, some advanced program analysis techniques (e.g., symbolic execution) could be used to achieve more accurate results. To this end, we may have to revise the design of our system to support advanced analyses. Despite the limitations, we still believe our efforts and observations could positively contribute to the community.


  • [1] Eos developer documentation, https://www.eosdocs.io/dappdevelopment/tokencontract/
  • [2] Eosio, https://eos.io/
  • [3] Ethereum, https://www.ethereum.org/
  • [4] Official developer portal of eosio, https://developers.eos.io/eosio-cpp/docs/abi
  • [5] Webassembly, https://en.wikipedia.org/wiki/WebAssembly
  • [6] Wiki of eosio, https://en.wikipedia.org/wiki/WebAssembly
  • [7] Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. A survey of attacks on ethereum smart contracts (sok). In International Conference on Principles of Security and Trust, pages 164–186. Springer, 2017.
  • [8] Bo Jiang, Ye Liu, and WK Chan. Contractfuzzer: Fuzzing smart contracts for vulnerability detection. In Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, pages 259–269. ACM, 2018.
  • [9] Chao Liu, Han Liu, Zhao Cao, Zhong Chen, Bangdao Chen, and Bill Roscoe. Reguard: finding reentrancy bugs in smart contracts. In Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings, pages 65–68. ACM, 2018.
  • [10] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. Making smart contracts smarter. In Proceedings of CCS 2016, pages 254–269. ACM, 2016.
  • [11] Sergei Tikhomirov, Ekaterina Voskresenskaya, Ivan Ivanitskiy, Ramil Takhaviev, Evgeny Marchenko, and Yaroslav Alexandrov. Smartcheck: Static analysis of ethereum smart contracts. In WETSEB 2018, pages 9–16. IEEE, 2018.
  • [12] Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen, Arthur Gervais, Florian Buenzli, and Martin Vechev. Securify: Practical security analysis of smart contracts. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 67–82. ACM, 2018.