DeepAI
Log In Sign Up

SmartScan: An approach to detect Denial of Service Vulnerability in Ethereum Smart Contracts

Blockchain technology (BT) Ethereum Smart Contracts allows programmable transactions that involve the transfer of monetary assets among peers on a BT network independent of a central authorizing agency. Ethereum Smart Contracts are programs that are deployed as decentralized applications, having the building blocks of the blockchain consensus protocol. This technology enables consumers to make agreements in a transparent and conflict-free environment. However, the security vulnerabilities within these smart contracts are a potential threat to the applications and their consumers and have shown in the past to cause huge financial losses. In this paper, we propose a framework that combines static and dynamic analysis to detect Denial of Service (DoS) vulnerability due to an unexpected revert in Ethereum Smart Contracts. Our framework, SmartScan, statically scans smart contracts under test (SCUTs) to identify patterns that are potentially vulnerable in these SCUTs and then uses dynamic analysis to precisely confirm their exploitability of the DoS-Unexpected Revert vulnerability, thus achieving increased performance and more precise results. We evaluated SmartScan on a set of 500 smart contracts collected from the Etherscan. Our approach shows an improvement in precision and recall when compared to available state-of-the-art techniques.

READ FULL TEXT VIEW PDF
03/01/2022

VOLCANO: Detecting Vulnerabilities of Ethereum Smart Contracts Using Code Clone Analysis

Ethereum Smart Contracts based on Blockchain Technology (BT) enables mon...
05/06/2021

Reentrancy Vulnerability Identification in Ethereum Smart Contracts

Ethereum Smart contracts use blockchain to transfer values among peers o...
03/16/2021

EtherSolve: Computing an Accurate Control-Flow Graph from Ethereum Bytecode

Motivated by the immutable nature of Ethereum smart contracts and of the...
04/17/2021

Ponzi Scheme Detection in EthereumTransaction Network

With the rapid growth of blockchain, an increasing number of users have ...
03/09/2020

Ransomware as a Service using Smart Contracts and IPFS

Decentralized systems, such as distributed ledgers and the InterPlanetar...
05/21/2021

SCSGuard: Deep Scam Detection for Ethereum Smart Contracts

Smart contract is the building block of blockchain systems that enables ...
08/29/2019

VeriSmart: A Highly Precise Safety Verifier for Ethereum Smart Contracts

We present VeriSmart, a highly precise verifier for ensuring arithmetic ...

I Introduction

Attributing to the wide range applicability of Blockchain technology (BT), it has been finding popularity in many domains. Bitcoin was the first version of cryptocurrency applied using blockchain technology and has since been used in many other applications such as e-commerce, trade and commerce, production and manufacturing, banking, and gaming. BT uses a peer-to-peer framework which is a more decentralized approach to storing transactions and data registers. As there is no single point of failure or a third-party centralized control of transactions, BT has been standing out from other emerging technologies. It uses a chain of blocks in which each block is locked using cryptography using the hash of the previous block it is linked to, which creates an immutable database of all transactions stored as a digital ledger, and it cannot be changed without affecting all the blocks linked together in the chain[surveyattacks].

Proof of Work (POW) and Proof of Stake (POS) are the systems that are required to be performed by each connected miner in a BT network wherein a complex computational math problem is solved to become eligible to add a block to the BT network. Data security and integrity are vital and to ensure protection from unauthorized access, the aspect of using a cryptography-based locked chain of blocks is introduced. Our research is focused on Ethereum Blockchain and the security vulnerabilities in it. Recent research have shown that many applications have been exposed to attacks because of vulnerabilities found in Solidity-based Ethereum Smart Contracts[vulnerabilities]. One such vulnerability in Solidity Smart Contract is the DoS-Unexpected Revert vulnerability. DoS - Denial of Service, as the name suggests, is a vulnerability where a Smart Contract is rendered inoperable because of an improper handling of an incomplete transaction resulting from a failure or a deliberate revert of the transaction. This paper presents a framework to address the DoS due to Unexpected Revert attack and provides a framework to identify this vulnerability. This paper has the following contributions:

  1. An automated framework that combines static and dynamic analysis to better capture the various patterns of the DoS due to an Unexpected Revert attack efficiently and accurately in over 500 SCUTs. [See Table I for various DOS-Unexpected Revert Vulnerability patterns identified]

  2. A Web application to scan Solidity-based Ethereum Smart Contracts for DOS-Unexpected Revert vulnerability.

