On the decentralized finance (DeFi): Exploring the vulnerabilities of the Blockchain Based Smart Contracts
Blockchain is a new type of distributed system architecture that uses peer-to-peer network communication, chained block transaction storage, distributed algorithm consensus, and cryptographic algorithm to prevent tampering. In essence, the blockchain can be regarded as a distributed database jointly maintained by all network nodes. Compared with traditional distributed databases, blockchain is more suitable for application scenarios that have clear requirements for decentralized trust due to its full data backup, open and transparent network, non-tamper evident records, full information traceability, and weak trust model. In particular, typical blockchain application scenarios include digital payment, product traceability, copyright protection, supply chain finance, etc. In the blockchain system, an application called a smart contract plays an extremely important role in implementing decentralized application deployment and expanding the functionality of the blockchain system. Compared with traditional applications, smart contracts running on the blockchain system architecture have the characteristics of openness and transparency, guaranteed execution, non-tampering, and no dependence on trusted third parties, which can meet the deployment of various decentralized application scenarios demand, including decentralized finance (Defi) projects that have developed rapidly in recent years.
Decentralized Finance (DeFi), a peer-to-peer financial paradigm which leverages blockchain-based smart contracts to ensure its integrity and security, contains over $ 45B USD of capital as of January 15th, 2021. Decentralized Finance is a new area of development, where tokens are exchanged, lent, or borrowed. Often, this generates a “yield” or income stream that is moderated by a smart contract — rather than a single, centralized legal entity or person — and/or controlled by a multiparty, decentralized governance mechanism (e.g. a DAO). Decentralized Finance (DeFi) — is gradually emerging on top of existing blockchain platforms. Components of this new domain include those that pertain to lending, decentralized exchange of assets, and markets for derivatives. As an application featuring decentralized trust, smart contracts often need to manage huge amounts of digital assets, making them vulnerable to various attacks.
In this article we explain smart contract security issues from three perspectives: First, Smart contract security due to vulnerability at each layer of ethereum architecture. Second, we also explore number of attacks from the recent emergence of DeFi and smart contract. We also explore the existing available tools and other recommendations from known best practice on how to minimize such attacks.
Part 1: Smart contract vulnerabilities at different layers of the Ethereum architecture
1.0 Overview of Ethereum Architecture
Before we explore the smart contract vulnerabilities, we would like to provide an overview about Ethereum smart contract architecture.
A blockchain network deploys and executes the programming scripts to process a task autonomously. These programs are called smart contracts which are used to define the customized functions and rules invoked during the transactions. Smart contracts based blockchain technology is being embedded into a wide variety of industry applications, such as finance, supply chain management, health care energy and government services. There are only specific blockchain platforms support smart contracts: Ethereum was the first to support smart contracts; other blockchain platforms, such as EOS, Lisk, Bitcoin, and Hyperledger Fabric, are compatible to deploy and execute the smart contracts. A script type language called Solidity is used to develop smart contracts in Ethereum platform . In this part we cover the important relevant security vulnerabilities of smart contract implementation on the Ethereum platform. Smart contracts can hold and manage function credit(address to) payable {a large amount of virtual currencies which could be worth thousands of dollars. Therefore, the adversaries keep attempting to manipulate the execution of smart contracts in favor of their activities. In nature, smart contracts are running on the distributed and permission-less networks, which inherits many vulnerabilities. In a traditional system, the small piece of applications running in a centralized environment can be redeveloped or patched.
On the contrary, in a decentralized blockchain network, the deployed smart contracts cannot be modified or upgraded in a live network unless extreme measures are taken. The immutable nature of smart contracts makes strengths and weaknesses in the means of security aspects. Because of this immutability, hackers are unable to make changes or modify the contracts for their benefit. However, the smart contract applications cannot be modified (Immutable) even by the developers after the deployment. They can kill or terminate the contract and create new smart contract and deploy it again. Therefore, before the deployment, the smart contracts should be thoroughly tested with a wide range of test cases for security and safety reasons. We highlighted the basic building block of Ethereum smart contract architecture as shown in Figure 1 which comprises four-layer architecture of Ethereum.
Figure 1: Architecture of the Ethereum blockchain and its environment in which the Ethereum blockchain runs. The environment serves the four layers of the Ethereum architecture via a web user interface to interact with applications, databases for storing blockchain data, cryptographic mechanisms for supporting the consensus protocols, and Internet service for the network layer [20].
a) Application layer: Ethereum clients execute smart contracts in EVM, where smart contracts are associated to Ethereum accounts. Ethereum supports two types of accounts: externally owned accounts (EOA) and contract accounts. An EOA is used to keep a user’s funds in Wei, which is the smallest sub denomination of Ether and is worth 10−18 Ether. An EOA is associated with, and addressed by, a public key; access to an EOA is authenticated by showing the ownership of the corresponding private key. In contrast, a contract account is associated with a piece of executable bytecode (i.e., smart contracts), which defines some business logic of interest. Smart contracts are DApp building-blocks. A DApp often has a user interface as its front-end and some smart contracts as its back-end. Some DApps issue their own cryptocurrency, called tokens, for purposes like Initial Coin Offering (ICO) and exchanges. An Ethereum-based token is a special kind of smart contract (e.g., ERC-20) [20]. Smart contracts execute in EVMs, which are quasi-Turing-complete machines using a stack- based architecture; the term “quasi” means the execution is limited by the amounts of gas offered by transactions. In the Ethereum application layer various vulnerabilities occurs as a result lead to many attacks as describe in Figure in the application layer.
b) The data layer: Contains the blockchain data structures. A transaction is an interaction between an EOA (called sender) and another EOA or contract account (called recipient). A transaction is specified by:
(i) nonce, which is a counter for tracking the total number of transactions that have been initiated by the sender;
(ii) recipient, which specifies a transaction’s destination EOA or contract account;
(iii) value, which is the amount of money (unit: Wei) to be transferred from the sender to the recipient (if applicable);
(iv) input, which is the bytecode or data corresponding to the purpose of the trans- action;
(v) gasPrice and gasLimit, which, respectively, specify the unit price and the maximum amount of gas the sender is willing to pay the winning miner of a block containing the transaction;
(vi) (v,r,s), which is the Elliptic Curve Digital Signature Algorithm (ECDSA) signature of the sender. Execution of a transaction updates the states of the accounts involved and therefore the blockchain.
c) The consensus layer: assures a consistent state of the blockchain. At the moment of writing, Ethereum takes about 12–14 seconds to create a block, meaning that multiple miners could create valid blocks simultaneously and that there could be many stale blocks. Ethereum uses a variant of the GHOST consensus protocol to select the “heaviest” branch as the main chain where the “heaviest” branch is the sub-tree rooted at the fork in question and has the highest cumulative block difficulty, while noting that stale blocks are not on the main chain. Note that Ethereum plans to replace its current use of Proof-of-Work (PoW) with Proof-of-Stake (PoS).
d) The network layer: manages an Ethereum peer-to-peer (P2P) network of nodes or clients such that a node can always get the updated state of the blockchain from some active nodes. The Ethereum network is a structured P2P network where each node (i.e., client) stores a copy of the entire blockchain. For node discovery and routing purposes, each node maintains a dynamic routing table of 160 buckets and each bucket contains up to 16 entries of other nodes’ IDs, IP addresses, UDP/TCP ports. Ethereum uses the RLPx protocol to discover target clients and uses the Ethereum Wire Protocol to facilitate the exchange of Ethereum blockchain information (e.g., transactions, blocks) between clients.
e) The Ethereum Blockchain Environment: runs in an environment that operates across the four layers as follows: a web interface for users to interact with the Ethereum blockchain; a database for Ethereum clients to store the blockchain data; cryptographic mechanisms for security purposes; and the Internet infrastructure to support blockchain communications among Ethereum nodes. We disparate the Ethereum blockchain architecture from the environment, because attacks against the Ethereum blockchain may come from the environment and these attacks may be better addressed in the environment rather than by the Ethereum blockchain.
1.1 Tokes of Ethereum Smart Contract Vulnerabilities
We highlighted smart contract vulnerabilities at each layer of Ethereum architecture as described in Figure 2.
1.1.1 Ethereum Application layer:
· Reentrancy: This vulnerability was first observed from the DAO attack [1], this vulnerability occurs when an external callee contract calls back to a function in the caller contract before the caller contract finishes (i.e., cyclic calls in a sense). This allows the attacker to bypass the due validity check until the caller contract is drained of Ether or the transaction runs out of gas.
· Delegate call Injection: This vulnerability was first observed from an attack against the Parity wallet [2]. To facilitate code-reuse, EVM provides an opcode, delegate call, for inserting a callee contract’s bytecode into the bytecode of the caller contract. As a consequence, a malicious callee contract can directly modify (or manipulate) the state variables of the caller contract. This vulnerability is caused by the fact that a callee contract can update the caller contract’s state variables. The vulnerability can be completely prevented by declaring a contract that is meant to be shared via the delegatecall as a library, which is stateless.
· Frozen Ether: This vulnerability was first observed from another attack against the Parity wallet [3]. The vulnerability results from the ability of users to deposit their money to their contract accounts with the inability to spend their money from those accounts, effectively freezing their money.
· Upgradable Contract: The idea of contract upgrading was introduced to mitigate the problem that smart contracts, once deployed, cannot be modified even if they are later found to have vulnerabilities. To allow contract upgrading, there are two approaches: (i) splitting a contract into a proxy contract and a logic contract such that developers can upgrade the latter but not the former; and (ii) using a registry contract to bookkeep the updated contracts. While effective, these approaches introduce a new vulnerability: When the contract developer becomes malicious, the updated contract can be malicious. This vulnerability (i.e., insecure contact updating) remains to be an open problem.
· DoS with Unexpected Revert: It occurs either when a transaction is reverted due to a caller contract encountering a failure in an external call, or the callee contract deliberately performs the revert operation to disrupt the execution of the caller contract. This vulnerability is caused by the execution of a caller contract being reverted by a callee contract. This vulnerability can be prevented by letting a recipient invoke a transaction to “pull” the money that was set aside by a sender for the recipient, which effectively prevents a sender’s transaction from being reverted.
· Integer Overflow and Underflow: This vulnerability was first observed from the attack against the BEC tokens [4]. It occurs when the result of an arithmetic operation falls outside of the range of a Solidity data type, causing (for example) unauthorized manipulation to the attacker’s balance or other state variables. The vulnerability is caused by Solidity source code not performing proper validation on numeric inputs, and that neither the Solidity compiler nor the EVM provides integer overflow/underflow detection. This vulnerability can be prevented by using the SafeMath library that handles these issues.
· Manipulated Balance: This vulnerability occurs when a contract’s control-flow decision relies on the value of this. balance or address(this).balance, which can be leveraged by an attacker to make itself the only one who can obtain the money. This vulnerability can be prevented by not using a contract’s balance in any conditional statement[5].
· Authentication Through tx.origin: The tx.origin is a global variable in Solidity and refers to the original EOA that initiates the transaction in question. This vulnerability occurs when a contract uses tx.origin for authorization, which can be compromised by a phishing attack. This vulnerability can be prevented by using msg.sender, instead of tx.origin, for authentication, because msg.sender returns the account that incurred the message.
· Erroneous Visibility: It occurs when a function’s visibility is incorrectly specified and thus permits unauthorized access.
· Unprotected Suicide: A contract can be killed by the contract’s owner (or a trusted third-party) using the suicide or self-destruct method. When a contract is killed, its associated bytecode and storage are deleted. The vulnerability is caused by inadequate authentication enforced by a contract. The vulnerability can be mitigated by enforcing, e.g., multi-factor authentication, meaning a suicide operation must be approved by multiple parties.
· Leaking Ether to Arbitrary Address: The vulnerability occurs when a contract’s funds can be withdrawn by any caller, who is neither the owner of the contract nor an investor who deposited funds to the contract. This vulnerability is caused by the failure to check a caller’s identity when the caller invokes a function to send Ether to an arbitrary address. This vulnerability can be prevented by enforcing an adequate authentication on the functions for sending funds.
· Confidentiality Failure: In blockchain, restricting the visibility of a variable or function does not assure that the variable or function is confidential because of the public nature of blockchain (i.e., details of transactions are publicly known). A possible solution to preventing this vulnerability is to use cryptographic techniques, such as timed commitments [6].
· Insufficient Signature Information: The vulnerability occurs when a digital signature is valid for multiple transactions, which can happen when one sender (say Alice) sends money to multiple recipients through a proxy contract (instead of initiating multiple transactions). This vulnerability was first exploited in a replay attack against smart contracts. This vulnerability can be prevented by incorporating the due information in each message, such as a nonce value and timestamps.
· DoS with Unbounded Operations: This vulnerability was first observed from the Govern Mental contract [7].
· Unchecked Call Return Value: This vulnerability is also known as mishandled exceptions. It has two variants, called gasless send and unchecked send. This arise when the return value of a low-level call is not checked, the execution may resume even if the function call throws an error [8].
· Uninitialized Storage Pointer: Recall that in Solidity, the contract state variables are always laid out consecutively in storage, starting from slot 0. For a compound local variable (e.g., struct, array, or mapping), a reference is assigned to an unoccupied slot in the storage to point to the state variable.
· Erroneous Constructor Name: This vulnerability was first observed from the Rubixi contract [9], where the constructor function has an incorrect name that allows anyone to become the owner of the contract. Prior to Solidity version 0.4.22, a function declared with the same name as the contract’s is considered as the contract constructor, which is executed only when creating the contract.
· Type Casts: This vulnerability was first discovered in [10]. Recall that a contract written in the Solidity language can call another contract by directly referencing the callee contract’s instance.
· Outdated Compiler Version: It occurs when a contract uses an outdated compiler, which contains bugs and thus makes a com- piled contract vulnerable. This vulnerability can be prevented by using an up-to-date compiler.
· Short Address: This vulnerability was first realized in [11] and it has been discussed extensively.
· Ether Lost to Orphan Address: Ether lost-to-orphan occur when transferring money, Ethereum only checks that the length of the recipient’s address is no greater than 160-bit but not the validity of the recipient’s address. If money is sent to a non-existing orphan address, then Ethereum automatically registers for the address rather than terminating the transaction. Since the address is not associated to any EOA or contract account, no one can withdraw the transferred money, which is effectively lost. This vulnerability is caused by EVM not being orphan-proof. At the moment of writing, this vulnerability can only be prevented by manually assuring the correctness of the recipient’s address.
· Call-stack Depth Limit: This vulnerability is caused by EVM’s inadequate execution model, and has been eliminated by the hard fork for EIP-150, which re-defines the gas-consumption rules of external calls to make it impossible to reach 1,024 in call stack depth.
· Under-priced Opcodes: This vulnerability was first observed from two DoS attacks [12][13].
· Transaction Ordering Dependence (a.k.a. Front Running): It refers to the concurrency issue that the forthcoming state of blockchain depends on the execution order of transactions, which is, however, determined by the miners
· Timestamp Dependence: This vulnerability occurs when a contract uses the block.timestamp as part of the triggering condition when executing a critical operation (e.g., money transfer) or as the source of randomness, which can be manipulated by a malicious miner. The vulnerability is caused by Ethereum only requiring that a timestamp be greater than the timestamp of its parent block and be within 900 seconds of the current clock.
· Generating Randomness: E.g Many gambling and lottery contracts select winners randomly, for which a common practice is to generate a pseudorandom number based on some initial private seed (e.g., block.number, block.timestamp, block. difficulty or blockhash). However, these seeds are fully controlled by miners, meaning that a malicious miner can manipulate these variables to make itself the winner. This vulnerability is caused by manipulable entropy sources.
1.1.2 Vulnerabilities at the Data Layer
· Indistinguishable Chains: This vulnerability was first observed from the cross-chain replay attack when Ethereum was divided into two chains, namely, ETH and ETC [13]. Recall that Ethereum uses ECDSA to sign transactions. Prior to the hard fork for EIP-155 [7], each transaction consisted of six fields (i.e., nonce, recipient, value, input, gasPrice, and gasLimit). However, the digital signatures were not chain-specific, because no chain-specific information was even known back then. As a consequence, a transaction created for one chain can be reused for another chain. This vulnerability has been eliminated by incorporating chainID into the fields.
· Empty Account in the State Trie: This vulnerability was first observed from a DoS attack reported in References [12][13].
1.1.3 Vulnerabilities at the Consensus Layer
· Outsourceable Puzzle: Recall that Ethereum adopts the PoW puzzle called Ethash, which was meant to be ASIC-resistant and be able to limit the use of parallel computing (owing to the fact that the vast majority of a miner’s effort will be reading a dataset via the limited memory bandwidth). However, a crafty miner can still divide the task of searching for a puzzle solution into multiple smaller tasks and then outsource them. This vulnerability is caused by Ethash only making the puzzle solution partially sequential in preimage search, rather than relying on sequential PoW.
· Probabilistic Finality: This vulnerability is caused by the design that Ethereum blockchain favors availability over consistency, which is choice made under the CAP theorem [14].
· DoS with Block Stuffing: This vulnerability was first observed from the Fomo3D contract [15]. The vulnerability entails only the attacker’s transactions being included in the newly mined blocks while others are abandoned by miners for a period of time. This can happen when the attacker offers a higher gasPrice to incentivize the miners to select the attacker’s transactions. This vulnerability is caused by the greedy mining incentive mechanism. At the moment of writing, there is no solution to prevent this vulnerability.
· Honest Mining Assumption: This vulnerability is caused by the consensus protocol for not being incentive-compatible can be found the detail in [16]. At the moment of writing, this vulnerability remains to be an open problem.
· Rewards for Uncle Blocks: It refers to the uncle-rewarding mechanism for coping with the increase in stale blocks caused by fast block generation. However, this mechanism had a side-effect in allowing selfish miners to make their stale blocks become uncle blocks and receive rewards, effectively incentivizing selfish mining and double-spending.
· Verifier’s Dilemma: This vulnerability was first reported in Reference [17], referring to when the verification of a new transaction requires nontrivial computation effort, miners are subject to attacks regardless of whether they choose to verify the transaction or not. If miners verify a computationally heavy transaction, then they will spend a significant amount of time and give attackers an advantage in the race for the next block; if miners accept the transaction without verification, then the blockchain may include an incorrect transaction. This vulnerability is caused by the high cost in verifying resource-demanding transactions in Ethereum. This vulnerability can be mitigated by limiting the amount of computation that is required for verifying all transactions in a block [17]. However, it is not clear how to eliminate this vulnerability.
4 Vulnerabilities at the Network Layer
4.1 Unlimited Nodes Creation: This vulnerability was reported for the Geth client prior to its version 1.8. In the Ethereum network, each node is identified by a unique ID, which is a 64-byte ECDSA public key. An attacker could create an unlimited number of nodes on a single machine (i.e., with the same IP address) and use these nodes to monopolize the incoming and outgoing connections of some victim nodes, effectively isolating the victims from the other peers in the network. This vulnerability is caused by the weak restriction on the node generation process. This vulnerability can be eliminated by using a combination of IP address and public key as node ID. This countermeasure has not been adopted by the Geth developers who argue that it has a negative impact on the usability of the client.
4.2 Uncapped Incoming Connections: This vulnerability was in the Geth client prior to its version 1.8 [18]. Each node can have a total number of maxpeers (with a default value 25) connections at any point in time, and can initiate up to ⌊(1 + maxpeers)/2⌋ outgoing TCP connections with the other nodes. However, there was no upper limit on the number of incoming TCP connections initiated by the other nodes. This gives the attacker an opportunity to eclipse a victim by establishing maxpeers many incoming connections to a victim node that has no outgoing connections. This vulnerability has been eliminated in Geth v1.8 by enforcing an upper limit on the number of incoming TCP connections to a node, with a default value ⌊maxpeers/3⌋ = 8.
4.3 Public Peer Selection: This vulnerability was detected in Geth client prior to its version 1.8 [18].
4.4 Fixed Peer Selection: The vulnerability refers to the Geth client always fetching the heads of randomly chosen buckets when selecting nodes from its routing table to establish outbound connections. Since the nodes in each bucket are sorted by activity, an attacker could make its node always stay ahead of the other nodes by regularly sending message to the Geth client. This vulnerability has been eliminated in Geth v1.9 by selecting nodes uniformly at random from the set of all nodes in the routing table instead of only the heads of each bucket.
4.5 Sole Block Synchronization: It allows an attacker to partition the Ethereum P2P network without monopolizing the connections of a victim client. Recall that each block header contains a difficulty field, which records the mining difficulty of the block. The total difficulty of the blockchain, denoted by totalDifficulty, is the sum of the difficulty of the blocks up to the present one. .
4.6 RPC API Exposure: This vulnerability was first observed from the attack against the Geth and Parity clients [19].
Reference:
[1] https://www.coindesk.com/understanding-dao-hack-journalists
[3] https://medium.com/blockcat/on-the-parity-multi-sig-wallet-attack-83fb5e7f4b8c
[4] https://nvd.nist.gov/vuln/detail/CVE-2018-10299
[6] https://eprint.iacr.org/2016/1007.pdf
[7]https://www.reddit.com/r/ethereum/comments/4ghzhv/governmentals_1100_eth_jackpot_payout_is_stuck/
[10] https://medium.com/golem-project/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95
[12] https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/
[13] https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513?gi=3b0603be9186
[14] https://dl.acm.org/doi/10.1145/3149.214121
[15] https://medium.com/coinmonks/how-the-winner-got-fomo3d-prize-a-detailed-explanation-b30a69b7813f
[16] https://dl.acm.org/doi/10.1145/3212998
[17] https://dl.acm.org/doi/10.1145/2810103.2813659
[18] https://ljk.imag.fr/membres/Jean-Guillaume.Dumas/Enseignements/ProjetsCrypto/Ethereum/236.pdf
WeBlock
WeBlock is committed to building the world’s most intelligent blockchain acceleration service system. Through the assistance of smart robot and extremely friendly user interaction, every project could enjoy unprecedented service experience. Unlike the past, WeBlock adopts a decentralized and transparent acceleration method: One-Click matching of data analysis and automated service from robot enable initial project funding, user growth and resource integration extraordinarily simple and efficient. In just 7 days, you project will be build brand new.
Official Website: weblock.vip
Twitter: https://twitter.com/WeBlockEnglish
Telegram: https://t.me/WeBlockEnglish (English)
Groups of 8 languages so far, visit our telegram for more information and you can easily find a local admin to help.
