Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what are the methods of block chain to achieve public chain double flower attack". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

1 proof of workload and Shuanghua attack

In 2008, Satoshi Nakamoto proposed an electronic cash system implemented entirely through peer-to-peer technology, which allows online payments to be initiated directly by one party and paid to the other without going through any financial institutions. Although digital signatures partially solve this problem, the system loses its value if third-party support is still needed to prevent double payments. The essence of Bitcoin's workload proof mechanism (PoW) is to make the cash system run in a peer-to-peer environment and prevent double-flower attacks.

The principle of the workload proof mechanism is as follows: each block in the network contains the transaction in the current network and the block header hash of the previous block. When a new block is generated, its block hash must meet the proof condition of workload (a large number of hash calculations are required). The whole network connects the hash chain that satisfies the proof of workload to form a block chain. Unless the attacker re-completes the full proof of workload, the resulting transaction record will not be changed. The longest blockchain will be seen not only as proof of the observed trading sequence, but also as a consensus from the most powerful groups. As long as most of the computing power in the whole network does not intend to cooperate to attack the whole network, then the honest node will generate the longest chain that exceeds the attacker, thus realizing the resistance to the double flower attack.

The Shuanghua attack is actually a result. If an attacker A pays both B and C users with the same bitcoin, and both B and C users approve the transaction. So we say that A spent the bitcoin twice, and An implemented a double-flower attack. Among the two-flower attacks against the workload proof mechanism, 51% attack is the most discussed form of attack. However, the double-flower attack against the workload proof mechanism actually has many forms, including Fanny attack, competitive attack, Vector76 attack and so on. In fact, these attacks have been fully concerned and discussed, and I will not repeat them in this article. In fact, there are many other forms of practical digital currency attacks. In the following, we will discuss the causes of multiple digital currency double-flower attacks through a number of security vulnerabilities we have found, and propose an efficient mitigation measure.

2 A new classification of Shuanghua attacks

Intelligent contract platform, in essence, is to share a ledger in the whole network. This can be seen as a distributed state machine replication problem. The current ledger status, we can think of as State_n. When a new transaction Tx_ is generated, Tx_ will have an effect on State_n. Thus, the State_n state is transitioned to the State_ state. This process can be expressed in a formula:

State_n × Tx_ {nasty 1} → State_ {nasty 1}

The intelligent contract platform consensus mechanism, in essence, is to Tx_1 Tx_2 all transactions. . Tx_n] acts on the initial State_0 sequentially, making the whole network always in the same state. Each block in the blockchain actually transacts the transaction sequence [Tx_1 Tx_2... . Tx_n] split into different chunks Block1,Block2 sequentially and link them sequentially. In the process of state machine replication of the whole network, if the state of the whole network is inconsistent for some reason, we can think that there is a bifurcation in the whole network. The bifurcation is used by the attacker to further realize the double flower attack.

In this article, we classify these two-flower attacks we found into three categories:

Double flower attack caused by loose verification.

A two-flower attack caused by inconsistent execution of the state machine State_n × Tx_ {naugh1} → State_ {naugh1}.

The double flower attack caused by the consensus mechanism.

The main reason for the double-flower attack caused by loose verification is the concrete implementation of logic check. The Bitcoin loophole CVE-2018-17144 is actually such a loophole.

The double-flower attack caused by inconsistent execution of the state machine is mainly due to the inconsistency of direct results caused by the intelligent contract virtual machine due to various reasons, thus creating bifurcations in the whole network, resulting in double-flower attack.

The vulnerability of consensus mechanism may lead to bifurcation of the whole network, which can further lead to double-flower attack. The so-called 51% attack is actually a bifurcation loophole in the PoW consensus mechanism.

3Shuanhua attack caused by lax verification

The main reason for the double-flower attack caused by loose verification is the concrete implementation of logic check. Here we introduce two loopholes about the lack of strict timing check between chunks and transactions, resulting in double-flower attacks.

In a blockchain project, the way in which a transaction Tx_1 is packaged in a block Block_1 is as follows: first calculate the hash value Hash_1 of the transaction Tx_1, and then use the Hash_1 hash value Hash_2 with other transactions. The combination of Hash_n forms Merkle Hash Tree. Calculate the root node root of the hash tree, and then package the root into Block_1. This forms the binding of a transaction to the block. Generally speaking, unless an attacker can break the collision resistance of a hash function, he cannot break the binding of a transaction to a block. If the attacker can package the binding between the transaction and the block, the attacker can realize the double flower attack by causing the bifurcation of the whole network. Here are two double-flower vulnerabilities we found on NEO:

