In the 2018 Shanghai Blockchain International Week technology Open Day, slow Fog security director, One Piece King shared “DApp Army of the Undead”, standing from the perspective of attackers (especially refers to the army of the undead), through a real attack case to the ethereum, EOS and other blockchain ecosystem DApp security problems were analyzed. And throw out the relevant security depth of thinking and how to deal with.

This chart summarizes the various aspects of smart contract offense and defense, divided into two main sections: on-chain offense and off-chain offense and defense.

Chain on the offensive and defensive

For on-chain attack and defense, The Pirate King selected 5 aspects to analyze in detail. He said “Talk is cheap. Show me the code.” and began to Show the source code for detailed interpretation.

  • The overflow

Because the amount of overflow caused by not using SaceMath can be arbitrarily controlled in the data constructed by the attacker, which leads to the establishment of conditional judgment and finally the attacker successfully attacks the smart contract.

How to avoid this problem: Strictly use SafeMath to do arithmetic operations in the relevant code to prevent overflow.

  • Access control

This type of permission control is one of the permission issues where the contract developer’s unprofessional role leads to an unauthorised judgment in the proxy transfer function, which allows anyone to transfer someone else’s money.

Methods to avoid such problems: Looking for professional developers to develop contract, contract developers also need to promptly improve their development skills, and professional ability, due to the particularity of block chain to center and Token easily because of a small hole while causes project from now on, so proposal project launched before looking for a professional occupational safety audit team out of the audit report, Such problems can be found in the process of audit and help the project side to avoid this embarrassing situation.

  • Conditions of the competition

This kind of problem is caused by the multi-time malicious transfer of cross-contract invocation caused by conditional competition, and finally the attacker successfully completes the attack. There are always great problems in cross-contract invocation, because the developer’s professional skills are not professional enough or the contract design is unreasonable and other problems will lead to this kind of conditional competition.

Methods to avoid such problems: Understand the function usage scenarios of Solidity language itself and the underlying implementation, deduct the amount of the account to be deducted from the business logic before adding it to the corresponding account and clear the temporary value of the intermediate variable in time to avoid the loss caused by excessive input due to transaction problems. Also know the difference between Solidity someaddress.call.value () and someaddress.transfer () and someaddress.send (). Use someaddress.call.value () is not recommended.

  • False top-up

This kind of problem is a series, such as XRP false recharge and USDT false recharge, etc. Here we only talk about ERC20 false recharge problem. This kind of problem is due to contract developers non-standard logic code in the etheric fang blocks the browser can see was a failed state as Success exchange in prepaid phone books when no strict state judgment and amount of the check which led to such problems, these problems power is strong, And one time can make a loss of millions or tens of millions of exchanges, both developers and exchanges need to pay enough attention to the problem of fake recharge.

Methods to avoid such problems: In contract development, require() or assert() is used to judge the logic of the code. If the conditions are not met, the transfer will directly fail and the status is also FAIL. Developers of exchange wallet business need to pay attention to strictly check whether the transfer status is successful or not when they recharge. At the same time, the recharge amount is also verified to confirm that the transaction is successful.

5. Malicious events

It is important to note that the code here is only written for demonstration purposes, so far no actual attacks have been detected. Since the data of blockchain is recorded on the chain, the events that maliciously record events can directly modify the corresponding parameters. If this code really exists, the fake recharge mentioned above will really become the real recharge.

Avoid this problem: do a good Code Review and find a professional Code audit.

Chain of offensive and defensive

For chain attack and defense, one Piece king also selected 5 aspects to analyze in detail.

  1. WEB

Prior to the MyEtherWallet domain hijacking incident, the security authorities had actually warned of intermediate risks (see below), but it did not take them seriously.

End to the security of hardware wallet, there may be a variety of safety problems such as: whether to use encryption chip, industrial design is safe, do manual work is very simple can not consider loss and accidental damage and in response to low temperature high temperature under the condition of normal use, ultimately need to consider whether you bought a hardware or real hardware wallet?

  • node

Etheric lane black valentine’s day event, for example, an attacker by on the Internet by all nodes of P2P protocol discover new etheric fang, then construct good scripts to engineering in wait for the new building of all nodes to attack, because a lot of small white users don’t know how to defense against such attacks so far there are still so many teams constantly ETH was stolen

For details, see the special page of Slow Fog: 4294967296. IO /eth214/

Special introduction: mp.weixin.qq.com/s/-Yiul1QtS…

Slow fog defense: mp.weixin.qq.com/s/Kk2lsoQ16…

  • The miners

Miners could be guilty of selective packaging, targeting dApps. For the mine pool, for block withholding attack

  • The back-end

For example, the back-end attack is USDT fake recharge.

The attack steps are:

1) Construct and initiate invalid (false) transfer transactions to the exchange wallet;

2) Invalid transactions will be recorded by the exchange and recorded into the user’s fund account in the exchange due to defects in logical judgment;

3) The user initiates coin withdrawal;

4) The exchange will transfer the money to the user’s wallet address when handling the user’s withdrawal; There is no loss of USDT in the charging part of users, while in the drawing part, exchanges send their real USDT coins to users, resulting in losses of exchanges.

And the idea behind this is,

USDT is an OMNI protocol asset type based on Bitcoin block, which uses Bitcoin OP_RETURN to carry relevant transaction data.

Bitcoin itself does not verify OP_RETURN data as “legitimate”, it can be any data;

Bitcoin transactions are recognized by Bitcoin nodes when the number of blocks confirmed reaches 6;

So, how are USDT transactions confirmed on OMNI nodes?

int64_t nBalance = 
getMPbalance(sender,property, BALANCE);
Copy the code

Note: through the above code, OMNI internal has its own set of accounts based on the address model, through the address can obtain the address balance.

Therefore, in order to avoid the above problems.

A USDT transaction must satisfy at least two conditions to be legal:

(1) To be constructed through bitcoin transactions, to comply with bitcoin balance verification (BTC) and transaction rules verification

(2) To pass the USDT’s own balance (USDT) verification

For USDT fake recharge, what happens when the balance is insufficient?

{"amount": "28.59995822"."block": 502358, 
  "blockhash": "0000000000000000005968fa48c49d7c4fb2363369d59db82897853fd937c71a"."blocktime": 1514985094, 
  "confirmations": 37854, 
  "divisible": true."fee": "0.00200000"."flags": null, 
  "invalidreason": "Sender has insufficient balance"."ismine": false."positioninblock": 301, 
  "propertyid": 31."propertyname": "TetherUS"."referenceaddress": "1Po1oWkD2LmodfkBYiAktwh76vkF93LKnh"."sendingaddress": "18DmsHjHU6YM2ckFzub4pBneD8QXCXRTLR"."txid": "1b5c80f487d2bf8b69e1bbba2b1979aacb1aca7a094c00bcb9abd85f9af738ea"."type": "Simple Send"."type_int": 0."valid": false."version": 0}Copy the code

Finally, he warned that some hackers are very clever and paste the wrong code in some Baidu answers. If programmers do not check the smart contract carefully or are not familiar with the code, they are vulnerable to attack. How do you improve security? First of all, developers have a sense of security development, and secondly, we should find a professional security team to do professional audit.

This article is published by Aether Chinese network.