What types of security issues are there in blockchain?

This article was published by Alpha Community on August 21, 2018.

I. Introduction

On August 6, 2018, Tencent Security released the "2018 First Half Blockchain Security Report," which indicated that there are currently over 1,600 types of cryptocurrencies worldwide. In the first half of 2018, losses in the blockchain sector due to security issues exceeded $2.7 billion, and the amount lost due to blockchain security incidents continues to rise. From the IOTA "Mailgate Incident," USDT "Fake Recharge Vulnerability," EOS "Rainbow Attack," to BEC and SMT "Integer Overflow Attack Vulnerability," BTG "51% Hash Power Attack," and so on, this series of events has sparked widespread attention and reflection.

What are the main security threats to blockchain? Why are the security issues of smart contracts so important that they attract so much attention? How many types of smart contract security issues are there? What are the mainstream security monitoring methods currently available? What is the most effective method? How can people obtain secure and bug-free smart contract code? To address these questions, we interviewed Guo Yu, the founder of SECBIT Lab, to systematically introduce the security issues in the blockchain industry and mainstream solutions.

II. Six Major Types of Blockchain Security

From a security perspective, blockchain technology can be divided into five layers, with corresponding security issues categorized into six major types.

Blockchain 2.0 Version Technology Architecture

First Layer, Cryptography. Cryptography is the foundational technology of blockchain, including hash algorithms, digital signatures, random numbers, etc. If there are problems or vulnerabilities in these cryptographic technologies, the trust built on the entire blockchain will collapse.

Although cryptographic technology is currently quite mature, the possibility of significant vulnerabilities is relatively low, but some projects may still have issues. On July 15, 2017, IOTA, known as the "First Coin of the Internet of Things," received an email from the DCI, an academic research group affiliated with MIT, warning the IOTA team that the hash algorithm Curl-P had weaknesses, and DCI could successfully attack the system to steal user funds. Although IOTA subsequently questioned and refuted DCI's email, to date, no user has reported stolen funds due to this vulnerability, but this incident raised concerns about the cryptographic security of IOTA and other projects.

Second Layer, Generation, Use, and Protection of User Private Keys. The credentials for users to participate in blockchain are a pair of public and private keys. The premise for anyone to engage in interactions on the blockchain is that they possess a secure private key and can safeguard it. Therefore, the generation, usage, and protection of private keys are crucial.

In July of this year, EOS faced security risks due to vulnerabilities in its private key generation tool, leading to the creation of private keys that hackers exploited in a "Rainbow" attack, resulting in the theft of digital assets worth tens of millions.

Third Layer, Node System Security Vulnerabilities. This issue falls under traditional security categories, such as blockchain nodes not having buffer overflow and other traditional security vulnerabilities. Additionally, blockchain nodes must accurately implement the consensus protocol of the blockchain; nodes should not expose APIs that should remain hidden, allowing hackers to easily access critical information about some nodes. Both Ethereum and EOS have previously been reported to have serious security vulnerabilities. This aspect of security is also vital.

Fourth Layer, Underlying Consensus Protocols. The mainstream blockchain consensus protocols currently on the market include POW, POS, DPOS, and PBFT. The underlying consensus protocol determines whether the entire architecture of the blockchain is trustworthy and whether it can genuinely form a consensus-based blockchain. There are not many consensus protocols that have been proven to be secure, as consensus protocols are inherently complex both theoretically and in terms of technical implementation. However, consensus protocols that have been validated over a long period, such as Bitcoin's POW, are relatively secure. Consensus protocols face an impossible triangle: security, decentralization, and efficiency; only two of these can be achieved simultaneously. If efficiency is prioritized, either decentralization or security must be sacrificed.

The security of a blockchain system's consensus protocol is a critical issue.

Theoretically, all cryptocurrencies created based on the underlying consensus protocol are at risk of 51% hash power attacks. In the first half of this year, at least four cryptocurrencies were subjected to 51% hash power attacks, including Monacoin, Bitcoin Gold, Verge, and Electroneum, resulting in losses of tens of millions of dollars for users.

Fifth Layer, Smart Contracts. Smart contracts are a set of digitally defined promises, including agreements that the parties involved can execute. Any participant can create contracts at the application layer, known as DAPPs (Decentralized Applications). This is also where the most security issues currently arise.

The security risks of smart contracts encompass three aspects: first, whether there are vulnerabilities. Are there common security vulnerabilities in the contract code? Second, whether it is trustworthy. A smart contract without vulnerabilities may not be secure; the contract must ensure fairness and trustworthiness. Third, compliance with certain standards and processes. Since the creation of contracts requires promises to be defined in digital form, if the creation process is not standardized, significant risks may arise.

Currently, many smart contracts in the market have security vulnerabilities. For example, on June 3, SECBIT Lab discovered that 81 contracts on Ethereum contained the same error, with the transferFrom function in ERC20 Token contracts posing significant risks. If issues arise after deployment, it could lead to irreparable losses. On June 6, SECBIT Lab found that the ERC20 token contract FXE had a business logic implementation flaw, allowing anyone to transfer tokens from others' accounts at will, putting the tokens at risk of total loss.

