Dry Goods | "False Rights" Attack on Chain Structured PoS Systems (Part-2)

Dry goods | "false rights" attack on chain structured PoS systems, Part-1

Vulnerability 2 and Equity Reuse Attack

By tracking the historical versions of these codebases, we noticed that Vulnerability 1 was originally introduced when the Bitcoin's "block header first" feature was incorporated into the PoSv3 codebase. Earlier versions of cryptocurrency (eg, peercoin) did not have vulnerability 1 because there were two preliminary validations before storing the chunks on the hard drive:

1. Verify that the output to be spent exists in the main chain;
2. Verify that the kernel hash of the PoS block meets the difficulty target.

The first verification is done by looking up the transaction database (TxDB). This database holds all transactions on the current main chain. In other words, the initial verification does have some effect, but it is still not complete and rigorous compared to full verification. If you follow the ideas of this article, you may immediately find two problems:

Question A: The first verification only ensures that the currency is present, but there is no guarantee that its corresponding UTXO has not been spent. This led to the vulnerability we will discuss next.

Question B: Even if we verify the block on a forked chain, the coinstake transaction in this block is verified based on the TxDB of the main chain.

• April 7th market analysis: the big direction is right, to be firm, otherwise it is easy to be smashed by the market
• Why can't the rude "game chain" not work? And how to design it?
• EOS hits high and BTC once again challenges 5200 points still strong

Based on question A, we have found a way to deceive these verifications by using a more subtle attack, which we call an " equity reuse attack ." In order to bypass the first validation, we will use a spent output to impersonate the node without spending the output. Usually, in order to bypass the second verification, we need to dig out an effective block to reach the difficulty goal, which requires a large investment. However, it turns out that we can generate any number of apparent stakes by abusing incomplete verification. We call this technology " energy amplification ."

Equity enlargement

In order to use a small amount of equity to achieve the purpose of the attack, the attacker must amplify his apparent weight. Apparent equity refers to the total amount of all alternative equity output, including the equity that has been spent. Suppose an attacker initially has a k- dollar UTXO, and he can initiate multiple transactions sent to himself (causing an illusion of an increase in his or her own equity), as shown in the following figure. Originally, only UTXO* (n+1) * can be counted as equity, but according to verification 2 above, UTXO from 1 to n+1 can be included in the equity, thereby increasing the apparent equity to n* k . Since the attacker can always increase the apparent equity in this way, it increases the chance that he will dig into the PoS block. “ Steps for enlarging the equity ” See the figure on the left.

-Equity amplification and equity reuse attacks –

Assuming that the attacker owns only 0.01% of the total system, he only needs to send these rights to himself and again through the transaction. After 5000 times, he can get 50% of the apparent equity calculation power to dig the block. After the attacker accumulates a large amount of apparent rights, they can use these apparent equity outputs to re-dig the PoS block from a point in time in the past. Finally, as shown on the right, the hard disk of the attacked node will be filled with invalid blocks. For example, an attacker can purchase some tokens from the exchange, amplify their apparent rights through the above-mentioned self-transaction, and then re-sell the tokens on the exchange, and then attack at any time. For an attacker, the cost of attack is simply a transaction fee.

Collaborative vulnerability disclosure

We first investigated the case of vulnerability 1 <1> for cryptographic currencies Particl and Qtum. To understand the extent of the vulnerability, we screened some well-known PoS cryptographic currencies from the website of coinmarketcap.com (as of August 9, 2018) and sequenced a list based on market capitalization. We only looked at cryptocurrencies that were forked out of the C++ codebase of bitcoin (or cryptocurrency derived from bitcoin). We reviewed a total of 26 cryptocurrencies, of which only 5 (Qtum, Navcoin, HTMLcoin, Emercoin, and Particl) have vulnerabilities1 and the remaining 21 seem to be unaffected by the attack. In order to confirm the vulnerability of Vulnerability 1, we attacked the five cryptocurrencies. We leveraged Bitcoin's existing test components, specifically regtest tests that support simulated timestamps and quick builds, and a test node written in Python (based on the Bitcoin test framework) that can be attacked by an attacker. The behavior is extended. As part of the vulnerability disclosure, we used the Docker container engine to package the hashes of these tests, their dependencies, and specific commits into a reproducible toolkit for sharing with the development team of the relevant cryptographic currency.

We further dig deeper into the reasons why the rest of the cryptocurrency can defend against the vulnerability 1 attack, and found the same serious and more common vulnerability 2 (only a small amount of interest). In the process of preparing to disclose these two vulnerabilities, we consider that some cryptographic currency liquidity is not strong, and the development team is less active. Disclosing these vulnerabilities to them may be counterproductive (one of the risks is if there is a loophole) The matter is leaked and may cause user losses before the relevant development team deploys the solution). In the end, we selected the 15 cryptocurrencies that were most likely to be attacked and the team's most responsive (committed in 2018), and their development (from the top 200 cryptocurrencies) The team communicated.