3.1 NEO virtual machine GetInvocationScript Shuanghua attack vulnerability:

In a blockchain project, a transaction usually consists of an unsigned part (UnsignedTx, the content of the transaction to be executed) and a signed part (the witness of the transaction). In blockchain projects such as Bitcoin, the hash calculation of a transaction actually includes the signed part of the transaction. However, in many blockchain platforms such as NEO and ONT, the calculation formula of transaction is hash=SHA256 (UnsignedTx). That is, the hash of the transaction is calculated from the unsigned part and has nothing to do with the witness of the transaction. When the NEO intelligent contract is executed, the witnesses of the transaction can be obtained from a transaction through the Transaction_GetWitnesses method. The specific implementation is as follows:

After a contract transaction obtains its own witness, you can also obtain the validation script in that witness through the Witness_GetVerificationScript method. If an attacker targets the same unsigned transaction UnsignedTx1, two different verification scripts can be constructed. It can cause inconsistency in the execution of the contract. Normally, the VerificationScript of a contract is determined by information such as the input of the contract, and the attacker cannot construct different verification scripts and pass the verification. But we found that in the VerifyWitness method, when VerificationScript.length=0, the system calls EmitAppCall to execute the target script hash.

So when VerificationScript=0, or VerificationScript is equal to the target script, the witness verification condition can be met. That is, an attacker can construct two different VerificationScript for the same unsigned transaction UnsignedTx_1. An attacker can use this property to attack all token assets on a NEO smart contract. The specific attack scenarios are as follows:

Step 1: the attacker constructs an intelligent contract transaction Tx_1 (unsigned content UnsignedTx_1, verification script is VerficationScript_1). In the execution of the UnsignedTx_1 contract, the contract determines whether its VerficationScript is VerficationScript_1. If VerficationScript_1, send tokens to A user. If VerficationScript is empty, a token is sent to user B.

Step 2:Tx_1 is packaged into block Block_1.

Step 3: after receiving the Block_1, the attacker replaces Tx_1 with Tx_2 (Tx_1 has the same unsigned content UnsignedTx_1 as Tx_1, but verifies that the script is empty) to form Block_2. The attacker sends Block_1 to user An and Block_2 to user B.

Step 4: when user A receives the Block_1, he finds himself receiving the token sent by the attacker. When user B receives the Block_2, he or she will also find that he has received the token sent by the attacker. Shuanghua attack complete.

It can be seen that the threshold for exploitation of this vulnerability is very low, and it can be used to attack all token assets on NEO smart contracts. The harm is very serious.

3.2 NEO MerlkeTree binding Bypass creates a transaction Shuanhua attack vulnerability:

The binding of intelligent contract transactions to blocks is usually done through MerkleTree. If the attacker can bypass the binding, he can achieve a double flower for any transaction. Let's take a look at the MerkleTree implementation of NEO as follows:

In the MerkleTreeNode function, NEO calculates the MerkleTree leaf node to the parent node. But there is a problem here, when leaves.length is odd n. The MerkleTree of NEO will copy the last leaf node once and add it to the calculation of MerkleTree. That is, when n is odd, the MerkleRoot values of the following two sets of transactions are equal:

[Tx_1 Tx_2. Tx_n]

[Tx_1 Tx_2. Tx_n Tx_] where Tx_= Tx_n

With this feature, an attacker can implement a two-flower attack on any NEO asset. The specific attack scenarios are as follows:

Step 1: assume a normal legal Block_1 with a transaction list of [Tx_1 Tx_2 … Tx_n] . After receiving the Block_1, the attacker replaces the transaction list with [Tx_1 Tx_2 … Tx_n Tx_] to form Block_2. Then publish the Block_2 to the network.

Step 2: after an ordinary node receives the Block_2, it will verify the validity of the Block_2. However, because of [Tx_1 Tx_2... Tx_n Tx_] and [Tx_1 Tx_2... Tx_n] has the same MerkleRoot. Therefore, Block_2 can pass the verification of block validity and enter the process of block persistence. NEO locally cancels the verification of transactions in legitimate blocks by ordinary nodes (trusting several consensus nodes). Then the Tx_n transaction can be executed twice by the ordinary node, and the Shuanghua attack is executed successfully.

