Denial of Service to Blockchain

When we hear about Denial of Service attacks in the news, they usually target websites and web applications. The most classic type of attack harnesses a massive botnet formed with zombie malware infecting thousands or millions of endpoints and uses a command and control server to overwhelm a webserver’s memory buffer with an overwhelming quantity of data packets. That’s a Distributed Denial of Service attack, and they’re usually for the purposes of either vandalism, or to facilitate a more destructive cyber attack by distracting administrators and network security devices. Administrators may implement solutions such as Cloudflare to prevent Denial of Service attacks to their webservers.  

But Denial of Service attacks can impact data-in-transit in all forms.  They affect mobile applications, cloud services, and even blockchain implementations. Blockchain implementations in cryptocurrencies and various forms of record keeping technologies can be particularly vulnerable to Denial of Service attacks due to having millions of users. Its decentralized design makes trying to perform a Denial of Service attack a lot more complicated because it has a lot more access points. But the decentralization can make detecting an attack more challenging too. Let’s examine the blockchain Denial of Service problem.

Case studies: Block stuffing attacks

Most kinds of Denial of Service attacks work by overwhelming a memory buffer connected to an access point in an network. Block stuffing attacks are a little more complicated than that.

Cryptomining works by making CPUs and GPUs solve lots of complex mathematical problems. These days you need to leverage the power of thousands of processors in order to mine effectively. In Ethereum’s blockchain, transactions can spend a certain amount of “gas” in order to be included into a block on the chain. The amount of gas per transaction can be altered according to the authentication contracts they use. These contracts can be exploited when a cybercriminal wants to perform a block stuffing attack. A cybercriminal designs a contract that allocates too much gas for a block to handle. Excess gas is spent by lots of meaningless code, kind of like when attackers write garbage code to the firmware on a system that they’re targeting.

Onur Solmaz explains how this sort of block stuffing attack works:

“For example let’s say that the average gas price has been 5 Gwei in the last 10 blocks. In order to exert influence over the next block, the attacker needs to submit transactions with gas prices higher than that, say 100 Gwei. The higher the gas price, the higher the chance of inclusion by miners. The attacker can choose to divide the task of using 8,000,000 gas—current gas limit for blocks—into as many transactions as they want. This could be 80 transactions with 100,000 gas expenditure, or 4 transactions with 2,000,000 gas expenditure.”

Unlike the classic type of DDoS attack to webservers I described earlier in this post, cyber attackers who engage in block stuffing to Ethereum’s blockchain want to maximize their profits per block. This is one of the most financially motivated kinds of Denial of Service attacks.

“For miners, maximizing profit is an optimum packing problem. Miners want to choose a subset of the transaction pool that gives them maximum profit per block. Since there are at least tens of thousands of transactions in the pool at any given time, the problem can’t be solved by brute-forcing every combination. Miners use algorithms that test a feasible number of combinations and select the one giving the highest reward.”

As with most kinds of attacks to cryptocurrencies, this is a game of mathematics and risk taking. Too often, this is a lucrative activity for organized crime.

Case studies: An academic proof-of-concept

In October 2020, researchers from Cornell Tech and the Technion Israel Institute of Technology discussed their own intriguing proof-of-concept for a Denial of Service attack that targets blockchain. A proof-of-concept is a working theory from an academic, of course. But their report has found a mechanism that will likely be conducted by cyber attackers. We should watch out for stuff like this!

Here are some interesting excerpts from the report.

“The crux of the BDoS attack (blockchain Denial of Service) is as follows. The attacker generates a block 𝐵A and publishes only its header; we then say the attack is active. A miner can ignore the existence of the header of 𝐵A and generate a block following its parent, resulting in a fork. In this case, the attacker publishes the contents of 𝐵A, resulting in a race with two branches. The miner’s block might or might not end up in the main chain, depending on the parameters of the system. The implication is that the expected profitability of the rational miners decreases, and if it is low enough, then pausing mining becomes a better option than mining. If the profitability decrease is significant enough so that all miners stop mining, the attacker can cease mining as well, while she has an advantage of one block (𝐵A). The blockchain thus grinds to a complete halt.”

Nearly all types of data packets have headers. They give networking devices and other components of computer systems information about the data in the body of the packet. It’s like when you shop at the bulk food store and you have to put a tag on the bag with the code for the particular kind of candy or mixed nuts. The cashier will weigh your bag and price it according to the weight of your bag and its price per weight.  

