Blockchain Security—Moving Beyond the Hype

By Morey Haber, Chief Technology Officer, BeyondTrust

I am simply amazed at all the buzz around Bitcoin, Blockchain, and cryptocurrency. However, the truth is that blockchain has a limited place in business and needs to be secured just like any other application; with some twists.

The Why

Blockchains are not a database replacement, nor will future applications that utilize them.

They are a multi-node distributed ledger system that secures entries based on volume and verification. Natively, blockchain can only process a limited number of transactions per second and cannot store complex records or blobs—only ledger-style information that has a finite start date, like shipping information.

As such, historical records, pictures, complex indexes, and other large datasets are just not good for blockchain technology. This is one of the problems security teams need to understand. Think of a blockchain implementation like an old school peer to peer network technology from Napster or bearshare. Each node contains a database of all records and any new entries need to propagate to all other nodes for validity. While a peer-to-peer network queries its peers for entries, blockchain actually contains a duplicate of all entries compared to its peers. This means tampering with one node does not invalidate the entire blockchain. As a consequence, every entry has to be properly validated to be accepted as a ledger entry and propagated to other nodes.

Morey Haber, CTO, BeyondTrust

This is where security is so critical. Entries into the blockchain ledger need to be validated for fraudulent activity, and more importantly, the hosts containing blockchain implementations need to be secured against vulnerabilities and privileged attacks that could compromise or tamper with blockchain insertions. There is no concept of blockchain ledger modifications—this is key to protect the integrity of the data. Once an entry is accepted, it is permanent. Therefore, if you can attack the server, application, and ledger processes, you can tamper with the blockchain. This is how some of the recent cryptocurrency attacks have been occurring.

To cite a recent example, on Monday, May 28^th 2018, The Hacker News reported on a wicked vulnerability within the EOS Blockchain Platform. While the vulnerability is considered critical, and the method of exploitation fairly basic (a maliciously crafted file), the ramifications are truly astounding. After the vulnerable parser reads the file, it forces an exploit on the node which could then be leveraged against the supernode on the EOS platform. The supernode is responsible for collecting transaction information and packing it into blocks. Once the threat actor owns the supernode, he/she can modify or create malicious blocks that would control the entire EOS network. This includes everything the EOS Blockchain Platform has been implemented to perform—from cryptocurrency, supply chain management, to identity storage. Let this sink in—the uncrackable Blockchain (as it is advertised) can be owned by the fundamental technology designed to protect it; WASM files (smart contracts) and a simple file upload.

The How

So how do we secure blockchain implementations? We first start with cyber security basic hygiene:

• Asset Inventory – Identifying and managing the lifecycle of all software, code, applications, nodes, and operating system used in the Blockchain.
• Change Control – Ensuring changes to the operating system, application, and resources are documented and go through a formal change control process.
• Configuration Management – The hardening and removal of default settings that are a liability for the operating system, application, or network.
• Vulnerability Management – Ensuring that the operating system, application, web application, and source code are reviewed for vulnerabilities and risks are prioritized accordingly.
• Log Management – Centrally managing and parsing log files from all resources in the environment including transaction logs.
• Patch Management – Using a systematic and predictable methodology for deploying maintenance and security patches to all systems in the environment—from firmware to web applications and everything in between.
• Identity and Access Management – The predicable workflow management of identities, roles, and entitlements for all users that have access to resources of the system.
• Privileged Access Management – The management of all privileged access into the Blockchain environment—from operating system to web applications including password management, least privilege access, session management, keystroke logging, and application to application key and password management.

And now the twist:

• New entries into the blockchain should be secured with dynamic privileges and only valid for one-time usage. This can be done with privileged password access solutions and keys or passwords using an API. An insecure insertion path into the blockchain can lead to devastating results.
• Reads from the blockchain should be secured in a similar fashion to ensure the retrieval is not tampered with (like a man in the middle attack) before processing by the application.

Since modifications and deletions of blockchain records are not permitted, all entries must be 100% valid or the entire model (ledger) could be compromised. Think of blockchains as just another application for data storage. It has limited data storage capabilities, is not very fast, but is designed to be highly distributed and 100% reliable. If your application or host can be tampered with, so can you blockchain. The goal—securing both during their design and implementation so this can never occur.