It can be seen that the threshold for exploitation of this vulnerability is very low, and it can be used to attack all assets on NEO. The harm is very serious.

4 inconsistent execution of virtual machines

The intelligent contract platform consensus mechanism, in essence, is to Tx_1 Tx_2 all transactions. . Tx_n] acts on the initial State_0 sequentially, making the whole network always in the same state. In the process of state machine replication, we require State_n × Tx_ è State _ to be decisive. State_n × Tx_ è State _ is essentially the execution process of the intelligent contract virtual machine to the Tx_. If there is a design or implementation loophole in the intelligent contract virtual machine, the virtual machine executes inconsistently (inconsistent State_ for the same input State_n and Tx_, output). Then the attacker can take advantage of this problem to generate bifurcations and carry out double-flower attacks in the network. Let's take a look at several virtual machine inconsistent execution vulnerabilities we found on EOS and NEO and their causes.

4.1 EOS virtual machine memory corruption RCE vulnerability:

Earlier, we released the article "EOS Node Remote Code Execution Vulnerability-EOS WASM Contract Function Table Array Out of Bound" (http://blogs.360.cn/post/eos-node-remote-code-execution-vulnerability.html)). In this paper, we found a memory out-of-bounds write vulnerability of an EOS WASM virtual machine. The program we wrote for this vulnerability can successfully make the EOS virtual machine execute arbitrary instructions, thus completely controlling all the outgoing blocks and authentication nodes of the EOS.

In essence, it is in the process of State_n × Tx_ {nasty 1} → State_ {nasty 1}. If the attacker can make the EOS virtual machine completely off the original execution path and execute arbitrary instructions, the two-flower attack can be completed naturally. The attack process is as follows:

Step 1: the attacker constructs a malicious intelligent contract that implements RCE and publishes the contract to the EOS network.

After the step 2:EOS super node parses to the contract, it triggers a vulnerability and executes arbitrary instructions customized by the attacker.

Step 3: the attacker implements the double flower attack.

The vulnerability is very serious, and it is the first time that an intelligent contract platform has been attacked by remote code execution. Readers can read this article to learn the relevant details, and I will not repeat them here.

4.2 the uninitialized memory of the EOS virtual machine results in a double flower attack:

In the process of writing the exploit program of "EOS Node Remote Code Execution Vulnerability-EOS WASM Contract Function Table Array Out of Bound", we also exploited an undisclosed memory uninitialization vulnerability in EOS at that time. In memory corruption attacks, memory uninitialization vulnerabilities can usually cause further problems such as information leakage and type confusion, which helps us to bypass the mitigation measures of modern binary programs such as ASLR and further realize the attack. However, in the intelligent contract virtual machine, the memory uninitialized vulnerability has a more direct way to exploit, which can directly cause double-flower attack. Here are the details of an uninitialized memory vulnerability that we exploited in EOS RCE, which can be used to directly implement the EOS smart contract token asset Shuanhua attack.

When the WASM virtual machine uses grow_memory pseudocode to request new memory. In the initial implementation of EOS WASM grow_memory, the requested memory was not zeroed. The space in this block of memory is actually random (depending on the memory state of the contract execution machine). Then the attacker can construct a malicious contract to realize the double-flower attack on any contract asset on EOS. The attack process is as follows:

Step 1: the attacker constructs a malicious intelligent contract. In the contract, a new memory address is obtained through grow_memory.

Step 2: read some bit content in this address in the contract (at this time the bit may be 0 or 1, depending on the status of the contract execution machine).

Step 3: the contract judges the content of the bit. If it is 1, the token is sent to the A user, and if it is 0, the token is sent to the B user, so as to realize the double flower attack.

4.3 EOS virtual machine memory out-of-bounds reading results in double-flower attack:

In the traditional memory corruption, memory out-of-bounds reading vulnerabilities will mainly lead to information leakage, which will help us to bypass the mitigation measures of modern binary programs such as ASLR, and further implement attacks together with other vulnerabilities. However, in the intelligent contract virtual machine, the memory out-of-bounds read vulnerability can be exploited more directly, which can directly cause double-flower attack. The following is an EOS memory out-of-bounds read vulnerability we found, which we can use to implement a double-flower attack.

When EOS WASM translates an offset into an internal WASM memory address, the boundary check process is as follows:

Here the type of | ptr | is actually an I32 type, which can be a negative number. So when:

-sizeof (T) < ptr < 0

Ptr+sizeof (T) is a small number that can pass the boundary check. In the following addressing, we see the code:

T & base = (T) (getMemoryBaseAddress (mem) + ptr)

| the address of base | will exceed the memory base address of WASM, thus enabling the intelligent contract to achieve memory out-of-bounds reading (the content of the memory address read depends on the current execution status of the virtual machine and can be considered random). An attacker can take advantage of this vulnerability to implement a double flower attack. The attack process is as follows:

Step 1: the attacker constructs a malicious intelligent contract. The contract takes advantage of the memory out-of-bounds read vulnerability to read a bit beyond the WASM memory base.) at this point, the bit may be 0 or 1, depending on the status of the contract execution machine.

