I have been in the Blockchain world since 2017. One of the questions that stuck in my mind(as a newbie in 2017) was

Blockchains, like Bitcoin, are public, right? There are thousands of nodes, broadcasting messages to the network…This is a really promising situation for any hacker. Can we leverage these distributed Systems to infect the whole network?

A few months later, after understanding how these systems work, I finally started getting the answers.

In this article, we will see:

• Why it’s Hard to Infect a Blockchain itself?
• Can we use Distributed Systems to store malware?
• A practical example of how we can spread malware using distributed systems such as IPFS and Ethereum Swarm.

Let’s get started! It’s going to be a fun ride…

Why it is Hard to Infect a Blockchain?

For our example, we will target Bitcoin & Ethereum.

Like all blockchains, nodes in a Bitcoin/Ethereum network, communicate with other nodes and execute code to verify & generate transactions/blocks.

Now in order for malware to spread and infect the blockchain, we have to

• Step 1: send the malware within the transaction
• Step 2: exploit a bug in bitcoin client software

It seems simple, but both of these steps have a problem.

Problem with Step 1: The amount of data we can send in a transaction is really minimal.

In the case of Bitcoin, even the maximum size of a Bitcoin block is 1MB. Thus the size of a transaction is even smaller(~80bytes).

Similarly, for Ethereum you have a limit on how big/complex(block gasLimit) a block can be. Thus, Ethereum also has a restriction on the size of the transaction.

This goes the same for all the blockchains.

Problem with Step 2: When we receive our malicious payload, there is very little that we can do with it.

• The transactions are usually written in a fixed format. Many blockchain clients don’t accept any arbitrary message.
• The execution environment(EVM in case of Ethereum) is really restrictive and only allows a very few types of instructions to be executed. Also, even if Ethereum supports smart contracts and boasts the Turing completeness of Solidity, the EVM restrictions(limited OP Codes and limited blockgasLimit) render the overall environment far away from Turing-completeness.

If you want to know more how EVM works, you can check this out

This applies to most of the Blockchain environments.

Also, as the client code is publicly available, so it’s vetted by a very large community of developers. This makes it less probable to find an exploitable vulnerability in the client. This doesn’t mean that it’s impossible to do, but when compared to today’s internet hacks that give much more freedom to hackers, it’s really hard to find a loophole.

Can we use Distributed Systems to store malware?

Well, we saw that it’s hard to mess with blockchains, but we are not stopping here…

It’s hard to infect these systems, but they are still really good payload delivery mechanisms.

We saw that due to the limited size of transactions, it’s difficult to package a malware within a single transaction…Well, who said that have to use just one transaction?

Enter K-ary Malware.

These things are not new. So, if you are familiar with malware then you may be not that surprised.

These have been here since 2007 and have infected a lot of systems already. You can find a detailed study of them in these papers[0,1]. I will try to keep this article less technical.

The way these malware works is that instead of keeping the malicious payload as one entity, it divides the payload into k parts. Each part looks like an innocent executable file and does not generate any indication of compromise (IOC).

Now, there are 2 different categories of k-ary:

1. The k parts are working sequentially. Thus, it’s NOT necessary to have all the parts available and active at the same time.
2. The k parts are working in parallel. Thus, all chucks have to be available and active in the system in the same period.

The choice depends on the circumstances and the system that you are targetting.

To make the attack more stealth, we can also encrypt the chunks. So, in this way, we can pass the encrypted payload and keys(to decrypt the payload) separately.

Furthermore, we can use the hashes of the payloads to identify if all the parts are present in the network before we execute the viral payload.

You may ask how do k-ary benefits from DLTs(Distributed Ledger Systems)?

There are a few advantages of using a DLT

• The data on DLT is immutable to a high degree. This means that if we add our malware to a DLT, it’s really hard to get it off, as these networks are not controlled by any single entity.
• The inherent use of cryptography makes it easy for malware to verify the integrity of its chunks. As all the data is referenced using hashes(content-addressing) rather than its location(location addressing), it gives us a more trusted way to verify if a chunk has been tampered with or not.

Some Practical Examples

Disclaimer: Below demonstrated techniques are for educational purposes only.

To see how the above proposes system will work, we will demonstrate it on IPFS.

First, we will take a Keylogger and check it against the antivirus software. Then we will use IPFS and Swarm to store these payloads and see if the chunks are detected by the antivirus software.

Let’s first download a keylogger. you can use this one. Now, check it against the antivirus software here.

You can see that the malware is detected.

Now chunk the malware.

You can download and setup IPFS from here.

After installing use following command to add the malware to IPFS.

ipfs add <path-to-malware-file>

You will receive the following output

Your malware is chunked and stored on IPFS. The hash of my whole malware file is(as seen in the above image)

QmNuAxMT9pepjZ26yXEk4T8qXofJrHoe7SxpoHa5WJ3T5x

If you want to know more about how this works, you can check this out.

Now you can list the chunks using this command

ipfs ls QmNuAxMT9pepjZ26yXEk4T8qXofJrHoe7SxpoHa5WJ3T5x

This gives me the following output

These are the hashes of the chunked files. Now we can get each file using

ipfs get <hash-of-chunk>

As I am fetching the chunks by referencing their hash, I am totally sure that these chunks are not tampered with.

Now you can check the individual chunks against the antivirus software. All your chunks will pass the tests.

Now as we know that all parts of our malware are available, we can execute our keylogger.

Note: IPFS is NOT persistent by default. The content is deleted by the garbage collector if the content is not pinned.

Ethereum Swarm(storage layer of Ethereum) provides persistent storage. So, it can be a better option for now. Swarm also works in a quite similar way. You can add chunks of your malware and fetch it by referencing it via its hash.