An Analysis of Ontology Smart Contract Security and Loopholes — Part 1
Foreword: The security of smart contracts is one of the hottest topics in blockchain technology. All the existing smart contract systems have shown some types of loopholes, whether they are backed by the Ethereum Virtual Machine (EVM) or the EOS WASM Virtual Machine. These loopholes have caused huge losses for projects and users, and have called into question the security of blockchain technology.
Chapter 1: Introduction
The security loopholes of smart contracts are not caused by blockchain virtual machines — most of them are coding issues caused by smart contract developers. For example, some Ethereum smart contract developers are not well-versed in Solidity, which increases the risks of loopholes. Of course, some security loopholes are caused by certain features of the smart contract platforms themselves. Moreover, since data on blockchains is inherently tamper-resistant, these loopholes cannot be closed by upgrades or data rollbacks. Therefore, it became all the more important for smart contract developers to have a full understanding of existing smart contract systems on blockchain platforms.
Ontology currently uses NeoVM to run its smart contracts. Developers can use the languages they are good at, for example, C# and Python, to write smart contracts, without the need to learn a new language, which makes developing smart contracts much easier. However, we have found and collected from our practice some potential security issues when developing smart contracts on Ontology. If we can prevent these issues, then we can help projects and users avoid losses.
Chapter 2: Cross-contract Call Attacks
In this article, we will talk about cross-contract call attacks, a type of potential loophole attack that may happen when developing smart contracts on Ontology. Developers may need random numbers when writing smart contracts. Normally, they can use Ontology Oracle to access credible external data sources. In its simplified form, some developers need to get the current block hash as the random number. In this article, we will mainly analyze the potential security issues of smart contract development and solutions when using the current block hash as the random number.
2.1 Contracts with Loopholes
Below is a code sample using the current block hash as the random number, we call this Contract A:
We can see that Contract A uses getRandomNumber() to obtain the current block hash as the source of the random number and make some tweaks. Users can receive incentives if their guessed numbers match the numbers generated by the contract.
2.2 Loophole Attacks
At first glance Contract A seems to be working just fine since the current block hash cannot be predicted by anyone except the node that generates the block. However, attackers can write another smart contract to invoke and attack Contract A. The following shows how Contract B attacks Contract A:
As can be seen, attackers write another smart contract to invoke Contract A. By using the same random number generation algorithm as Contract A, Contract B is executed in the same block as Contract A. By doing this, Contract B is able to get the random number generated by Contract A and then keeps winning by generating the same random number.
Chapter 3: Prevention of Random Number Cross-contract Call Attacks
How do smart contract developers prevent such attacks? We can see that the attack can be prevented by preventing Contract B from calling Contract A. Ontology smart contract developers can use GetCallingScriptHash() and GetEntryScriptHash() to solve this problem. Below is Contract C, which has been modified based on Contract A and can prevent such attacks.
GetCallingScriptHash() can obtain the contract hash used for calling the current smart contract, and GetEntryScriptHash() can obtain the contract hash of the calling contract entry. When the contract hash used for calling the current contract is not the same as that of the calling contract entry, the caller of the current smart contract is deemed to be another smart contract, instead of the user who is using the wallet address to call the contract. In this way, we can prevent the smart contract call attack.
Chapter 4: Afterword
This article listed one type of potential attack Ontology smart contract developers may encounter. This type of attack is hard to discover. Developers who do not have a good understanding of smart contracts may not be able to predict and prevent such attacks. The root cause is that developers use a simplified method of choosing random numbers. In our future tech point articles, we will talk about more types of loophole attacks to help Ontology smart contract developers avoid potential loopholes.
Ontology smart contract developers can also use VaaS-ONT, an automatic smart contract formal verification platform integrated into SmartX, the Ontology smart contract IDE, to locate risky code and find out the cause in one click, which can verify common security loopholes, security properties, and function correctness of smart contracts or blockchain applications, thus improving security.
Are you a developer? Make sure you have joined our tech community on Discord. Also, take a look at the Developer Center on our website, there you can find developer tools, documentation, and more.
Find Ontology elsewhere
Ontology website / Ontology GitHub / ONTO website / OWallet (GitHub)