Step 2: the contract judges the content of the bit. If it is 1, the token is sent to the A user, and if it is 0, the token is sent to the B user, thus the double flower attack is realized.

4.4 inconsistent implementation of standard functions results in double-flower attack:

To sum up the essence of the above two examples of Shuanghua attack, in fact, the EOS contract reads random variables due to some memory vulnerabilities during execution, thus breaking the consistency of the original virtual machine execution, resulting in Shuanghua attack. In fact, the inconsistency of contract execution does not necessarily depend entirely on randomness. Here we introduce a two-flower attack caused by inconsistencies in the implementation of standard C functions on different platforms (versions).

In the C language standard definition, the return of the memcmp function is required to be less than 0, equal to 0, or greater than 0. However, in different C version implementations, the specific returns may be different (but still conform to the C standard). Attackers can take advantage of the inconsistency of the implementation of the standard, resulting in inconsistent execution results of EOS virtual machines running on different systems, and then realize the double-flower attack. The attack process is as follows:

Step 1: the attacker constructs a malicious intelligent contract, calls the memcmp function in the contract, and gets the return value.

Step 2: at this point, the return value of the Memcmp implemented by different platforms and versions is different (even if the binaries of the EOS virtual machine are the same). The malicious contract judges the return value of Memcmp and decides to transfer the money to An or B, thus completing the double flowers.

The specific fixes of this vulnerability are as follows:

EOS enforces the return value of memcmp to be converted to 0mai 1 or 1, thus resisting this inconsistent execution.

The problem of Memcmp is caused by the inconsistency of the implementation of the same standard in the same language. In fact, there are often multiple implementations of different versions of the same blockchain project.

Different languages often deviate from the implementation of the same standard. For example, one of the inconsistent implementations that we found to be caused by inconsistent standard definitions is the ECDSA function. The ECDSA signature standard requires that the private key x is not 0. For example, in several cryptographic libraries in python and JS, this standard is strictly enforced, but we find that some ECDSA libraries in golang allow private key xroom0 to be signed and verified. Malicious attackers can take advantage of this problem to execute malicious contracts inconsistently on different versions of the same blockchain platform (such as golang implementation and python implementation), thus further completing the double-flower attack.

Inconsistency in implementation of version 4.5 results in Shuanhua attack:

The same blockchain project often has multiple implementations of different versions of programming languages. The implementation of different programming languages also has the possibility of inconsistent execution. The above ECDSA is an example. Large integer operations are also a common example. For example, in the previous NEO C # version implementation and python version implementation, large integer (BigInteger) division operation can lead to inconsistent execution in different programming language implementation versions, resulting in double-flower attacks. A similar phenomenon has occurred in multiple blockchain projects.

4.6 other issues inconsistency issues

System time, random number, floating-point calculation and other factors can also cause inconsistent execution of virtual machines. However, in our audit, we did not find such vulnerabilities in the Dagong chain project. Most blockchain projects take into account these obvious possible problems at the beginning of their design.

But the factors that may cause inconsistent implementation may far outweigh the problems we have found above. In fact, some subjective factors (depending on the current running state of the machine, which we call subjective factors) may cause inconsistent execution of the virtual machine. For example, in 4G memory, machines with 8G memory have different subjective boundaries of memory overflow (OOM) during execution, and attackers may use OOM to cause inconsistent execution of virtual machines.

5 double flower attack caused by consensus mechanism

The double-flower attack caused by the consensus mechanism is actually a problem that has been fully discussed in the industry. however, various common chain schemes may still have bifurcation problems in the implementation of the consensus mechanism, resulting in double-flower attacks.

5.1 ONT vBFT VRF random number bypass vulnerability