One of the more complicated factors is that most teams' code bases don't use the regtest test mode, so it's hard to show them the attack method or provide a reproducible toolkit for each cryptocurrency. Therefore, we can only demonstrate <7> through a C++ version of the stratisX codebase. Based on the similarity of the code base, we informed the above 15 development teams about the vulnerability. Five of the teams confirmed the existence of the vulnerability, three teams are still investigating, three teams believe that the vulnerability has little impact (and pointed out that some procedural changes can resist its impact), and four teams have not yet responded. For those 4 non-responding teams, we contacted <5> <6> through the channels available on their website. We've provided the Github Reproducible Toolkit for two vulnerabilities here, here is a small paper on Vulnerability 1. We also kept the vulnerability on the CVE and will announce it in the near future.

solution

We have seen some teams have taken some measures to address these vulnerabilities. Some cryptocurrency teams have taken measures to monitor such attacks and disconnect them from the attacking node <2>. Simply put, the node monitors the anomalous behavior of other nodes (for example, sending a large number of block headers to the forked chain). The problem with this approach is that it is difficult to distinguish between true aggression and legal reorganization of honest nodes—the risk of forbidden honest nodes. As of the current situation, we believe that such solutions are reasonable, but further investigation is needed.

The other cryptocurrency team's approach is to add a partial verification mechanism that triggers this mechanism every time a certain number of blocks are accumulated, so that the previous blockchain at the trigger point no longer accepts the forked block <3>. If the node receives a forked block that is too long (that is, it is older than the latest trigger point), the node will not recognize it and will only discard it. For example, the BBC (Bitcoin Cash) ABC code library uses this method to set up a rolling checkpoint with a depth of 10 blocks. The disadvantage of this method is that it creates the possibility of "chain splitting". "Chain splitting" refers to the fact that honest nodes are scattered on different bifurcation chains of the main chain. For example, in a poor network environment, nodes are not synchronized for a long time, resulting in conflicting checkpoints. Even if the node is back online, there is no way to reach a consensus on this chain. We have noticed that even without this approach, the problem of chain splitting exists. Going back to question B above, since the coinstake transaction is validated based on the transaction output on the current main chain, if a node suddenly finds itself on a forked chain, it may not be able to switch to the real main chain.

The risk of chain splitting has also created new attacks for malicious miners. An attacker can secretly dig a long chain and broadcast it to a subset of nodes, causing the chain to split. A node in the IBD (Initial Block Synchronization) state or a node that is resynchronized after a long time offline is particularly vulnerable to such an attack. This type of attack can be combined with an eclipse attack to introduce honest nodes into a forked chain controlled by an attacker.

All of these solutions are effective against false equity attacks, but they are still not a substitute for full verification. Some cryptographic currency plans, including Qtum, are fully validated in future versions of non-backbone blocks.

We recommend that all users of these cryptocurrency vulnerabilities upgrade their own node software and patch them with the latest patches. Unupgraded nodes may be attacked, RAM or disk resources are consumed too much, and eventually the program crashes.

Final feelings

Although the “false equity” attack is simple in nature, it highlights the difficulty of design: diverting some of the ideas that apply to the proof of work to the proof of equity raises security issues. Given that the code in the PoSv3 cryptographic currency is highly coincident with Bitcoin Core, we believe that code checking should be taken more seriously. In investigating these vulnerabilities, we found some solutions and targeted defenses in different project codebases <4> (or some of the commented out code). We believe that this indicates that developers of current PoS projects have realized that they have insufficient consideration of trade-offs and requirements in the design process. The difficulty is that, on the one hand, we want to defend against ineffective block attacks as quickly as possible, but on the other hand, we don't want chain splitting or delays. In future research, we still have to think about how to find a systematic solution.

Although we have seen at least two code bases being affected (for example, CVE 2018–17144 in BTC), as far as we know, the number of cryptocurrencies involved in this collaborative security vulnerability disclosure is (20+), Absolutely unprecedented. Considering the design of these cryptocurrencies and the high degree of codebase overlap, we expect to find more such vulnerabilities in the future. We also found that these code bases have almost no uniform security handling. For example, most teams do not have a dedicated security contact. Disclosure of collaborative vulnerability like ours is a best practice and beneficial to the entire ecosystem.

Note 1: The idea behind this vulnerability began in the summer of 2018, when Andrew Miller was still working with Unit-E developers. Thanks to Matteo Sumberaz and Gil Danziger for their instructive discussions and the bonuses offered by the DTR Foundation.

Note 2: A heuristic node discovery method implemented by Emercoin https://github.com/emercoin/emercoin/commit/ec32762b99cc68fb9abb2909dda96bc7a13bd819

Note 3: The rolling checkpoint in Qtum https://github.com/qtumproject/qtum/commit/8d208d0bee8449c1e4a3904ff3fc97ed26156648

Note 4: Ad-hoc check case in a PoS: https://github.com/peercoin/peercoin/blob/ebb4003ce8367501020181f7e734d52c4b1ab5ea/src/main.cpp#L2564

Note 5: We contacted some teams via email and the "send memo" function.

Note 6: We have contacted the PIVX team several times through the contact function on the webpage since November. It was not until we wrote this article that the PIVX team launched a hackerone project. And we also found that until today, the bug reward page on the PIVX page did not list the hackerone project.

Note 7: Note 7: StratisX has migrated from a vulnerable C++ codebase to a C# implementation.

Original link: https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806

Author: Decentralized Systems Lab

Translation & Proofreading: TrumanW, Whisker & Min Min

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