Survey and Analysis of Smart Contract Quality Assurance: Attacks on Smart Contracts

Authors: (1) ZHIYUAN WEI, Beijing Institute of Technology, China; (2) JING SUN, University of Auckland, New Zealand); (3) ZIJIAN ZHANG, XIANHAO ZHANG, XIAOXUAN YANG, and LIEHUANG ZHU, Beijing Institute of Technology, China; (4) XIANHAO ZHANG, Beijing Institute of Technology, China; (5) XIAOXUAN YANG, Beijing Institute of Technology, China; (6) LIEHUANG ZHU, Beijing Institute of Technology, China. Table of Links Abstract and Introduction Overview of Smart Contracts and Survey Methodology Vulnerability in Smart Contracts Attacks on Smart Contracts Defense Methodologies Evaluation Conclusions, Acknowledgement and References 4 ATTACKS ON SMART CONTRACTS Over the past six years, smart contracts have experienced a substantial increase in daily transaction volume, rising from an average of 23 transactions per day in 2016 to an average of 4 million transactions per day in 2021 [3]. Unfortunately, this growth has also led to an increase in the number of attackers exploiting vulnerabilities in smart contracts. Consequently, several high-profile attacks have occurred, resulting in substantial financial losses [61]. One of the most notable attacks on smart contracts was the DAO attack in 2016, which led to millions of dollars worth of Ether being drained from the organization. Since then, smart contracts has experienced several high-profile attacks from 2016 to 2021, as shown in Figure 4. To gain a better understanding of these attacks, we have analyzed and identified eight representative attack patterns. Figure 5 illustrates the major application domains of smart contracts and the corresponding targeted attack patterns. Additionally, we conduct an examination of the vulnerabilities that contribute to these attacks. Through the classification of vulnerabilities based on known attack patterns, we can identify common weakness that require attention. Following this analysis, we provide a comprehensive breakdown of each attack, shedding light on the specific vulnerabilities that contribute to these attacks. 4.1 The DAO Attack (A1) The DAO (Decentralized Autonomous Organization) was a groundbreaking project launched on the Ethereum blockchain in 2016. It aimed to create a decentralized venture capital fund where participants could invest in projects and vote on funding decisions through the use of smart contracts. The DAO project gained significant attention and raised over $150 million USD in funding from investors. However, the DAO’s success was short-lived as it fell victim to a critical security vulnerability. In June 2016, an attacker exploited a flaw in the DAO’s smart contract code, allowing them to drain approximately $60 million USD worth of ether from the organization [8]. This event, known as the DAO attack, was a significant setback for the Ethereum community and led to a contentious debate about the immutability of blockchain transactions and the need for a hard fork to recover the stolen funds. Ultimately, a hard fork was implemented to create a new version of the Ethereum blockchain that reversed the effects of the hack and returned the stolen funds to their rightful owners. Following the occurrence of The DAO hack, other smart contracts, such as Spankchain [97] and Lendf.me [107], also experienced losses due to comparable security vulnerabilities. Atzei et al. [20] provided two attack contract examples, called Mallory and Mallory2. In Mallory, attacker manipulates the control flow and exploits reentrancy (VE34). In Mallory2, attacker efficiently exploits arithmetic overflow/underflow (VE25) and unchecked send (VE30) vulnerabilities by using only two calls. 4.2 Parity Wallet Attack (A2) The Parity Wallet attack encompasses two distinct incidents that occurred in 2017. During these incidents, the Parity Multisig Wallet suffered breaches, leading to substantial financial losses. The Parity Wallet is comprised of two components: a library contract and wallet contracts. The library contract contains the essential functions of a wallet, while the wallet contracts act as proxies that delegate calls to the library contract through the delegatecall mechanism. In both incidents, the vulnerabilities enabled the attackers to obtain unauthorized control over the wallets. The first incident is caused by exploiting unsafe delegatecal (VE19) and more than 30M USD worth of ether is drained [96]. In this incident, the attacker initiated two transactions to manipulate each contract involved. The first transaction was aimed at gaining ownership of the victim’s wallet contract. The second incident on the Parity Multisig Wallet exploited the vulnerability known as suicide (VE17) and resulted in the locking of more than $280 million USD worth of funds [100]. In this incident, the attacker leveraged the delegatecall mechanism to initialize themselves as the owner of the wallet contract, similar to the first incident. 4.3 Fomo3D Attacks (A3) The Fomo3D contract was an Ethereum game where participants could purchase keys using Ether and refer others to the game to earn more Ether. The objective of the game was to be the last participant to purchase a key before the timer expired, thereby winning the entire pot of Ether. The attacker purchased a ticket and then sent multiple transactions with high gas prices in rapid succession, effectively consuming a significant portion of the block’s gas limit. This action caused other transactions related to Fomo3D, including the key purchases made by other participants, to be delayed or stuck in a pending state until the timer ran out. The attackers gain an advantage by exploiting two vulnerabilities: bad randomness (VE40) and DoS with block gas limit (V29) 4.4 KotET Attack (A4) The King of the Ether Throne (KotET) contract was also a game contract where participants competed to win the throne and receive all the Ether held in the contract. This game contract was implemented as a contract account on the Ethereum blockchain. The KotET attack, which occurred in February 2016 [94], exploited two vulnerabilities: unchecked send (VE30) and insufficient gas griefing (VE28). In the attack, when the KotET contract attempted to transfer funds to another wallet contract, both contracts required sufficient gas to successfully process the transaction. However, if the wallet contract had insufficient gas, it would fail to complete the payment, resulting in the funds being returned to the KotET contract. Importantly, the KotET contract was not aware of the payment failure, and the latest player would be crowned as the King, while the compensation payment intended for the previous player would not be sent. 4.5 BatchOverflow Attack (A5) The BatchOverflow attack, which occurred in April 2018, targeted the Beauty Ecosystem Coin (BEC) token. The attack exploited arithmetic overflow/underflow (VE25) vulnerability to achieve an unauthorized increase in digital assets. This vulnerability resulted in the theft of BEC tokens and a temporary shutdown of the exchange platform [2]. According to the blockchain security firm, PeckShield [6], the BatchOverflow attack was not limited to the BEC token. According to the blockchain security firm PeckShield, they discovered similar integer overflow vulnerabilities in around 12 other token smart contracts. Some examples include SMT (proxyOverflow), UET (transferFlow), SCA (multiOverflow), HXG (burnOverflow), and others. 4.6 Frontrunning Attack (A6,A7) Both the DEXs attack and the Bancor attack can be categorized as Frontrunning attacks. The concept of Frontrunning is not exclusive to blockchain and is commonly observed in traditional financial markets. Frontrunning involves manipulating financial markets by gaining undisclosed information about transactions beforehand [126]. This practice is generally deemed illegal in most countries. In the context of blockchain, every transaction is publicly visible in the pending pool before being included in a block. Miners, who have the authority to choose which transactions to include, often prioritize those with higher gas prices. This creates an opportunity for attackers to manipulate the transaction order and maximize their own profits. Frontrunning attacks exploit the vulnerability known as TOD (VE38), which is also referred to as the Frontrunning vulnerability. Eskandari et al. [49] categorize this vulnerability into three types of attacks: displacement, insertion, and suppression attacks. 4.6.1 DEXs Attack (A6). The decentralized exchange (DEX) is an exchange platform built on smart contracts where users can exchange their ERC-20 tokens for ether or other tokens. Frontrunning attacks have become a significant concern in DEXs. These attacks exploit TOD vulnerability to manipulate the execution of transactions and gain an unfair advantage in trading. When a searcher detects a transaction that can yield a profit, it attempts to front-run that transaction by submitting its own transaction with higher gas fees to ensure its execution before the victim’s transaction. These front-running attacks are performed by highly competitive bots that aim to maximize their profits by extracting Miner’s Extractable Value (MEV). According to Flashbots [53], searchers extracted approximately 691 million USD worth of value from Ethereum in January 2023 alone. 4.6.2 Bancor Event (A7). The Bancor ICO is a decentralized exchange platform that allows users to create and trade their own tokens. During the audit of its exchange smart contract, two vulnerabilities were discovered: TOD (VE38) and function default visibility (VE11). The attacker exploited the TOD vulnerability, which enabled them to execute transactions ahead of others, resulting in a profit of 135,229 USD worth of ether [138]. Fortunately, no real-world attack occurred, but the vulnerability itself was identified and addressed. 4.7 Honeypots (A8) Honeypots in the context of smart contracts are a type of fraudulent scheme that capitalizes on security vulnerabilities while employing deceptive tactics. The fundamental concept of a honeypot involves intentionally creating a smart contract that appears to possess an obvious flaw or vulnerability, enticing potential victims to exploit it for financial gain. However, the contract is deliberately designed in a way that when someone attempts to take advantage of the apparent vulnerability, they end up losing their funds instead. Honeypots manipulate human greed and the desire for quick profits, luring unsuspecting users into falling for the trap. The aim is to present an enticing opportunity for financial gain, while in reality, it is a trap orchestrated by malicious actors. According to Torres et al. [130], honeypots typically take advantage of specific vulnerabilities to carry out their deceptive schemes such as incorrect constructor name (VE6), shadowing state variables (VE10), and incorrect inheritance order (VE36). In this section, we have examined eight common attack patterns and their associated lists of vulnerabilities. This analysis has allowed us to address the second research question, RQ2, as outlined in Section 2.2, which focuses on how these common attacks exploit vulnerabilities and the consequences of such attacks. By studying past attacks, we gain valuable insights into common vulnerabilities and attack patterns. This knowledge can be utilized by smart contract developers to enhance the security of their contracts. While it may be challenging to completely eliminate all attacks on vulnerable smart contracts, there are steps that can be taken to minimize risks and improve contract security. By implementing best practices and employing appropriate security measures, developers can reduce the likelihood of their contracts being exploited by attackers. Building upon our understanding of attack patterns, we can now explore various defense methodologies in the next section. This paper is available on arxiv under CC 4.0 license. Authors: (1) ZHIYUAN WEI, Beijing Institute of Technology, China; (2) JING SUN, University of Auckland, New Zealand); (3) ZIJIAN ZHANG, XIANHAO ZHANG, XIAOXUAN YANG, and LIEHUANG ZHU, Beijing Institute of Technology, China; (4) XIANHAO ZHANG, Beijing Institute of Technology, China; (5) XIAOXUAN YANG, Beijing Institute of Technology, China; (6) LIEHUANG ZHU, Beijing Institute of Technology, China. Authors: Authors: (1) ZHIYUAN WEI, Beijing Institute of Technology, China; (2) JING SUN, University of Auckland, New Zealand); (3) ZIJIAN ZHANG, XIANHAO ZHANG, XIAOXUAN YANG, and LIEHUANG ZHU, Beijing Institute of Technology, China; (4) XIANHAO ZHANG, Beijing Institute of Technology, China; (5) XIAOXUAN YANG, Beijing Institute of Technology, China; (6) LIEHUANG ZHU, Beijing Institute of Technology, China. Table of Links Abstract and Introduction Abstract and Introduction Overview of Smart Contracts and Survey Methodology Overview of Smart Contracts and Survey Methodology Vulnerability in Smart Contracts Vulnerability in Smart Contracts Attacks on Smart Contracts Attacks on Smart Contracts Defense Methodologies Defense Methodologies Evaluation Evaluation Conclusions, Acknowledgement and References Conclusions, Acknowledgement and References 4 ATTACKS ON SMART CONTRACTS Over the past six years, smart contracts have experienced a substantial increase in daily transaction volume, rising from an average of 23 transactions per day in 2016 to an average of 4 million transactions per day in 2021 [3]. Unfortunately, this growth has also led to an increase in the number of attackers exploiting vulnerabilities in smart contracts. Consequently, several high-profile attacks have occurred, resulting in substantial financial losses [61]. One of the most notable attacks on smart contracts was the DAO attack in 2016, which led to millions of dollars worth of Ether being drained from the organization. Since then, smart contracts has experienced several high-profile attacks from 2016 to 2021, as shown in Figure 4. To gain a better understanding of these attacks, we have analyzed and identified eight representative attack patterns. Figure 5 illustrates the major application domains of smart contracts and the corresponding targeted attack patterns. Additionally, we conduct an examination of the vulnerabilities that contribute to these attacks. Through the classification of vulnerabilities based on known attack patterns, we can identify common weakness that require attention. Following this analysis, we provide a comprehensive breakdown of each attack, shedding light on the specific vulnerabilities that contribute to these attacks. 4.1 The DAO Attack (A1) The DAO (Decentralized Autonomous Organization) was a groundbreaking project launched on the Ethereum blockchain in 2016. It aimed to create a decentralized venture capital fund where participants could invest in projects and vote on funding decisions through the use of smart contracts. The DAO project gained significant attention and raised over $150 million USD in funding from investors. However, the DAO’s success was short-lived as it fell victim to a critical security vulnerability. In June 2016, an attacker exploited a flaw in the DAO’s smart contract code, allowing them to drain approximately $60 million USD worth of ether from the organization [8]. This event, known as the DAO attack, was a significant setback for the Ethereum community and led to a contentious debate about the immutability of blockchain transactions and the need for a hard fork to recover the stolen funds. Ultimately, a hard fork was implemented to create a new version of the Ethereum blockchain that reversed the effects of the hack and returned the stolen funds to their rightful owners. Following the occurrence of The DAO hack, other smart contracts, such as Spankchain [97] and Lendf.me [107], also experienced losses due to comparable security vulnerabilities. Atzei et al. [20] provided two attack contract examples, called Mallory and Mallory2. In Mallory, attacker manipulates the control flow and exploits reentrancy (VE34) . In Mallory2, attacker efficiently exploits arithmetic overflow/underflow (VE25) and unchecked send (VE30) vulnerabilities by using only two calls. reentrancy (VE34) arithmetic overflow/underflow (VE25) unchecked send (VE30) 4.2 Parity Wallet Attack (A2) The Parity Wallet attack encompasses two distinct incidents that occurred in 2017. During these incidents, the Parity Multisig Wallet suffered breaches, leading to substantial financial losses. The Parity Wallet is comprised of two components: a library contract and wallet contracts. The library contract contains the essential functions of a wallet, while the wallet contracts act as proxies that delegate calls to the library contract through the delegatecall mechanism. In both incidents, the vulnerabilities enabled the attackers to obtain unauthorized control over the wallets. The first incident is caused by exploiting unsafe delegatecal (VE19) and more than 30M USD worth of ether is drained [96]. In this incident, the attacker initiated two transactions to manipulate each contract involved. The first transaction was aimed at gaining ownership of the victim’s wallet contract. The second incident on the Parity Multisig Wallet exploited the vulnerability known as suicide (VE17) and resulted in the locking of more than $280 million USD worth of funds [100]. In this incident, the attacker leveraged the delegatecall mechanism to initialize themselves as the owner of the wallet contract, similar to the first incident. unsafe delegatecal (VE19) suicide (VE17) 4.3 Fomo3D Attacks (A3) The Fomo3D contract was an Ethereum game where participants could purchase keys using Ether and refer others to the game to earn more Ether. The objective of the game was to be the last participant to purchase a key before the timer expired, thereby winning the entire pot of Ether. The attacker purchased a ticket and then sent multiple transactions with high gas prices in rapid succession, effectively consuming a significant portion of the block’s gas limit. This action caused other transactions related to Fomo3D, including the key purchases made by other participants, to be delayed or stuck in a pending state until the timer ran out. The attackers gain an advantage by exploiting two vulnerabilities: bad randomness (VE40) and DoS with block gas limit (V29) bad randomness (VE40) DoS with block gas limit (V29) 4.4 KotET Attack (A4) The King of the Ether Throne (KotET) contract was also a game contract where participants competed to win the throne and receive all the Ether held in the contract. This game contract was implemented as a contract account on the Ethereum blockchain. The KotET attack, which occurred in February 2016 [94], exploited two vulnerabilities: unchecked send (VE30) and insufficient gas griefing (VE28) . In the attack, when the KotET contract attempted to transfer funds to another wallet contract, both contracts required sufficient gas to successfully process the transaction. However, if the wallet contract had insufficient gas, it would fail to complete the payment, resulting in the funds being returned to the KotET contract. Importantly, the KotET contract was not aware of the payment failure, and the latest player would be crowned as the King, while the compensation payment intended for the previous player would not be sent. unchecked send (VE30) insufficient gas griefing (VE28) 4.5 BatchOverflow Attack (A5) The BatchOverflow attack, which occurred in April 2018, targeted the Beauty Ecosystem Coin (BEC) token. The attack exploited arithmetic overflow/underflow (VE25) vulnerability to achieve an unauthorized increase in digital assets. This vulnerability resulted in the theft of BEC tokens and a temporary shutdown of the exchange platform [2]. According to the blockchain security firm, PeckShield [6], the BatchOverflow attack was not limited to the BEC token. According to the blockchain security firm PeckShield, they discovered similar integer overflow vulnerabilities in around 12 other token smart contracts. Some examples include SMT (proxyOverflow), UET (transferFlow), SCA (multiOverflow), HXG (burnOverflow), and others. arithmetic overflow/underflow (VE25) 4.6 Frontrunning Attack (A6,A7) Both the DEXs attack and the Bancor attack can be categorized as Frontrunning attacks. The concept of Frontrunning is not exclusive to blockchain and is commonly observed in traditional financial markets. Frontrunning involves manipulating financial markets by gaining undisclosed information about transactions beforehand [126]. This practice is generally deemed illegal in most countries. In the context of blockchain, every transaction is publicly visible in the pending pool before being included in a block. Miners, who have the authority to choose which transactions to include, often prioritize those with higher gas prices. This creates an opportunity for attackers to manipulate the transaction order and maximize their own profits. Frontrunning attacks exploit the vulnerability known as TOD (VE38), which is also referred to as the Frontrunning vulnerability. Eskandari et al. [49] categorize this vulnerability into three types of attacks: displacement, insertion, and suppression attacks. 4.6.1 DEXs Attack (A6). The decentralized exchange (DEX) is an exchange platform built on smart contracts where users can exchange their ERC-20 tokens for ether or other tokens. Frontrunning attacks have become a significant concern in DEXs. These attacks exploit TOD vulnerability to manipulate the execution of transactions and gain an unfair advantage in trading. When a searcher detects a transaction that can yield a profit, it attempts to front-run that transaction by submitting its own transaction with higher gas fees to ensure its execution before the victim’s transaction. These front-running attacks are performed by highly competitive bots that aim to maximize their profits by extracting Miner’s Extractable Value (MEV). According to Flashbots [53], searchers extracted approximately 691 million USD worth of value from Ethereum in January 2023 alone. 4.6.1 DEXs Attack (A6). TOD 4.6.2 Bancor Event (A7). The Bancor ICO is a decentralized exchange platform that allows users to create and trade their own tokens. During the audit of its exchange smart contract, two vulnerabilities were discovered: TOD (VE38) and function default visibility (VE11) . The attacker exploited the TOD vulnerability, which enabled them to execute transactions ahead of others, resulting in a profit of 135,229 USD worth of ether [138]. Fortunately, no real-world attack occurred, but the vulnerability itself was identified and addressed. 4.6.2 Bancor Event (A7). TOD (VE38) function default visibility (VE11) TOD 4.7 Honeypots (A8) Honeypots in the context of smart contracts are a type of fraudulent scheme that capitalizes on security vulnerabilities while employing deceptive tactics. The fundamental concept of a honeypot involves intentionally creating a smart contract that appears to possess an obvious flaw or vulnerability, enticing potential victims to exploit it for financial gain. However, the contract is deliberately designed in a way that when someone attempts to take advantage of the apparent vulnerability, they end up losing their funds instead. Honeypots manipulate human greed and the desire for quick profits, luring unsuspecting users into falling for the trap. The aim is to present an enticing opportunity for financial gain, while in reality, it is a trap orchestrated by malicious actors. According to Torres et al. [130], honeypots typically take advantage of specific vulnerabilities to carry out their deceptive schemes such as incorrect constructor name (VE6) , shadowing state variables (VE10) , and incorrect inheritance order (VE36). incorrect constructor name (VE6) shadowing state variables (VE10) incorrect inheritance order (VE36). In this section, we have examined eight common attack patterns and their associated lists of vulnerabilities. This analysis has allowed us to address the second research question, RQ2 , as outlined in Section 2.2, which focuses on how these common attacks exploit vulnerabilities and the consequences of such attacks. By studying past attacks, we gain valuable insights into common vulnerabilities and attack patterns. This knowledge can be utilized by smart contract developers to enhance the security of their contracts. While it may be challenging to completely eliminate all attacks on vulnerable smart contracts, there are steps that can be taken to minimize risks and improve contract security. By implementing best practices and employing appropriate security measures, developers can reduce the likelihood of their contracts being exploited by attackers. Building upon our understanding of attack patterns, we can now explore various defense methodologies in the next section. RQ2 This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Survey and Analysis of Smart Contract Quality Assurance: Attacks on Smart Contracts

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Advancing OOD Detection: A Deep Learning Approach

Survey and Analysis of Smart Contract Quality Assurance: Abstract and Introduction

Survey and Analysis of Smart Contract Quality Assurance: Overview of Smart Contracts

Survey and Analysis of Smart Contract Quality Assurance: Vulnerability in Smart Contracts

Survey and Analysis of Smart Contract Quality Assurance: Defense Methodologies

Advancing OOD Detection: A Deep Learning Approach

Survey and Analysis of Smart Contract Quality Assurance: Abstract and Introduction

Survey and Analysis of Smart Contract Quality Assurance: Overview of Smart Contracts

Survey and Analysis of Smart Contract Quality Assurance: Vulnerability in Smart Contracts

Survey and Analysis of Smart Contract Quality Assurance: Defense Methodologies

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps