Four common pitfalls of HyperLedger implementation

After several security audits of HyperLedger implementations (and other custom blockchain platforms), we have selected a couple of challenges that our clients met. In this article, we present these challenges, potential security problems they introduce, and solutions to these challenges.

Some of these challenges do not introduce a vulnerability directly but break the rules of blockchain technology and that could have serious security implications.

1. Centralized infrastructure

One of the main goals of distributed ledger technology (DLT), used by HyperLedger, is decentralization. The nodes (servers) of the network should be spread among all organizations in the consortium and they should not depend on the third party providers.

However, we have seen implementations where the whole infrastructure is maintained by one organization or where it is spread among the organizations but all of them host their nodes provided by the same cloud vendor (e.g. AWS).

With centralized infrastructure comes the threat that one organization or external provider could easily turn off the system and thus break the principal goal of DLT.

Solution

Each organization of the consortium must maintain their own node (or multiple nodes). Ideally, it should be on premise. External providers could be used, but it should not be one provider for all organizations but different ones to not introduce a single point of failure (or attack).

2. Default policies

The default policies in HyperLedger permit any organization’s member with a Reader role to read the channel (an independent part of the distributed ledger) and any organization’s member with Writer role to write to the channel (invoke chaincode). Such configuration is fine for default implementations where each organization in the channel is treated equally and should have the same permissions.

However, in some cases the business requirements assume that one of the organizations cannot perform modifying operations on the channel (invoke chaincode), but should be able to read it – simply read-only access. If that is the case and the default policies are used, the read-only-access organizations are able to invoke chaincode on the channel and modify the contents of the distributed ledger. 

Also, sometimes channel configuration by mistake includes all organizations instead of the selected ones. Such configuration with the default policies allow all organizations (including unauthorized ones) to join the channel and invoke chaincode.

Solution

The default channel policies must be reviewed. If there is an organization that should have limited access (e.g. read-only) the policies must be updated and the organization should be removed from the Writers (and Admins) channel policy. 

Also, the list of organizations allowed to access the channel must be reviewed and unauthorized organizations removed.

3. Chaincode without access control 

The business requirements for a few implementations defined that a selected subgroup of organizations were permitted to invoke any function in the chaincode and the others could invoke only some functions from a predefined list. 

Alternative case was that an organization was allowed to invoke a function itself but could use it to update only a limited set of parameters in the ledger state.

The channel policy does not allow to define such a granularized permissions so if one allows the organization to write to the channel, the organization can invoke all functions in the chaincode without any limitations.

Solution

In order to add the access control on the chaincode level one can use Client Identity Chaincode Library This library allows developers to check the identity of the chaincode caller (in particular their organization and caller’s certificate attributes) and build the access control list on the function level.

4. Privileged organization

One of the extremes in defining permissions in the DLT network, contrary to limiting the access of an organization, is privileging one of the organizations in such a way that it can make any changes to the distributed ledger. 

As such configuration does not have to introduce a vulnerability, it is against blockchain rules. We have met different implementations with this issue that all allowed one organization can freely modify the contents.

• The channel endorsement policy required the signature only from one organization. That simply allowed this organization to submit any modification transaction that could not be blocked by other organizations. 
• The chaincode functions allow the selected organization to update any key with any value at any time.

All these changes would be stored on the blockchain in the form of transactions so any organization could detect that. However, if the applications execute operations automatically based on the content of the world state, the attack will be detected too late.

Solution

There is a couple of things to remember:

• The policies and chaincode source code must be reviewed and potentialy too powerful organizations should be detected and mitigated. 
• The channel and modification policies must require multiple endorsements and confirmations. 
• The chaincode source code should not include too powerful functions – they should be replaced with simpler functions that perform operations in accordance with a previously established workflow (accepted by all organizations).

Conclusions

This article covered four most common pitfalls we have met during security audits of HyperLedger implementations (and other custom blockchain platforms). 

All of them introduce potential threats to the DLT implementations or break its rules. That is why we have proposed solutions to solve the challenges and mitigate the introduced threats. 

Below is a brief summary of the things you need to pay attention to when deploying a blockchain:

• Maintain independent node(s) for all organizations.
• Run nodes on premise or via multiple external providers in different datacenters.
• Review default configuration, especially channel policies, the list of organizations that have access to the channel and endorsement policies (they should require multiple endorsements).
• Use access control mechanism in the chaincode based on the certificates (e.g. Client Identity Chaincode Library).
• Review the chaincode and remove too powerful functions.

We hope that the above-mentioned cases do not apply to you 🙂 If you would like to talk about the security of your HyperLedger implementation, feel free to use our contact form.

Damian Rusinek Principal IT Security Consultant
Head of Blockchain Security