ContractGuard: Defend Ethereum Smart Contracts with Embedded Intrusion Detection

Abstract

Ethereum smart contracts are programs that can be collectively executed by a network of mutually untrusted nodes. Smart contracts handle and transfer assets of values, offering strong incentives for malicious attacks. Intrusion attacks are a popular type of malicious attacks. In this paper, we propose ContractGuard, the first intrusion detection system (IDS) to defend Ethereum smart contracts against such attacks. Like IDSs for conventional programs, ContractGuard detects intrusion attempts as abnormal control flow. However, existing IDS techniques/tools are inapplicable to Ethereum smart contracts due to Ethereum's decentralized nature and its highly restrictive execution environment. To address these issues, we design ContractGuard by embedding it in the contracts to profile context-tagged acyclic paths, and optimizing it under the Ethereum gas-oriented performance model. The main goal is to minimize the overheads, to which the users will be extremely sensitive since the cost needs to be paid upfront in digital concurrency. Empirical investigation using real-life contracts deployed in the Ethereum mainnet shows that on average, ContractGuard only adds to 36.14% of the deployment overhead and 28.27% of the runtime overhead. Furthermore, we conducted controlled experiments and show that ContractGuard successfully guard against attacks on all realworld vulnerabilities and 83% of the seeded vulnerabilities.

SODA: A Generic Online Detection Framework for Smart Contracts

“…The instrumented smart contracts will reject all transactions that violate the invariants [32]. ContractGuard inserts runtime checks into the bytecode of smart contracts, and the instrumented smart contracts will reject all transactions that hijack the control flow of smart contracts [31]. Ayoade et al's work inserts protection code into the bytecode of smart contracts to prevent integer overflow/underflow attacks [33].…”

“…Ayoade et al's work inserts protection code into the bytecode of smart contracts to prevent integer overflow/underflow attacks [33]. However, the protection abilities of these approaches [29], [31]- [33] are restricted by the blockchain architecture for two reasons. First, complicated runtime checks may not be inserted into smart contracts, because the bytecode of a smart contract must not exceed 24KB [38].…”

“…IAL obtains the information of control flow transfer whenever the control flow of the executed smart contract transfers, including the executed EVM instruction, the current program counter and the program counter of the next executed instruction. With such information, controlflow hijacking can be detected [31]. To construct the information of control flow transfer, IAL abstracts the information of 2 EVM instructions, JUMP and JUMPI, because the control flow can be transferred after executing these instructions [39].…”

“…Online approaches attempt to detect attacks targeting smart contracts or protect smart contracts from attacks after deployment [29]- [37], which can be classified into two categories. The first category inserts protection code into the source/bytecode of smart contracts [29], [31]- [33]. However, their capabilities [29], [31]- [33] are restricted by the size limit of EVM bytecode [38] and the gas mechanism [39].…”

“…The first category inserts protection code into the source/bytecode of smart contracts [29], [31]- [33]. However, their capabilities [29], [31]- [33] are restricted by the size limit of EVM bytecode [38] and the gas mechanism [39]. The second category inserts protection code into the runtime of smart contracts (e.g., EVM) [30], [34]- [37].…”