Blockchain Security Science: Witch Attack

As more and more people participate in the blockchain industry, the new vitality of the industry, as well as the lack of relevant knowledge and lack of security awareness, gives attackers more opportunities. In the face of frequent security incidents, Slow Fog has launched a blockchain security entry notes series to introduce blockchain security related terms, so that novices can quickly adapt to the security of the blockchain crisis.

Series review:

Blockchain Security Getting Started Notes (1) | Slow Mist Science

Blockchain Security Getting Started Notes (2) | Slow Mist Science

Blockchain Security Getting Started Notes (3) | Slow Mist Science

• Cross-border dialogue | How do Haier, Fast, Sany, Changhong and other well-known companies view the digital economy?
• Bank of England Governor: Libra-like digital currency will be the best option to replace the dollar system
• The undead black swan: from ICO to IEO

Blockchain Security Getting Started Notes (4) | Slow Mist Science

Blockchain Security Getting Started Notes (5) | Slow Mist Science

Blockchain Security Getting Started Notes (6) | Slow Mist Science

 

Override access attack

Exceed Authority Access Attack

As with the definition of traditional security, an override refers to an operation that accesses or executes a permission that exceeds the current account. For example, some operations can only be performed by a contract administrator, but because the restrictions are not rigorous, the key operations can also be managed by the contract. Executions outside of the staff lead to unpredictable risks, and such attacks have occurred many times on Ethereum and EOS.

Take the well-known BetDice game on EOS as an example. Because the routing in the game contract (the customizable event forwarder in EOS) does not strictly check the source account, the ordinary user can access it through the push action. The key operation transfer function in the contract directly bet around the transfer process, resulting in an unauthorized attack. Although BetDice officially fixed the code and strictly restricted the source account, the vulnerability has made the attacker almost no cost. Take nearly 50,000 EOS in the BetDice prize pool. Another example is when the Ethereum uses the solidity version of 0.4.x for contract development. Many contract developers write not only the permission check but also the function visibility when writing the key functions. In this case, The default visibility of the function is public, and malicious users can attack the contract through these key functions that are not restricted.

The Slow Mist Security Team recommends that smart contract developers pay attention to the privilege check of key functions during contract development to prevent key functions from being illegally invoked and causing the contract to be attacked.

Transaction order dependent attack

Transaction-Ordering Attack

In the world of blockchains, a transaction may contain multiple different transactions, and the order in which these transactions are executed will affect the execution of the final transaction, since the transaction is not packaged in the blockchain of the mining mechanism. Before being in a pending state to be packaged, if you can know in advance which other transactions are executed in the transaction, the malicious user can initiate a transaction by increasing the amount of the miner's fee, so that one of the transactions in the transaction is packaged first. Disturbing the order of transactions, causing unintended execution results and reaching an attack. Take Ethereum as an example. If there is a Token trading platform, the fee on this platform is realized by adjusting the parameters in the contract. If the platform project party raises the transaction fee through a transaction request, the transaction is The transaction fee for all the purchase and sale tokens after the package is raised. The correct logic should be that all the Token purchase and sale transactions from the beginning of the transaction will increase, but there is a certain delay due to the transaction from being issued to being packaged. At the same time, the transaction requesting the modification of the transaction fee is not effective immediately, then the malicious user can pack his transaction first and avoid the higher handling fee at a higher handling fee.

The Slow Mist Security Team recommends that smart contract developers pay attention to the impact of the transaction order on the outcome of the contract when developing the contract, and avoid contract attacks due to different transaction sequences.

Witch attack

Sybil Attack

The rumored witch is a magical person. A person can illusion of multiple self, making the victim think that there are many people, but there is only one person. In the blockchain world, Sybil Attack is an attack against server nodes. When an attack occurs, in a certain way, a malicious node can pretend to be a plurality of nodes, issue a link request to the attacked node, and reach the maximum link request of the node, so that the node cannot accept the request of the other node, causing the node to refuse the service attack. . Taking EOS as an example, the EOS P2P node denial of service attack that the slow fog security team has disclosed is actually a kind of witch attack, and the attacker can achieve the goal of the master node with very small attack cost. For details, please refer to:

https://github.com/slowmist/papers/blob/master/EOSIO-P2P-Sybil-Attack/zh.md

The slow fog security team recommends that in the case of building a full node, the server needs to monitor the network connection at the system level. Once an IP connection is found to be abnormal, the script is configured to configure the iptables rule to block the abnormal IP, and the chain developer is working. When the public chain is developed, you should add control to the number of single IP node connections in the P2P module.

False error notification attack

Fake Onerror Notification Attack

There are various notifications on EOS. By adding the require_recipient command to the action, the specified account can be notified of the action. In some smart contracts on EOS, the onerror notification is generally performed for user experience or other reasons. Some processing. If at this time there is no check on whether the source contract of the onerror notification is eosio, the same method as the fake transfer notification can be used to attack the contract, triggering the onerror processing in the contract, resulting in the loss of the assets of the attacked contract.

The Slow Mist Security Team recommends that smart contract developers need to verify the onerror source contract when developing smart contracts to ensure that the contract account is an eosio account to prevent false error notification attacks.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!