The arch rival behind “frozen” contracts | LianAn Technology Smart Contract Vulnerability Analysis Series Phase II

DoS vulnerabilities

BEOSIN
8 min readAug 30, 2018

DoS attack reappeared in blockchain, security audit teams came to help

In the last phase, we talked about integer overflow and underflow, it caused excessive minting of tokens and then price drop of tokens. However, using SafeMath can prevent similar vulnerabilities from being exploited.

Looking at the current situation of blockchain and cryptocurrency industries, the pace of them are becoming so fast that we don’t even have time to look back at those victories and failures happened before. The only thing we can do is to follow the crowd and trying to catch up with the rest. Everything on the battle ground in 2016 seems to be frozen in the history, very few people try to recall what happened here.

We dug out the DoS attack happened then and share the principle analysis and fix-up techniques with you guys, hope you can remember those lessons in mind.

Incidents Review

From February 6th to February 8th of 2016, During the Turbulent Age version of The King of the Ether Throne (KotET), there are a lot of reimbursements for lost competitors and unaccepted offers’ money in the game can not be returned to the original players.

Ironically, in the same month, a Ponzi game called GovernMental which tried to fool players around suffered DoS attack. The ETH attackers got are traded using 2.5 million gas. This transaction exceeded the limit of gas that contracts can hold, causing transactions pending.

Intended destruction of transaction process and blocking transaction tunnel both used the old-fashioned attack method — DoS, which represents Denial of Service. This attack method can disrupt regular transaction trading processes, and pause, freeze, or even stop the logical function from running.

What is DoS?

DoS is the abbreviation of Denial of Service, which can be explained as the service request sent by the users cannot be processed by the system.

If we use an analogy to explain it, you can imagine the system as a train station. If someone tries to DoS that station, there are a lot of ways of realizing it. For instance, occupy the hallway without moving onto the train, block the ticket sale windows without paying, harass the stewards and drivers to stop the train from moving, or even destroy the rails. These actions will all interfere the normally functioning of the station.

In the past Internet age, there are also a lot of ways of creating DoS, but they can be included into 3 categories:

1. Exploiting the flaws of software realization

2. Exploiting the bugs in protocals

3. Using resource advantages to suppress.

Besides, there is DDoS, as Decentralized DoS, the difference of it is that attacker uses remotely controlled computers instead of just one to initiate attacks simultaneously. In the analogy above, we can liken it to a gang doing the same things instead just one person.

The Principle Analysis and Vulnerability Fix-up of Smart Contract DoS Attack

DoS happens everywhere, of course it has threats to Ethereum which is based on new language — Solidity.

There are 3 measures to implement DoS attack aiming at smart contracts which belong to the type of exploiting bugs in protocol. The purpose is to create an effect of making the contract fail to run in a certain period or permanently. By using DoS attack, the tokens could be locked in contract forever, which turns the block to a frozen waste.

1.Using Unexpected Revert to initiate DoS

If the change-of-state of smart contract relies on the execution result of external functions, and the contract didn’t have precautions against execution failure situations, then this contract is under the threat of DoS attack.

Now we use a case to replicate the mechanism of KotET, and analyze accordingly:

The case above is a simplified KotET competition mechanism, if the ether amount carried by the current transaction is higher than the variable highestBid, then the ether amount of highestBid will be returned to the address of currentLeader, and the competitor will become the new currentLeader, which will also be changed to variable msg.value. But when vicious attacker deploy contract as follows, and compete through the original contract, problems will show up:

First, attacker transfers certain amount of tokens into the original amount through the attack contract to become the currenLeader, then the new bidder transfers and compete, but the first function will execute until require(currentLeader.send(highestBid)) and return false because the fallback() function in the attack contract (here it refers to ‘function() external payable’) cannot receive ether. Finally, the attack contract will win the bid with low ether amount payed.

Vulnerability Fix-up

If the original contract needs the processing of the result from calling external function to get to the new state, please consider the possibility of constant failure, or add the operation based on time, to avoid the situation of external function cannot fit the ‘require’ conditions.

After analyzing the incident of GovernMental, we consider it as initiating DoS using gas limit.

2.Initiate DoS attack using Gas Limit of the block