Now imagine this. A bulk food bag with nothing in it but with a tag is handed to the cashier. The cashier treats the empty bag like it’s something that should be weighed and priced, but without contents they just leave it in the queue. An attacker slaps another bag full of the candy item that should be in the empty bag according to its tag. A sort of traffic jam starts to form in the cashier’s system. Can the attacker sneak the candy through the system without being stopped or detected? Meanwhile, in all of the confusion and chaos, legitimate bulk food customers decide they should buy their raisins and cashews somewhere else, so they leave the store. The attacker who snuck their bag of candy into the system has the upper hand while the cashier raises their hands in the air and gives up.

The impact

Denial of Service attacks can threaten two components of the CIA Triad of cybersecurity, Integrity and Availability. The threat to availability is obvious. A webserver or blockchain goes out of service, so its data becomes unavailable. People will inevitably lose money when a cryptocurrency blockchain goes out of service because money is made by cryptomining, buying, and selling.  

But there’s also the threat to integrity. The data in a blockchain may no longer be trustworthy, it might become corrupted. Both of the case studies described here involve cyber attackers putting fraudulent transactions into the blockchain.

Here’s a great example of the economic impact of blockchain vulnerabilities and exploits. Parity is a cryptocurrency wallet provider. In 2017, a bug in their system made it possible for entities to claim wallets that didn’t belong to them. That’s much like someone else grabbing your old-fashioned physical wallet or bank account and claiming it as their own. It’s literal theft. From Parity’s security alert:

“Following the fix for the original multi-sig vulnerability that had been exploited on 19th of July (function visibility), a new version of the Parity Wallet library contract was deployed on 20th of July. Unfortunately, that code contained another vulnerability which was undiscovered at the time - it was possible to turn the Parity Wallet library contract into a regular multi-sig wallet and become an owner of it by calling the initWallet function. It is our current understanding that this vulnerability was triggered accidentally on 6th Nov 2017 02:33:47 PM +UTC and subsequently a user deleted the library-turned-into-wallet, wiping out the library code which in turn rendered all multi-sig contracts unusable and funds frozen since their logic (any state-modifying function) was inside the library.”

It’s estimated that at least $280 million worth of cryptocurrency was frozen because of that vulnerability.

And that’s just one vulnerability in one blockchain system. The overall impact of blockchain Denial of Service attacks each year could be in the billions.

Can anything be done?

Developers often try to prevent vulnerabilities in their applications by engaging in code reviews. Code reviews can detect known vulnerabilities, such as those recorded in the CVE database. But performing a code review is very tedious and inefficient in large codebases. Often even known vulnerabilities can be missed because there’s just too much code to examine. Any programmer who’s alerted to syntax errors in tens of thousands of lines of code can grasp how frustrating code reviewing a large codebase can be. Also having to review the code in a lot of different libraries and external sources can be an uphill battle. And in general, protocol and contract vulnerabilities often aren’t recorded reliably.

Detection can also be very difficult. Blockchain attackers often exploit contracts and other authentication keys, so their malicious activity could look like legitimate blockchain activity to application firewalls and other sorts of security measures. Enterprise monitoring systems are getting more sophisticated. And well designed algorithms, SIEM correlation rules and the like can detect some blockchain attacks. But deep inspection can be a challenge. Monitoring systems often lack full visibility.

Application firewalls should be deployed, regardless. It’s very important to configure them well. But if malicious activity is conducted at the application level, it can be missed. That’s similar to how malicious activity with authentication keys can slip through the cracks.

When designing and maintaining a blockchain application, following known best practices is an excellent idea. You can avoid a lot of security problems that way. But best practices alone are insufficient for regulatory compliance. And current compliance standards were often developed with non-blockchain systems in mind. Best practices and compliance must catch up with rapidly evolving blockchain threats.

The integrity and availability of data is at stake in these blockchain threats, as are very large quantities of money. But don’t lose hope. Recognizing the problem is the first step in creating effective solutions.

About Valid Network  

Valid Network’s blockchain security platform provides complete life cycle security for enterprise blockchains from initial development to active deployment and management. Based in Be'er Sheva, Israel, the company’s solutions enable enterprises to innovate with blockchain faster, providing complete visibility and control over their distributed applications and smart contract governance, compliance, and security posture through advanced platform capabilities.

Secure the block with Valid Network.

Learn more:

Follow us: LinkedIn | Twitter | Blog

Other Blogs

Introducing Ethereplay by Valid Network

We are excited to announce Ethereplay by Valid Network, a free community tool to support examining, analyzing, optimizing and securing of smart contract code on Ethereum.

Broken Authentication: The Greatest Vulnerability to Cryptographic Systems

What do blockchain, VPN, and SSH all have in common? They’re all implementations of cryptographic technology.