The concept of a smart contract existed as early as 1994. However, due to the lack of a trusted execution environment, the smart contract was not applied to practical scenarios. After Satoshi Nakamoto put forward the concept of Bitcoin back in 2008, it was found that the blockchain technology, on which Bitcoin was based, provided a trusted execution environment for smart contracts.
A smart contract is deployed on the EVM and eventually deployed on the public blockchain. Bitcoin led the way in blockchain technology, and Ethereum revived the smart contract, so to speak.
In fact, the development of the smart contract has been very stable. Statistics from the CM Blockchain Security Center show that in the most recent month the average daily increase in the number of smart contracts was about 2,200, showing a very stable upward trend.
Smart contracts are being used in many application scenarios, such as decentralized wallets, token issuing, crowd-funding and some very popular blockchain games such as FO3D and CryptoKitties. With the rapid developments in smart contracts, we have begun to witness many attacks involving smart contracts. The following are figures on security incidents involving smart contracts from 2011 to 2018.
In fact, security incidents involving smart contracts account for around 6%, a very small proportion, of all security events involving the blockchain. However, based on the statistical data, total losses of up to 1.24 billion USD were incurred. This indicates that although the proportion of security incidents involving smart contracts was relatively small, these incidents caused very serious consequences. As smart contracts can have a great impact on real-time digital currency transactions, we should attach great importance to the security of smart contracts.
The DAO incident, which took place in June 2016 and has become well known, caused a hard fork of Ethereum and an asset loss of approximately 60 million USD, accounting for nearly one-third of the total assets.
In July 2017, the multiple signature vulnerabilities of the parity wallet caused a loss of 1.5 million ETH.
As most know, the BeautyChain incident that took place in April 2018 caused a 1 billion loss in the assets of BEC in a few days. Similarly, the smartmash incident, caused by overflow and access control issues, resulted in a significant asset loss worth 140 million USD.
With the occurrence of these major incidents involving smart contracts, we cannot help but think about what problems emerged at the code level of Solidity and what types of vulnerabilities may exist in smart contracts.
Here is a brief overview of the TOP 10 types of attacks on smart contracts: reentrancy attack, access control, integer overflow, unchecked call return value, transaction sequence dependency, timestamp dependency, condition competition, short address attack, predictable random processing, etc.
Today, we will talk briefly about three types of vulnerabilities that are commonly seen:
Integer Overflow
As we all know, the range of an odometer is from 0 to 9999. When the mileage reaches the upper limit, the reading will return to zero. In fact, this is an example of an integer overflow commonly seen in our daily lives.
With vulnerabilities in the EVM and smart contracts, the range of number of data bits in the EVM is equivalent to the 1 to 999999 range on the odometer. The number of data bits on the EVM is in the range of 0 to 255. When the number reaches 255, an increase of 1 will cause an overflow and the number will return to zero. When the number reaches 0, a decrease of 1 will cause an underflow and the number will change to the maximum value.
Addition and multiplication will cause overflows, and subtraction will cause underflow, to which we should pay attention during code writing.
With the BEC incident, the 257th line of code showed a simple amount type and the amount parameter was equal to the value of the local variable CNT. In this simple operation, CNT was verified, but the amount was not.
Therefore, during the attack, the attacker introduced a very large value, causing an amount overflow. When this parameter caused the value of the amount to return to zero, detection was bypassed. Although a more powerful detection was arranged, the detection was also bypassed after the amount reached zero. Therefore, the hacker obtained a large amount of digital currency with a very large value, without paying a single cent.
We can review these attack events through Etherscan in order to analyze how the attack processes were realized.
Similarly, the edu event was also caused by integer overflow, plus problems in data access control. The two events shared some common aspects, and also had some different aspects.
Next, we will discuss access problems. In fact, there are many types of access problems, and we will explain the problem of loss of control over the constructor simply. The constructor is a very important and special function in the smart contract, which is used for initializing the ownership of a smart contract.
In smart contract versions earlier than version 0.4.2, the contract name and the name of its constructor must be identical. If they are different, the constructor may be called by other contracts. In this way, malicious attackers may obtain ownership of the current smart contract and then carry out some other operations.
With the smart contract MorphToken, the attack took place due to an inconsistency between the capital letter and the lowercase letter.
Reentrancy Vulnerability
Next, we will talk about the reentrancy vulnerability. In fact, reentrancy is recursion, which refers to the cyclic call of a function and the cyclic call of itself. The withdraw function of a code contract supports recursion, and as no judgment is made prior to a transfer, an attacker can take this opportunity to use the reentrancy vulnerability.
The fallback function can be called depending on the value, so an attacker may carry out a cyclic call of withdraw by taking advantage of such a contract to conduct a withdrawal.
After this complicated operation and cycle, an attacker can transfer all the digital currency under the public contract to his/her own wallet. As we all know, the DAO incident was caused by this vulnerability, resulting in a loss of assets worth 115 million USD based on the market value at that moment, which accounted for one-third of the total assets.
Prevention of Vulnerabilities
After learning about the three types of vulnerabilities mentioned above, you may be thinking about how we can prevent these vulnerabilities. For example, with regards to the integer overflow vulnerability, we can guarantee the security of digital currency by carrying out detailed parameter control or by using some third-party SafeMath libraries.
To prevent the access control vulnerability, we should conform to coding specifications and ensure that the contract name and the constructor name are identical. If the constructor is used, we recommend the use of constructor for creating some composite functions.
As for the reentrancy vulnerability, we should pay attention to three points. As mentioned earlier, an amount transfer operation should be carried out prior to amount transfer variables, followed by some relevant cyclic operations.
In addition, the above mentioned call.value has no upper limit for gas, so we can ensure that recursion is impossible by using the upper limit of gas in this transfer operation, namely 2300.
Finally, we can also realize these functions through mutual exclusion in the code.
Automated Audit of Smart Contracts
According to our statistics, the number of smart contracts has reached 200,000. From the perspective of third-party manual audit, such audits cannot keep pace with the development of smart contracts, so more attention is being given to automated audits.
Automated audits can be divided into three types, including matching based on feature code, automated detection based on formal verification, and automated audit based on symbolic execution and symbolic abstraction.
Feature code matching in smart contracts is similar to traditional feature code matching, which involves the detection and abstraction of smart contract codes by matching the source code of the inspected module.
However, there is another problem with smart contracts. In fact, only about 40% of all smart contracts on the public network have plain codes according to our statistics. Therefore, in terms of matching of feature codes, we need to resort to reverse engineering for the matching of some feature codes, which poses a certain degree of difficulty.
Next, we will explain automated detection based on symbolic execution and symbolic abstraction. Now, there are many similar detection tools, such as Mythril, Oyente, Maian, and other well-known tools for symbolic execution. In fact, the source code of a smart contract is first compiled as opcode using the SOC compiler, namely the EVM, which is similar to a compiled and executed operational code. Then the code can be converted into an image in the form of modeling through the formation of a Control Flow Graph (CFG), enabling us to understand the logic of the source code opcode in a better way. For example, when a judgment is made, we can analyze such problems in a better way.
Finally, we should analyze symbolic abstraction, namely Securify. There is a significant difference between smart contracts and other source codes, namely the very low degree of code coupling in smart contracts. The original code coupling is very high, so when scanning smart contracts, we might conduct detection on individual modules and carry out modeling for various modules, and then learn about some types of malicious attacks through matching.
This is the difference between such analysis and traditional automated detection and analysis. In this way, Securify can carry out such detection for its symbolic abstraction analysis.
Ecological Security of the Blockchain
Finally, I would like to ask another question. From the perspective of project security, if we can solve problems in code, do you think we can actually guarantee the security of a project?
I do not think so. As a crucial aspect of smart contracts, such problems must not be overlooked, but there will be other problems with smart contracts. A project involves not only the smart contract but also the technical team, quality of the white paper, and public opinions on social networks, which may cause certain risks to the security of the project.
For example, based on our findings, many technical teams engaged in fraudulent behavior. The CVs of their members were fake, or their white papers were very similar and characterized by very poor quality.
In addition, the phenomenon of “pilfering” is indeed a problem. For an airdrop in a project, an address may be used for pilfering a lot of coins. For example, at an official address, an attacker may pretend to have found some airdrops by entering some names using the official address in order to steal ETH from some normal users.
Therefore, we believe that blockchain security is multi-dimensional security, so the security of a project cannot be guaranteed just from the perspective of a smart contract or the code. We should detect the security of a project by using big data technologies, AI technologies, or natural language analysis technologies such as npl in a better way.
CM also created a project named RatingToken, in which sentiment analysis on a project can be conducted through on-chain and off-chain data extraction and analysis and natural language processing (NLP).
Therefore, we hope to make joint efforts with all interested parties through introducing more dimensions, and bring in more talented individuals who will maintain the ecological security of the blockchain together with us.
Official website of RatingToken: https://www.ratingtoken.net/?from=steemit