Blockchain Vulnerabilities: Verge Network Mining Attack

The year 2018 has been rich in massive blockchain network breaches and attacks. Just recently, we told you some details about the Bancor exchange hack that resulted in over $13.5 million being stolen as well as the FOMO3D exploit and the most disturbing security issues of this popular game.

In this post, we’ll have the Verge Network mining hack explained and give you some interesting Verge Network mining hack details. The interesting thing about this attack is that in contrast to other much-talked-about blockchain hacks, this one wasn’t performed to steal existing cryptocurrency. This attack’s main goal was quite the opposite — to create more cryptocurrency.

The Verge network hack

Verge is a relatively small decentralized open-source cryptocurrency with a focus on user privacy. In the first half of 2018, the Verge network has found itself under a set of unusual types of blockchain attacks. In a matter of a few weeks, from April 4 to May 22, 2018, hackers exploited several bugs and mechanics of the network.

Their initial goal, however, wasn’t to steal any smart contract or private keys and eventually get access to the coins of network users. Instead, hackers started mining tokens just like any other miner would, but with one significant advantage — all the new coins were mined at a much higher rate. During the hack, new coins were generated at a rate of 1,560 coins per second, with the total value of counterfeit currency surpassing $1 million.

To make the Verge network attack happen, hackers exploited several vulnerabilities:

• Faking timestamps
• Manipulating the difficulty
• Dominating the network

Let’s take a closer look at each of these exploits.

Faking timestamps

Timestamp faking was the key vulnerability used by the attackers in this hack. Since Verge is a decentralized network, there’s no central authority to set the official time for everyone. As a result, enforcing perfect time synchronization within the network is also quite challenging, and consecutive blocks may have timestamps that are out of order.

For example, block 100 may have a timestamp later than block 101. This chain will still be considered valid by the network if the timestamp drift falls within a certain limit. This flexibility is a fair and deliberate feature of many blockchain networks. In the case of the Verge network, the protocol allowed nodes to disagree about the current time by at most two hours. So to start creating blocks at a higher rate, hackers simply submitted blocks from the past by setting a fake timestamp within the two-hour timeframe.

This issue is partially caused by the next problem: the mechanism for regulating difficulty in the Verge protocol.

Manipulating difficulty

The Verge network uses proof of work to create valid blocks. To ensure that relatively small devices such as personal computers can participate in the network, the volume of transactions within a block must be limited. This can be achieved by, among other things, setting a block time limit. But in this case, malicious nodes can start spamming blocks faster than the limit, especially when each submitted block earns a reward for the miner.

In order to prevent this from happening, the proof of work algorithm requires the node to solve a cryptographic problem. The difficulty of that problem is variable. Since the actual algorithm used by the Verge is the Dark Gravity Wave algorithm, the difficulty may change with every block based on the average block mining frequency for the last 30 minutes. So if there’s a lot of hashing power dedicated to the network, new blocks are generated faster and block time decreases. At the same time, the network protocol increases the difficulty, returning the block time to its target value. In the end, the block time on the Verge network is supposed to reach equilibrium at around 30 seconds.

The tricky thing is that the timestamp of each block is used to set the difficulty when the block frequency is calculated. And since hackers managed to manipulate the timestamps, they could also manipulate the difficulty.

Essentially, attackers tricked the difficulty algorithm into thinking that not enough blocks had been mined recently. As a result, the algorithm kept lowering the difficulty. During the latest attack, the difficulty dropped from 117320.58848226 before the attack to around 0.0015 during the attack. This drop in difficulty is shown in the image below.

You can see full difficulty charts for the Verge network here or follow the blocks with alternating timestamps in the block explorer, starting from around block 2155850. The difficulty gets to its lowest values at around block 2157500.

However, lowering the difficulty is just part of the story. Since the difficulty is the same for every miner on the network, block production turns into a real competition between miners. To ensure they could completely dominate the network, the hackers had to acquire most of the hash rate on the network.

Dominating the network

In order to dominate the network, hackers used what is called a 51 percent attack. Usually, this type of attack is used for tricking the system and spending the same cryptocurrency twice, which is why it’s also called a double-spend attack.

In the case of the Verge network, however, attackers took a bit of a different approach. They dominated the network to interfere with the creation of new blocks and prevent other miners from creating blocks. Furthermore, they managed to accomplish this while having far less than 51 percent of the hashing power. The main reason for this is another feature of the Verge protocol.

While there are many hashing algorithms that can be used for proof of work, each of them works well for a particular kind of software. Most blockchain networks support a single hashing algorithm. The Verge protocol, however, supports five different hashing algorithms to facilitate the network’s decentralization. And the only way to maintain the same block time for different algorithms is by having different difficulty values.

So hackers didn’t actually lower the difficulty for the entire network. Instead, they only had to target a single algorithm (in the April attacks, Scrypt) and mine new blocks using only that particular algorithm. As a result, they didn’t have to compete with all Verge miners but only with a small fraction of them.