Long range attack is a bifurcation attack method faced by all PoS consensus mechanisms at present. The attacker can choose not to fork the existing chain, but actually return to the chain state of a long time ago (where the attacker had a lot of money) and create a longer new chain to mistake the network for the main chain, thus completing the double flowers. At present, there is no fundamental solution to Long range attack in the industry, and it can only be guaranteed to prevent bifurcation if "Weak Subjectivity" does not occur.

ONT's vBFT consensus algorithm proposes a method to prevent malicious bifurcation expansion by relying on verifiable random functions (VRF). First of all, the network selects the alternative block proposal node set, the block verification node set and the block confirmation node set in turn based on VRF in the consensus network, and then completes the consensus by the selected node set. Since each block is prioritized by VRF, it is difficult for an attacker to maintain a high priority for malicious bifurcations (if the attacker does not control the vast majority of shares), so malicious bifurcations will die out quickly, making vBFT have fast state finality.

However, we find that there is a vulnerability in the implementation of VRF in vBFT, which causes users with a private key of 0 to generate the same vrfValue for any chunk of data. Specifically, vrf in vBFT is an implementation of the draft VRF standard (https://hdl.handle.net/2144/29225)) proposed by Boston University. Specifically in chapters 5.1 and 5.2 of the draft, we can see the algorithms for proof generation and random number calculation. As shown in the figure:

The flaw lies in the fact that y is still a valid public key computationally and can be verified by ValidatePublicKey in the vBFT implementation. Gamma is a fixed point (infinity) on an elliptic curve. That is, for any input alpha, the vrf produces a fixed value. There is no randomness at all. This problem can cause attackers to use fixed vrf to break the randomness of consensus algorithm, so as to control node election for a long time.

5.2 NEO dBFT consensus bifurcation

NEO's dBFT consensus mechanism can be regarded as a POS+pBFT scheme in essence. In the original NEO code, we found that NEO and ONT have bifurcation problems when implementing their dBFT consensus mechanism. A malicious consensus node can produce a bifurcation block, resulting in the occurrence of double flowers. For details, please refer to our previous article: "Analysis and Improvement of NEO's dBFT Consensus Mechanism" (http://blogs.360.cn/post/NEO_dBFT_en.html)), which we will not repeat here.

6 an efficient mitigation measure for the implementation of inconsistent double flowers in virtual machines

For logic loopholes such as verification bypass and consensus mechanism loopholes, we still need to go deep into the specific analysis of specific problems in business logic. Here we propose an inconsistent mitigation measure for virtual machines.

A simple way to solve the problem of double flowers caused by inconsistent execution of virtual machines is for the chunk to hash the global status State_ after running the transaction, and then package the hash into a block. After receiving the block, the ordinary node compares the hash of the status State'_ after running the transaction locally with the hash of State_. If equal, no bifurcation occurs. However, because the local data grows in advance, it is very expensive to hash the global state each time. To solve this problem, Etay Fong uses the structure of MekleTree to improve performance and deal with the problem of bifurcation rollback. However, the Etay Fong scheme is not suitable for block chain projects that use other data structures to store state information. Here we propose a new solution, and its workflow is as follows:

During the block packing phase, the block producer will write the sequence of write operations to the database during the operation of all the transactions in the block [write_db_1 write_db_2 … . Write_db_n] record and calculate the hash value write_db_hash of the sequence.

After the ordinary node receives the new block, it verifies the block. The transaction is then performed in the virtual machine. At the same time, record the sequence of write operations of these transactions to the database locally [write_db_1' write_db_2' … . Write_db_n'], and then calculate the write_db_hash'. Determine whether it is equal to write_db_hash. If equal, no inconsistent execution occurs. If not, commit the write operation sequence is refused.

The core idea of this method is that the reason for the inconsistent execution of the virtual machine of the intelligent contract platform is that a variety of uncertain factors may be introduced into the support of various functions and Turing completeness in the contract, resulting in inconsistent execution. A variety of complex small reasons may cause such inconsistent enforcement to be difficult to prevent. But if we take a step back, the essence of the Shuanghua attack is to modify the global state State_, which is essentially a series of simple write operations (simple write operations often do not produce ambiguity). To prevent double flowers, you only need to match and check all the write operation sequences. The overhead of matching and recording these writes locally is very small, and recording these write sequences locally is also convenient to deal with other factors such as bifurcation rollback.

This is the end of the content of "what are the methods of block chain to achieve public chain double flower attack". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.