Ii Background

Ii-a Ethereum

Ethereum[Ethereum] is a BT platform that implements algorithms expressed in a general purpose programming language allowing developers to build a variety of applications, ranging from simple wallet applications to complex financial systems for the banking industry. These programs are known as Smart Contracts which are written in a Turing-complete byte-code language, called EVM byte-code[Ethereum]. The transactions sent to the Ethereum network by the users can create new contracts, invoke functions of a contract, and/or transfer ether to contracts.

Ii-B Smart Contract

Ethereum uses Smart Contracts[Ethereum], which are computer programs that directly controls the flow or transfer of digital assets. Each function invocation in a Smart Contract is executed by all miners in the Ethereum network and they receive execution fees paid by the users for it. Execution fees also protect against denial-of-service attacks, where an attacker tries to slow down the network by requesting time-consuming computations. This execution fee is defined as a product of gas and gas-price. Implementing a Smart Contract use case can pose a few security challenges because of the primary characteristic of BT of transparency. Moreover, the immutability of BT makes patching the already deployed Ethereum Smart Contracts to overcome the discovered vulnerabilities impossible.

Ii-C Solidity

Ethereum Smart Contracts [Ethereum] are typically written in a high-level turing-complete programming language such as Solidity[Solidity], and then compiled to the Ethereum Virtual Machine (EVM) byte-code[Ethereum], a low-level stack-based language. For instance, Listing 1 shows a smart contract written in the Solidity programming language[Solidity].

In Listing 1, the first line of the program declares the Solidity version. The program will be compatible with the corresponding EVM or any other higher version less than 0.6.0. It contains a constructor to create an instance of the contract, and functions.

The msg.sender is a built-in global variable representative of the address that is calling the function. The msg.value is another built-in variable that tells us how much ether has been sent. The payable keyword is unique to Solidity language as it allows a function to send and receive ether.

A function with no name followed by payable keyword, function () payable, is a fallback function in Solidity. This function gets triggered whenever a function call has an identifier that does not match any of the existing functions in a smart contract or if there was no data supplied to the function call at all.

To transfer ether between the contracts, Solidity uses send(), transfer() and call(). send() transfers the ether and executes the fallback function of the contract that receives ether. The gas limit per execution is 2300 and an unsuccessful execution of send() function does not throw an exception, but the gas required for the execution is spent. Similarly, transfer() is also used to transfer ether between the contract, but the gas limit can be redefined using the .gas() modifier, and an unsuccessful transfer() throws an exception. The gas limit in both these functions prevents the security risk involved in executing expensive state changing code in the fallback function of the contract receiving the ether. The one pitfall is when a contract sets a custom amount of gas using the .gas() modifier. The call() function is comparatively more vulnerable as there is no gas limit associated with this function.

Iii DoS caused by an Unexpected Revert Vulnerability

When the flow of control is transferred to an external contract, the execution of the caller contract can fail accidentally or deliberately, which can cause a DoS state in the caller contract. The caller contract can be in a DoS state when a transaction is reverted due to a failure in the receiving smart contract, or the receiving smart contract deliberately reverts the transaction to disrupt the execution of the caller contract.

Iii-a DoS - Unexpected Revert Scenarios

Scenario 1: Consider an Ethereum Smart Contract HYIP, which is a Ponzi scheme. This contract sends payments to lenders from funds collected via new lenders each day. The function sendPayment() in Listing[1] contains the DoS due to an Unexpected Revert vulnerability. The attack proceeds as follows:

  1. The AttackerContract lends funds to the HYIP contract and throws an exception in its fallback function.

  2. When the function sendPayment() is called to send daily payments to the contract lenders, the fallback function of all its lenders are invoked and and the fallback function of our AttackerContract throws an exception, causing a deliberate revert of the transaction and subsequently transitioning the vulnerable contract HYIP into a DoS state.