Also, instead of getting 50 percent of the entire network’s hash rate, the hackers needed only about 10 percent of the general hashing power. And that’s assuming that each of the five algorithms was used equally, which they probably weren’t. Plus, since the hackers would most likely target the easiest algorithm, the real value of the acquired hashing power could be far less than 10 percent.

The entire attack came together nicely:

1. Hackers used fake timestamps to lower the difficulty of mining.
2. Since Verge uses five algorithms, the hackers needed to lower the difficulty of only a single algorithm.
3. Once the difficulty of the targeted algorithm was lowered, it was much easier to dominate the network.
4. Thanks to the reduced block time, the hackers could now create new blocks faster.

The attack had a reasonably large impact. Overnight, several million Verge tokens were generated from thin air. However, Verge developers didn’t react to the hack until it had been exploited and publicly discussed on the bitcointalk forums.

Mitigating the attack

Unfortunately, not only was the reaction of Verge developers not as fast as the response by NEM developers to the CoinCheck hack — it also wasn’t quite effective. The first solution used by the Verge developers was to limit consecutive blocks generated by one algorithm. It seems like they suggested that since only one algorithm was used during the attack, patching that exploit would help solve the problem. Predictably, this patch wasn’t effective at all.

During the attacks in May 2018, the attackers switched to using two algorithms instead of one, generating five blocks with one algorithm and five with another. But for every algorithm, the attack remained exactly the same.

Eventually, even though they had their issues with simple arithmetic at first, the Verge development team managed to limit the block drift window to ten minutes starting from block 2040000. This solution resolved the problem of timestamp manipulation by limiting its impact to the point where the attacker could lower the difficulty only partially and for a short period of time.

A potentially fatal vulnerability is still out there

Even though this problem was effectively solved by the Verge development team, there’s another critical vulnerability hiding in the Verge protocol database.

The problem comes from developers’ inheriting some properties of the original Verge code from Peercoin, another open-source cryptocurrency system. Since both Verge and Peercoin are open source, developers are free to copy and reuse any part of the code. In theory, this should allow developers to improve upon existing products and create a better network. Unfortunately, the Verge network inherited several properties that it shouldn’t have. For example, that same two-hour block time drift that was used by hackers in spring 2018 was inherited from Peercoin. For the Peercoin network, such a long block time drift worked perfectly since Peercoin has a much larger block time. But for the Verge network, setting the same two-hour block time drift was a huge mistake.

One more property that Verge shouldn’t have inherited from Peercoin is the way it determines a valid chain. It’s possible for two legitimate miners to create two different but equally valid chains at the same time. When other nodes receive these chains, they need to pick a single one to consider valid. In theory, the node should pick the strongest chain, meaning the one that has had more work put into it.

In contrast to Verge, however, Peercoin uses the proof of stake protocol. With that protocol, it’s easier to determine the strongest chain based on its length since every block in the chain is created in the same way.

For the proof of work protocol used by Verge, on the other hand, every block might take a different amount of hashing power. Therefore, it should contribute to the chain strength in proportion to its difficulty. So for the proof of work protocols with their variable difficulty, the longest chain doesn’t necessarily mean the strongest. The problem is that despite such significant differences, the Verge protocol mindlessly copied validation by length from Peercoin, thus opening another potential attack vector.

Here’s a potential scheme of an attack exploiting this vulnerability:

1. The attacker creates a private copy of the Verge blockchain.
2. Using the timestamp faking vulnerability, the attacker creates a lot of new blocks.
3. The attacker’s private blockchain becomes longer than the Verge blockchain.
4. The attacker publishes their blockchain and it’s accepted by the network as the current valid chain.

It takes only a couple of seconds to propagate new blocks around the network, so the attacker would stay several blocks ahead since they could create more than one block per second. This would effectively DDoS other miners, forcing them to orphan any block that they were working on.

Fortunately for Verge users, there have been no successful attempts at exploiting this vulnerability since the May hack. At the same time, Verge developers claim that they’re updating the network’s codebase to a recent fork of Bitcoin, meaning there still may be hope for the Verge network.

Conclusion

The Verge network hack serves as yet another bright example of what the consequences can be of using misconfigured code and not reacting to a breach fast enough. During the attacks in spring 2018, hackers managed to exploit several bugs found in the Verge network and use these vulnerabilities to their advantage.

At the same time, this series of attacks shows a completely different approach to attacking blockchain networks. Instead of simply stealing the cryptocurrency, as most hackers do, people behind the Verge mining hack found a way to mine more coins in a shorter period of time.

At Apriorit, we’re insistent on building things the right way and creating solutions and products that are not only effective but also highly secure. For example, we always apply security measures like DDoS defense techniques. With a high level of expertise in data protection and cybersecurity, we’ll gladly assist you in building a new blockchain solution from scratch.