As practitioners in the blockchain industry, users of smart contracts, or holders of cryptocurrencies, it is essential to learn relevant cryptography and smart contract programming knowledge. One should not casually copy and use code related to financial security, such as contracts and public/private keys. If malicious attackers disseminate code with severe vulnerabilities online, enticing organizations with inadequate technical development capabilities to use it, it could lead to devastating impacts and irreparable losses for users.

Sixth Layer, Incentive Mechanism Design. For smart contracts to facilitate collaboration, it is often necessary to design corresponding economic incentive mechanisms. Economic incentives are a groundbreaking concept within blockchain technology. A truly healthy and vibrant blockchain ecosystem requires a good incentive mechanism. However, if the economic incentive design is not secure enough, the ecosystem may fail to develop, as seen in typical Ponzi-like games, which is something to be wary of.

III. Three Major Issues of Smart Contracts

The six layers of blockchain security issues introduced earlier are categorized based on their respective technical levels, with lower-level technologies being more stable. For instance, once cryptography is selected, it is not easily changed.

Smart contracts are relatively flexible, and anyone can create them, making it easier for security issues to arise.

Any user can create a contract based on a consensus foundation, similar to how any citizen can draft a contract based on a law, where the law serves as a consensus mechanism (platform), and the contract contains inherent binding clauses. Using a DAPP is akin to signing a contract, and all actions must comply with the contract terms. Therefore, the security risks of smart contracts directly relate to users' financial losses.

So far, SECBIT Lab has identified three major issues with smart contracts in the market:

First, security vulnerabilities represented by integer overflow. Security vulnerabilities are often inadvertently introduced by the code writers, potentially causing certain functional components of the contract to fail. In the worst-case scenario, this could lead to hacker attacks, users losing coins, or even hackers creating large amounts of coins out of thin air. For example, BEC, SMT, and EDU have previously experienced attacks due to integer overflow vulnerabilities, resulting in their values dropping to zero.

Second, smart contract permission control. Generally, a smart contract will set an administrator who typically has superuser privileges. Such contracts carry significant security risks because if the administrator's private key is compromised, it can lead to substantial losses. According to incomplete statistics from SECBIT Lab, among the top 570 Token contracts, 342 contracts have functions that can only be called by the administrator (Only Owner), and many contracts allow the administrator to mint, burn, freeze accounts, and halt transfers with excessive privileges.

On July 10 of this year, the cryptocurrency exchange Bancor reported an attack, resulting in the loss of Ethereum worth $12.5 million, Bancor tokens worth $10 million, and Pundix tokens worth $1 million. Our analysis revealed that this theft incident was related to the BancorConverter contract, where the attacker (hacker/insider) obtained the private key of the administrator account and used the administrator's identity to steal users' tokens, causing significant losses to users.

Third, standardization issues. Currently, many smart contracts lack unified standards for implementation. Smart contracts involve interactive collaboration among multiple parties, and if the contract is not standardized, it can lead to misunderstandings about the contract's behavior, resulting in numerous security issues.

For instance, this year, a series of "fake recharge" incidents have emerged, including Ethereum tokens and USDT. According to incomplete statistics from an organization, there are 3,619 single-token contracts in the market that have "fake recharge" vulnerability risks, including several well-known tokens.

Under normal circumstances, if a transfer fails during the recharge process, the account will be unable to recharge, and the account balance will remain at 0. However, if the contract has a "fake recharge" vulnerability, the system will not indicate that the recharge has failed when the transfer is unsuccessful, leading exchanges to mistakenly judge the result as a successful recharge. If a hacker discovers this vulnerability, they could continuously perform "fake" recharges and then withdraw the funds, causing direct losses to the exchange.

IV. The Importance of Formal Verification

Currently, there are three main methods for verifying smart contract security issues in the market: first, testing; second, auditing; and third, formal verification. Testing requires programs to run automatically, checking for issues such as integer overflow vulnerabilities through various possible inputs. However, this testing typically cannot achieve 100% coverage, and there will inevitably be omissions. Auditing relies on the expertise of professionals to review, but even the most skilled experts may overlook certain issues. The first two traditional methods cannot guarantee that there are no vulnerabilities in the contract, but formal verification can achieve this.

Formal verification can address three types of issues: the first type is security without vulnerabilities: using mathematical reasoning methods to capture and cover all behaviors of the contract, covering all possibilities to ensure that the contract has no vulnerabilities. The second type is trustworthiness: transparency. The creator of the contract must not only clarify what has been done but also prove to everyone that the code indeed performs as stated. This is something that can currently only be achieved through formal verification. The third type is standardization issues. The previously mentioned fake recharge vulnerability arose because the ERC20 standard of Ethereum was written very ambiguously and incompletely. How can it be written comprehensively? This requires that the contract's standards cannot be expressed in natural language or textual descriptions but should instead introduce formal specifications, using a mathematical logical language for strict definitions.

Formal verification has already seen numerous application cases in the industry, especially in fields related to security systems, such as aerospace, high-speed rail, and nuclear power, where dedicated teams provide formal verification services, and its role and effectiveness have long been recognized by experts in the security industry.

Currently, formal verification includes two types: model checking and deductive reasoning. Relatively authoritative and secure companies, such as Zeppelin and the Ethereum official website, have previously published problematic smart contract codes. If there could be a more trustworthy smart contract code repository that does not rely on authority and is open for everyone to use, it would significantly help resolve this issue.