1pragma solidity ^0.5.0;
2
3contract HYIP {
4    Lenders[] private lender;
5    function sendPayment() {
6        for(uint i=lender.length; i<=0; i--) {
7        uint payment=(lender[i].amount*/1000;
8        if(!lender[i].addr.send(payment)) throw;
9            }
10    }
11 }
12 contract AttackerContract {
13    bool private attack = true;
14    function() payable {
15        if (attack) throw; // callee fails the caller execution deliberately
16    }
17    function stopAttack() {
18        if(msg.sender == owner) attack = false;
19    }
20 }
Listing 1: Contract HYIP - Exploited for DoS-Unexpected Revert Vulnerability [Etherscsan]

Scenario 2: Another scenario is when a contract uses iteration statements to push out payments to users. The vulnerability arises when there is even one failed send. For even one failed send the whole payout system gets reverted, leaving the loop of payout system inoperable. No one gets the payment because one contract is causing a revert either accidentally or deliberately.(See Listing[2])

1    address[] private paymentAddresses;
2    mapping (address => uint) public payments;
3    function payAll() public {
4        for(uint x; x < paymentAddresses.length; x++) {
5            require(paymentAddresses[x].send(payments[paymentAddresses[x]]));
6        }
Listing 2: Iteration statements DoS Vulnerability Pattern

This scenario is more severe than the previous one as now a single payment failure in a send will hold up all the other payments.

Iii-B Preventive Technique

This vulnerability exists because of inadequate exception handling around conditional and iteration statements. Placing any external calls initiated by a callee contract into a separate transaction can be helpful in reducing the damage caused by this vulnerability.

Making the recipient to pull funds out rather than sender using push to send out funds may help in avoiding this vulnerability. Moreover, isolating following code constructs should be considered to avoid this vulnerability:

  1. an if-statement with an external function call in the condition and a throw or a revert in the body;

  2. a for-statement with an external function call in the condition.

Iv Motivation

Although classified as

not severe by few researchers, a recent survey paper by Samreen and Alalfi [Survey2020] highlights the importance of detecting a DOS vulnerability in an Ethereum Smart Contract. DOS vulnerability can render a smart contract inoperable thereby freezing any ether stored in the smart contract and also costs the Ethereum blockchain network in terms of memory and space which cannot be retrieved back in any way. One of the real world instances of exploitation of this vulnerability is the GovernMental smart contract. This was a Ponzi scheme which collected a fairly large amount of ether is an example of DOS due to unexpected revert vulnerability in Ethereum Smart Contracts. It had collected almost 1100 ether at one point and was then susceptible to the DOS vulnerability. This contract required sending a minimum amount to the previous creditors and then a deletion of these creditors in the scheme in order to withdraw the jackpot ether amount. However, as a part of clearing out the previously engaged creditors in this scheme, the contract iterates over the storage locations and deletes them one by one after sending out the minimum credit. And, in doing so, the fallback function of all the creditors gets executed when there is a transfer of the minimum credit to their account. One of the creditor’s fallback function reverted the transfer, thereby halting the entire scheme. Therefore, Governmental has been stuck since then and its 1100 ETH are in a limbo. The working of a Denial of Service vulnerability is tightly coupled with the error handling mechanism in Solidity-based Ethereum Smart Contracts. To identify this vulnerability, the patterns for error handling in Solidity needs to be analysed. The common pattern for enforcing permissions in Solidity-based Ethereum Smart Contracts (till V 0.5.0) was to check the address of the account that is trying to access a smart contract in an if statement and to throw if false.

1contract HasAnOwner {
2
3    address owner;
4    function restrictedFunction(){
5        if (msg.sender != owner) { throw; }
6        // do something only the owner should be allowed to do
7    }
8}
Listing 3: If…Throw pattern of DoS Vulnerability

In the above listing 3, if the restrictedFunction() function is called by any other address other than owner of the contract, then the function will throw and returns an invalid opcode error, undoing all state changes, and using up all remaining gas.

The newer versions of Solidity use built-in functions like assert(), require(), and revert() to provide the same functionality, with a much cleaner syntax.

1if(msg.sender != owner) { throw; }

currently behaves exactly the same as all of the following:

1if(msg.sender != owner) { revert(); }
2assert(msg.sender == owner);
3require(msg.sender == owner);

See Table I for a list of patterns identified to detect a DoS-Unexpected Revert vulnerability.

S.no. Pattern Name Pattern Format
1. Iteration Pattern
for(uint x; x < rec.length; x++) {
        require(rec[x].send(payments[rec[x]]));}
2. If/Throw Pattern
if(msg.sender != owner) { throw; }
3. If/Revert Pattern
if(msg.sender != owner) { revert(); }
4. Assert Pattern
assert(msg.sender == owner);
4. Require Pattern
require(msg.sender == owner);
TABLE I: DoS due to Unexpected Revert Vulnerability Patterns Identified

Fig. 1: Txl Paradigm[TXL]

V Proposed Framework

There are two parts to check for the DOS due to unexpected revert vulnerability. First, a call to an external function is executed in a module of the smart contract that could possibly mishandle an exception if thrown. Second, there is an exception thrown at the external call causing the denial of service state of the smart contract. Therefore, the pattern in our proposed analysis solution, SmartScan, should combine both static and dynamic analysis methodologies to check the possibility of an exception being thrown at an external call and to confirm the functional unavailability of the smart contract after the external call to an untrustworthy address dynamically, i.e. mishandled exception causing DOS due to an unexpected revert by the untrustworthy address.

Fig. 2: Proposed Framework

This framework utilizes both static and dynamic analysis techniques to cover almost all the above-described attack patterns. The first stage of SmartScan adopts static analysis technique of pattern recognition and automated instrumentation of a Smart Contract Under Test (SCUT) to efficiently cover the possible attack scenarios in the SCUT.

The second stage uses the extracted information of vulnerable functions in the SCUT from stage one to automatically generate an attacker-contract which is then used to interact with the SCUT after they are deployed onto our private Ethereum test network. This interaction is done to demonstrate the exploitability of the DoS-Unexpected Revert vulnerability in a SCUT dynamically.

V-a Stage 1: Contract Analysis

To accurately model the possible scenarios that can result in this vulnerability, our proposed framework, SmartScan [as shown in Figure 2], uses Txl[TXL]. TXL is a programming language used for structural analysis and source transformation. The TXL paradigm consists of a grammar and transformation rules that are used to parse a given input text into Abstract Syntax Tree (AST), and this intermediate AST is transformed into a new AST of the target domain, and finally this output is un-parsed to a new output text.

The structure of a transformation rule in TXL specifies a target program type to be transformed, a pattern which is an instance of the type that we are interested in replacing and a replacement structure. In SmartScan, we used TXL to achieve the following tasks:

  1. To parse the SCUT and to apply pattern recognition rules in order to identify potentially vulnerable functions in the SCUT,

  2. To extract the names of these potentially vulnerable functions from the SCUT to generate an attacker-contract.

1 rule main
2 replace [program]
3 EntireInput [program]
4    by
5     EntireInput [Function1]
6                 [Function2]
7 end rule
Listing 4: Txl program structure

The potentially vulnerable functions were determined if they contained an external call using any of these three Solidity’s built-in functions: transfer(), call(), send() in an iterative or a conditional statement or a statement that could mishandle an exception if thrown. These exception mishandling prone statements include: assert(), revert(). These function signatures were extracted using TXL and outputted in a .txt file. This output file was used to modify the attacker-contract to exploit DOS vulnerability in the SCUT by deliberately reverting the transaction in the fallback function of the attacker-contract.

An attacker-contract, as shown in Listing5, is automatically created to interact with the potentially vulnerable functions of the SCUT to recreate the DOS due to unexpected revert attack scenario. For illustration, BetDeEx smart contract is used as an example from the collected data-set for this research. This framework successfully detected DOS vulnerability within it in our analysis.

As shown in Listing5, the AttackerContract deliberately reverts the transaction using revert() in its fallback function. At first, the attacker-contract creates an instance of the BetDeEx contract and thus calls the constructor of the BetDeEx contract. It then calls the collectPlatformFee() function of BetDeEx smart contract to initiate the attack. Within the collectPlatformFee() function, the BetDeEx smart contract transfers ether using the in-built Solidity function transfer() in a require() statement. Since the transfer function call has no parameters provided, it will invoke the fallback function of the attacker-contract. If the transaction fails, then an exception is thrown by the require() statement. Due to the mishandling of this exception in the require() statement, the BetDeEx is rendered unavailable for future requests.

1import "BetDeEx.sol";
2contract Attacker_BetDeEx{
3    address payable private _owner;
4    address payable private _vulnerableAddr;
5    BetDeEx public fd = BetDeEx(_vulnerableAddr);
6    constructor() public {
7         _owner = msg.sender;
8         fd. collectPlatformFee();
9    }
10    function() external{
11        revert();
12    }}
Listing 5: Attacker-Contract for BetDeEx SCUT

Within the fallback function, the attacker-contract can deliberately have a revert(); statement to cause a revert of any transaction happening between this attacker-contract and any other contract. As a result, the BetDeEx smart contract will be in a state of unavailability due to mishandling of this unexpected revert caused in an external call. With the help of the attacker-contract, we can verify the exploitability of the potential DOS due to unexpected revert

vulnerability detected by static analysis using TXL pattern matching.

V-B Stage 2: Contracts Deployment

The contracts deployment stage requires an Ethereum Private Test Network with test environment specifications. To deploy the SCUT and the attacker-contracts for testing, we used Geth[Geth], a Golang implementation of Ethereum, to create a private blockchain. This enabled us to create a new and private blockchain which we will be using to deploy and test any smart contract. This private blockchain does not connect to the Ethereum Main-net and therefore does not require real ether to execute transaction between smart contracts.

V-B1 Geth

To use Geth[Geth], we created a new account that represents a key pair. We simulated having two different accounts that store our private blockchain by creating two nodes in the blockchain. These nodes serve the purpose of acting like two different computers hosting and interacting with the same private blockchain using two terminal windows. We used two data directories, so each node has a separate place to store their local copy of our blockchain.

V-C Stage 3: Initiating Attack Vector

To interact with the blockchain, we launched the geth console command to initiate the ports for ContractsNode and AttackerNode.

After simulating the contracts node and attacker node on our private Ethereum network, the SCUTs are deployed on these nodes in the following steps:

  1. The SCUT were compiled and deployed using a Javascript in which the Solc command was invoked to generate the ABI and bytecode of the SCUTs.(See Listings 6 and 7)

  2. HDWalletProvider is a hosted Ethereum node cluster that was used to automatically deploy the contracts onto our Private Ethereum Test Network.

  3. After deploying the contract onto a node, the transaction is submitted to all the peers of the blockchain. The miner.start() command starts the mining process and miner.stop() ends this process. After the mining process is completed, the contract gets appended to the blockchain.

1    const compileContracts = () => {
2    try{
3  const compiledContracts = JSON.parse(solc.compile(JSON.stringify(input)).contracts);
4  if (!compiledContracts) {
5        console.error(’>> ERRORS <<<\n’, ’NO OUTPUT’);
6    } else if (compiledContracts.errors) { // something went wrong.
7        console.error(’>> ERRORS <<\n’);
8        compiledContracts.errors.map(error => console.log(error.formattedMessage));
9    }
10 for (let contract in compiledContracts) {
11  for(let contractName in compiledContracts[contract]) {
12   fs.outputJsonSync(
13    path.resolve(builPath, ${contractName}.json‘),
14    compiledContracts[contract][contractName],
15    {spaces: 2})
16    }}}
17 catch(e){
18  console.log(e);}}
Listing 6: Javascript to Compile all the SCUTs automatically
1    (async () => {
2 const accounts = await web3.eth.getAccounts();
3
4 console.log(‘Attempting to deploy from account: ${accounts[0]}‘);
5
6 const deployedContract = await new web3.eth.Contract(compiledContract.abi)
7  .deploy({
8   data: ’0x’ + compiledContract.evm.bytecode.object,
9   arguments: [3, 5]
10  })
11  .send({
12   from: accounts[0],
13   gas: ’2000000’
14  });
15
16 console.log(
17  Contract deployed at address: ${deployedContract.options.address}‘
18 );
19
20 provider.engine.stop();
21})();
Listing 7: Javascript to Deploy all the SCUTs automatically

After deploying the contracts, transactions were initiated between SCUTs and the attacker-contract using the vulnerable function name extracted using TXL in the first step of our analysis.

Fig. 3: Report of Analysis Generated

Vi Usage of Our Tool

We deployed SmartScan as a web service. To analyze a smart contract, our tool adopts a one-click design. (See Figure[3]). Users only need to type the contract code in the browser, and our tool will then statically analyse and give the results as Passed if there are no potentially vulnerable functions detected in the SCUT.

However, if there are potentially vulnerable functions in the SCUT, then the tool deploys the SCUT onto our private Ethereum Test Network and begins the second stage of our analysis i.e. it generates an attack vector to confirm the exploitability of the DOS due to unexpected revert vulnerability in the SCUT.

Taking the simple SCUT in Figure [3] as an example, we briefly describe the usage of our tool. By clicking the Scan button, our tool initiates the analysis. When the analysis is done, a report is generated as shown in Figure[3]. In this case, the potentially vulnerable function signatures are highlighted.

Access our tool here, SmartScan 111https://smartscan.cs.ryerson.ca:4638/.

Vii Related Work

Many tools have been developed that aim at improving the security and correctness of Ethereum smart contracts. The online Solidity compiler Remix also provide warnings and suggestions regarding some of the known vulnerabilities in Smart Contracts. However, there is very few tools that has been developed to check for DOS due to unexpected revert vulnerability.

Grech et. al developed a tool, MadMax (now renamed as ContractLibrary) [madmax] as a static program analysis tool that aims at automatically detecting gas-focused vulnerabilities. This tool combines a control-flow-analysis-based decompiler, Vandal[Vandal] and declarative program-structure queries. Grech et. al proposes that this combined analysis achieves high precision and scalability. ContractLibrary [madmax] outlines the DOS-due to unexpected revert as Wallet Griefing - a condition in which a contract may throw an out-of-gas exception when combined with other complicating factors.

SMARTCHECK is a pattern-based analysis tool that uses XPath to detect if any vulnerabilities pattern exists in a Smart Contract. To do so, it transforms the Smart Contract into XML representation. SmartCheck has its limitations, as detection of this vulnerability requires a combination of static and dynamic analysis techniques to confirm the unavailable state of a vulnerable Smart Contract.

SMARTSHIELD by Y. Zhang et al. [smartshield] utilizes EVM bytecode analysis and provides an automatic correction mechanism that would avoid vulnerable patterns in Ethereum smart contracts. It does this rectification by extracting EVM bytecode level semantic data to transform the vulnerable smart contracts into secure ones.

ETHPLOIT by Q. Zhang et al. [Ethploit] is another tool that addresses this vulnerability. ETHPLOIT automatically detect vulnerabilities that have been exploited in Ethereum smart contracts. This tool adopts light-weight techniques to answer the problems of previous such tools. These problems consisted of unsolvable constraints and Blockchain effects. It is claimed by Q. Zhang et al. [Ethploit] that this tool achieves precise and efficient smart contract analysis and successfully detects more exploits than previous exploit generation tools. A recent study published in Feb. 2020 by Durieux et al. aims at reviewing the findings of automated tools available for detecting known vulnerabilities in Ethereum Smart Contracts. The empirical study by Durieux et al. lists two other automated tools Osiris[osiris] and Slither[slither] that detect DOS vulnerabilities.

However, we found that Osiris [osiris] focuses on identifying integer overflow vulnerabilities in Ethereum smart contracts and checks for semantics of a smart contract that may cause an integer overflow vulnerability by applying symbolic execution and taint analysis.

Slither[slither] provides a way to identify if the send built-in function of Solidity was used without checking its return value. This detection is a much broader way of formulating pattern for the occurrence of DOS vulnerability and Slither fails to narrow down the pattern of function calls that may cause this vulnerability.

Viii Evaluation

The data-set used for the evaluation consisted of 500 real world Smart Contracts of Solidity version greater than 0.5. This was extracted from Etherscan by developing a python-based web scraper. Etherscan[Etherscsan] is a free-to-use platform for BT analytics based on Ethereum. It is essentially a Block Explorer that allows users to easily lookup, confirm and validate transactions that have taken place on the Ethereum Blockchain. Ethereum Smart Contracts developers can get a substantial benefit from APIs available that can be utilized to either build decentralized applications or serve as a data-set for Ethereum Blockchain analysis.

Although we mentioned that four automated testing tools are available to detect the DOS- due to unexpected revert vulnerability (SMARTSHIELD [smartshield], ETHPLOIT [Ethploit], SmartCheck [SmartCheck] and ContractLibrary [madmax]). We could evaluate our framework - SmartScan against the results produced by only two of the available tools - SmartCheck and ContractLibrary, as these were the only publicly available tools to identify DOS vulnerabilities in Ethereum Smart Contracts.

The analysis result shows that 73 contracts from the 500 contracts were deployed onto our private Ethereum Test Network to confirm the existence of DOS due to unexpected revert vulnerability as they exhibited the identified vulnerable code patterns. In the second stage of our analysis, out of the deployed 73 contacts, only 28 were confirmed to be exploitable by a DOS attack. Further breakdown of these 28 confirmed vulnerabilities indicated that 18 of these confirmed vulnerable SCUTs were exploitable by initiating an attack vector from an external contract. The remaining 10 vulnerable SCUTs were protected by an access modifier and was successfully exploited by gaining control of the owner contract or its dependent contracts.

Our framework, SmartScan, resulted in detection of DoS vulnerability in 10 more smart contracts than SmartCheck[SmartCheck] and ContractLibrary[madmax] [See Table II]. These two tools used in the evaluation failed to detect these externally non-exploitable vulnerabilities even though they contained the pattern that resulted in a DoS state in a smart contract. This was due to the fact that the functions that exhibited the pattern for DoS-Unexpected Revert vulnerability was protected by an access modifier that restricted its external invocation. We confirmed the existence of the DOS vulnerability in these smart contracts by invoking the vulnerable functions from within the SCUT itself.

1contract Unipool {
2    function sendValue(address payable recipient, uint256 amount) internal {
3        require(address(this).balance >= amount, "Address: insufficient balance");
4        if(!recipient.call.value(amount)(""))
5        throw;
6    }
7}
Listing 8: Contract Unipool - for DoS-Unexpected Revert Vulnerability[Etherscsan]

For example, one of the smart contracts in our dataset - Unipool[Etherscsan],listing 8 had an access modifier internal for a function sendValue which made it inaccessible to be called from an external contract. But the pattern that exposes the smart contract to a possible DOS-due to unexpected revert from an external contract did exist in the function sendValue of the SCUT Unipool. Therefore, the confirmation of the DOS vulnerability in this case could be determined by trying to gain control of the owner contract or the dependent contracts of the SCUT. It can serve as an indication to the smart contract programmers that such coding practice in developing smart contracts may expose their smart contracts to a the DOS-due to unexpected revert vulnerability.

Our framework, SmartScan, produced no false positives and therefore, has better precision than SmartCheck [SmartCheck]. ContractLibrary [madmax],however, had similar precision value when compared to our framework, SmartScan, but lower recall value because of missed vulnerability instances detection (false negatives). Also, the process of checking a smart contract for vulnerabilities using ContractLibrary is complicated as it requires deploying the smart contract under test (SCUT) on the Ropsten test network of the Ethereum Blockchain and then wait for ContractLibrary framework to import and test the SCUT. The process of detecting a smart contract for vulnerabilities is quicker and simpler in our framework, SmartScan.

Analysis Results SmartScan SmartCheck Contract Library
Vulnerabilities Confirmed 28 20 18
Exploitable-internal attack 10/28 0/20 0/18
False-Positives (FP) 0/28 2/20 0/18
Vulnerability pattern instances missed (FN) 0 10 10
TABLE II: Results of DOS due to Unexpected Revert vulnerability analysis. FN: False Negative
S.no. Smart Contract SmartScan SmartCheck ContractLibrary
Pattern Detected Exploitable by external Attacker Contract
1. AZBICore If/Throw
2. AZR Require
3. BetDeEx Iteration
4. BIOXE If/Throw
5. Booth Renting Assert
6. Chainlink If/Throw
7. CREDIT If/Throw
8. CryBet Iteration
9. ETGF Require
10. Flash Loan Ave If/Throw
11. Lition Pool Iteration
12. Load Coin Iteration
13. RICH Assert
14. Syndicate Iteration
15. Tip Iteration
16. USPi Require
17. HYIP If/Throw
18. CallToTheUnknown Require
Inaccessible from external contract because pattern is protected with an access modifier
19. BKRW Assert Access modifier-only owner (FN) (FN)
20. GramChain If/Revert Access modifier-only owner (FN) (FN)
21. Price Feed Assert Access modifier-internal (FN) (FN)
22. Off-Chain Asset Evaluator If/Throw Access modifier-internal (FN) (FN)
23. Off-Chain Currency Evaluator If/Throw Access modifier-internal (FN) (FN)
24. Redeem Code Require Access modifier-only owner (FN) (FN)
25. SONERGY Assert Access modifier-only owner (FN) (FN)
26. Unipool Require Access modifier-internal (FN) (FN)
27. Xank Require Access modifier-internal (FN) (FN)
28. ZdzMedia Assert Access modifier-only owner (FN) (FN)
29. Countdown Griefing (FP)
30. Simple Griefing (FP)
TABLE III: Detailed Evaluation of DOS due to Unexpected Revert vulnerability analysis. FP: False Positive; FN: False Negative; : Vulnerability found; : Vulnerability not found; : In-exploitable due to inaccessibility

Ix Conclusion

In this paper, a combined static and dynamic analysis framework is proposed to detect DoS-Unexpected Revert vulnerabilities in data-set of 500 real world Ethereum Smart Contracts collected from Etherscan[Etherscsan]. These Smart Contracts were collected by developing a python-based web scraper for Etherscan portal. This framework uses TXL[TXL] for analyzing these smart contracts to extract the function signature of potentially vulnerable functions in a contract. Then, the DoS vulnerability confirmation is done at the run-time while interacting with the vulnerable contract using an attacker-contract in an attempt to recreate the DoS scenario.

X Future Work

The future work in this research would be to make our tool scalable to include Solidity smart contracts of newer versions. Currently, this framework targets Solidity smart contracts of versions v5.0. Also, to include detection of other vulnerabilities listed by some of the known security vulnerabilities research[Survey2020] by our framework, SmartScan.

Acknowledgments

This work is supported in part by the Natural Sciences and Engineering Research Council of Canada (NSERC).

Xi Data Availability

The data collected to conduct this research is publicly available on Etherscan web portal and was gathered using a web scraper written in Python. The tool produced in this research to analyse smart contracts for the presence of DOS due to unexpected revert vulnerability is also publicly available at SmartScan 222https://smartscan.cs.ryerson.ca:4638/

.

References