Transferring to a lot of addresses at once will probably cause exceeding the gas limit of Ethereum block. Ethereum limited the gas spent in one block, if overspent, then all transaction will fail.

Even there is no vicious attack, this could lead to other problems. But the worst thing is that the spending is controlled by the attacker. In the case above, if the attacker adds more addresses to the receivers list, and set that each of those addresses receives small amount of refund. Then more gas will be spent and the gas limit will be exceeded, all transactions will fail. For instance, please refer to the follow contract:

This contract loop over an array called ‘inverstor[]’ which could be manipulated by others. Attacker could create a lot of accounts to make investor[] array extremely large, so that the execution of ‘for’ cycle spending gas over the gas limit. The result of this is that distribute function will stay in out-of-gas (OOG) status, instead of successfully executed, hence the negative influence on contract functions.

Vulnerability Fix-up

Contract should not cycle the batch operation on manipulable data structure. Recommend using retrieve mode instead of send mode so that every investor can use withdrawFunds to retrieve deserved tokens.

If you have to loop over a variable length array to realize the transfer function, you’d better estimate the number of blocks and transactions to complete them. Plus, you will have to be able to track the steps of process so as to recover from the failed step, for instance:

3.Operations on owner cause DoS

We mentioned about the issue of owner access being unlimited, or you can say ‘super centralized’. Currently, a lost of token contracts contain an owner account, which has the access to start/pause transactions. If this account is not protected well enough, token contract will probably be frozen, leading to a non-subjective DoS. We use the following code as an example:

The limitation of this owner access is that if privileged user loses private key and become inactive after ICO, owner will not be able to call finalize() function. That results in user sending token becoming impossible. Thus, we can say that all operations in this token ecosystem is depended on a single address.

Vulnerability Fix-up

Recommend setting multiple addresses with owner access, or setting the time limit of pausing transactions. If the time limit is over, the transactions can be resumed. For example: require(msg.sender == owner || now > unlockTime)

Mistakes and just change, forever is not too late

1. Carefully consider the code about calling external functions, add exception validation into the code.

2. Estimate and think over the method of transferring by looping through variable length arrays. The contract should not contain manipulable part.

3. Decentralization should also be applied to owner access.

From DoS to trading system break down, to project being frozen and forgotten by the public, the projects we talked about today have suffered from the same as those in the early age of Internet development. However, if we can learn from mistakes, the development of blockchain can be steadier and faster.

References:

1. Post-Mortem Investigation https://www.kingoftheether.com/postmortem.html

2. A survey of attacks on Ethereum smart contract https://eprint.iacr.org/2016/1007.pdf

3. https://blog.sigmaprime.io/solidity-security.html#dos

4. (Unexpected)Throw initiated DoS

5. Block GasLimit inititaed DoS

About Chengdu LianAn Technology

Chengdu LianAn Technology Co. Ltd. is headquartered in Chengdu and focuses on blockchain security field. Founded by Prof. Xia Yang and Prof. Wensheng Guo of UESTC, LianAn Tech’s core team members consist of more than 30 associate professors, postdoctoral students, doctors and masters with experience of studying at overseas leading universities and laboratories (CSDS, Yale, and UCLA) as well as industry elite from Alibaba Huawei, and other famous enterprises. Using formal verification as its core technology, this team has been providing years of services for security critical systems in aerospace, military and other fields. Chengdu LianAn Technology Co. Ltd. is the one and only company in China that applies this technology to blockchain security field.

As the only blockchain security company obtained strategic equity investment from Fenbushi Capital, Chengdu LianAn Technology has signed strategic partnership agreements with well-known corporations such as Huobi, OKEX, LBank, CoinBene, Kucoin, CoinMex, Becent, JBEX, ONT, Scry, CareerOn, loTeX, DALICHAIN, Bytom, Bubi Blockchain, YUNPHANT, and BiXiaoBai. In addition, it has built partnership with Inria France, the top formal verification team in the world. LianAn Technology is on the “2018 China Blockchain Industry White Paper” issued by the Ministry of Industry and Information Technology and has also been selected for the smart contract security audit recommendation list on Etherscan.

--

--

BEOSIN

Blockchian Security · IDE · Beosin-VaaS · Formal Verification · SAS | China leading enterprise in blockchain security field