By Morey Haber, Chief Technology Officer, BeyondTrust

I am simply amazed at all the buzz around Bitcoin, Blockchain, and cryptocurrency. However, the truth is that blockchain has a limited place in business and needs to be secured just like any other application; with some twists.

The Why

Blockchains are not a database replacement, nor will future applications that utilize them.

They are a multi-node distributed ledger system that secures entries based on volume and verification. Natively, blockchain can only process a limited number of transactions per second and cannot store complex records or blobs—only ledger-style information that has a finite start date, like shipping information.

As such, historical records, pictures, complex indexes, and other large datasets are just not good for blockchain technology. This is one of the problems security teams need to understand. Think of a blockchain implementation like an old school peer to peer network technology from Napster or bearshare. Each node contains a database of all records and any new entries need to propagate to all other nodes for validity. While a peer-to-peer network queries its peers for entries, blockchain actually contains a duplicate of all entries compared to its peers. This means tampering with one node does not invalidate the entire blockchain. As a consequence, every entry has to be properly validated to be accepted as a ledger entry and propagated to other nodes.

Morey Haber, CTO, BeyondTrust

This is where security is so critical. Entries into the blockchain ledger need to be validated for fraudulent activity, and more importantly, the hosts containing blockchain implementations need to be secured against vulnerabilities and privileged attacks that could compromise or tamper with blockchain insertions. There is no concept of blockchain ledger modifications—this is key to protect the integrity of the data. Once an entry is accepted, it is permanent. Therefore, if you can attack the server, application, and ledger processes, you can tamper with the blockchain. This is how some of the recent cryptocurrency attacks have been occurring.

To cite a recent example, on Monday, May 28^th 2018, The Hacker News reported on a wicked vulnerability within the EOS Blockchain Platform. While the vulnerability is considered critical, and the method of exploitation fairly basic (a maliciously crafted file), the ramifications are truly astounding. After the vulnerable parser reads the file, it forces an exploit on the node which could then be leveraged against the supernode on the EOS platform. The supernode is responsible for collecting transaction information and packing it into blocks. Once the threat actor owns the supernode, he/she can modify or create malicious blocks that would control the entire EOS network. This includes everything the EOS Blockchain Platform has been implemented to perform—from cryptocurrency, supply chain management, to identity storage. Let this sink in—the uncrackable Blockchain (as it is advertised) can be owned by the fundamental technology designed to protect it; WASM files (smart contracts) and a simple file upload.

The How

So how do we secure blockchain implementations? We first start with cyber security basic hygiene:

• Asset Inventory – Identifying and managing the lifecycle of all software, code, applications, nodes, and operating system used in the Blockchain.
• Change Control – Ensuring changes to the operating system, application, and resources are documented and go through a formal change control process.
• Configuration Management – The hardening and removal of default settings that are a liability for the operating system, application, or network.
• Vulnerability Management – Ensuring that the operating system, application, web application, and source code are reviewed for vulnerabilities and risks are prioritized accordingly.
• Log Management – Centrally managing and parsing log files from all resources in the environment including transaction logs.
• Patch Management – Using a systematic and predictable methodology for deploying maintenance and security patches to all systems in the environment—from firmware to web applications and everything in between.
• Identity and Access Management – The predicable workflow management of identities, roles, and entitlements for all users that have access to resources of the system.
• Privileged Access Management – The management of all privileged access into the Blockchain environment—from operating system to web applications including password management, least privilege access, session management, keystroke logging, and application to application key and password management.

And now the twist:

• New entries into the blockchain should be secured with dynamic privileges and only valid for one-time usage. This can be done with privileged password access solutions and keys or passwords using an API. An insecure insertion path into the blockchain can lead to devastating results.
• Reads from the blockchain should be secured in a similar fashion to ensure the retrieval is not tampered with (like a man in the middle attack) before processing by the application.

Since modifications and deletions of blockchain records are not permitted, all entries must be 100% valid or the entire model (ledger) could be compromised. Think of blockchains as just another application for data storage. It has limited data storage capabilities, is not very fast, but is designed to be highly distributed and 100% reliable. If your application or host can be tampered with, so can you blockchain. The goal—securing both during their design and implementation so this can never occur.