25 Crypto Networks Vulnerable to ‘Fake Stake’ Attack, are Your Funds at Risk?
More than two dozen Proof-of-Stake (PoS) cryptocurrency networks are vulnerable to what has been dubbed a “fake stake” attack. The vulnerability allows a node with a very small stake to overwhelm competing nodes with false data and essentially crash them. Once competing nodes are gone, the attacking node can have a majority of stake on the crypto network, enabling it to conduct a 51% attack as the only validating node.
In a Proof-of-Stake system, mining is replaced by commitment of coins. The system uses existing coins to “mint” new coins instead of hashing power. A successful attacker could inadvertently make himself the only recipient of block rewards as well as transaction fees. At a minimum, he could limit the competition pool such that he was gaining disproportionate wealth.
The Decentralized Systems Lab at University of Illinois at Urbana Champaign uncovered the attack when researching cryptocurrency codebases. All of the coins affected had begun with a Bitcoin codebase and dropped in PoS as an alternative to Bitcoin’s Proof-of-Work. Peercoin were the first to do this, and many Proof-of-Stake coins are forks of Peercoin. The researchers write:
We call the vulnerabilities we found ‘Fake Stake’ attacks. Essentially, they work because PoSv3 implementations do not adequately validate network data before committing precious resources (disk and RAM). The consequence is that an attacker without much stake (in some cases none at all) can cause a victim node to crash by filling up its disk or RAM with bogus data. We believe that all currencies based on the UTXO and longest chain Proof-of-Stake model are vulnerable to these ‘Fake Stake’ attacks.
Proof-of-Work Guards Access to Node Resources
The vulnerability exists because affected coins (including Peercoin and Qtum) “do not adequately validate network data before committing precious resources (disk and RAM).”
Back in October, the researchers began contacting affected cryptocurrencies. They weren’t able to reach all of them. Several of the affected crypto projects have introduced code that makes the attack much harder to perform. However, the researchers prefer the attack eliminated altogether, and still consider them vulnerable. They say that the increase in difficulty of the attack is not an adequate substitute for requiring full validation of data.
The post explains that Proof-of-Work (PoW) is more than just a means for competitive mining and increased security in Bitcoin:
Proof-of-Work also plays a second, somewhat less appreciated role, which is guarding access to a node’s limited resources, such as disk, bandwidth, memory, and CPU. In a permissionless cryptocurrency network, peers must not be trusted. So, to prevent against resource exhaustion attacks, Bitcoin nodes first check the PoW for any received blocks before committing more resources, such as storing the block in RAM or on disk. However, it turns out that checking a Proof-of-Stake is a lot more complicated and context-sensitive than validating a Proof-of-Work.
Difficult to Fully Validate Multiple Competing Chains
Without getting overly technical here, this reporter learned from the post that Proof-of-Stake systems must keep track of all chains in progress. Any existing chain in the network might become the longest, and the node must follow the longest. Keeping track of competing chains is difficult. As the researchers explain:
Validating these off-the-main-chain blocks is difficult. To fully validate the block, you need the set of unspent coins (UTXOs) at the time of the previous block. Bitcoin keeps the UTXO set for the current tip of the best chain, but not for all the other past blocks a fork could start from.
This design can infinitely increase the resources required to participate in the network as a staking node. Staking nodes in competition with an attacking node might have no inkling as to why their software is failing. The following blockchains have implemented fixes for part of the vulnerability:
CCN reached out to the Qtum team for comment on the “fake stake” vulnerability. They hadn’t gotten back to us by press time, but we will update this article if they do.
Featured Image from Shutterstock