Blockchain nodes act as collaborative witnesses to blockchains. Each is equipped with a copy of the blockchain, which it monitors and adds blocks to as they are published by miners. Besides providing verification of the integrity of the blockchain, nodes also accept and relay transactions through the transaction “mempool” and help relay metadata about the status of the blockchain they monitor.

Blockchain node application security testing is recommended in cases where the blockchain is new, has been modified from an existing implementation, or is an existing blockchain implementation which has not received rigorous security audits.

Nodes can be attacked in several ways: the publication of invalid or valid malformed blocks, through the node’s peer-to-peer communications with other nodes, attacking the node’s third-party software dependencies, and the node’s remote procedure call interface. Public and private blockchains may not wholly share this attack surface as private blockchains can limit interactions with untrusted third parties. Public blockchains on the other hand must have rigorous node testing to ensure that the attack surface is properly secured.

Components Tested

• Peer to peer protocol vulnerabilities
• Defense against eclipse / peer network attacks
• Remote Procedure Call (RPC) authentication
• Secure implementation of Remote Procedure Call (RPC) methods
• Blockchain block parsing

Attack Surface

Blockchain nodes may have the following attack surfaces depending on the configuration of the node and if the blockchain it supports is permissioned or public. Note that this list is not exhaustive.

Communications Interfaces

How does the node communicate, and how can an attacker exploit that communication path? Nodes may have RPC (Remote Procedure Call), web, serialized protocols, or other interfaces for node-to-node communications and administration. Manual testing should be performed for every interface, evaluating authentication requirements, IP-based restrictions, OWASP web application attacks (if applicable), abusing intended functionality, and responses to unexpected inputs.

Input Handling and Sanitization

Can the node software be compromised through unexpected formatting of blocks or other inputs? If the source code is publicly available, it should be reviewed by an expert to look for insecure coding practices. This can be aided by automated code scanning tools but should also include manual analysis of the code that processes inputs.

Eclipse Attacks

Public blockchain nodes and applications which leverage nodes should be designed to be resistant to an eclipse attack. Eclipse attacks occur when attackers attempt to surround a specific node with peers under the attacker’s control to feed false information (e.g., fake transaction verifications) to the target node. Other vulnerabilities, such as denial of service attacks, can be used to disrupt normal peer to peer network operations to create favorable conditions for an eclipse attack. Very small blockchains with few nodes could be more vulnerable to these types of attacks. This type of vulnerability can be assessed with an application security test of the node software.

Operating System (OS) and Services

Is the OS secure, and are the other services secure? Is there an endpoint protection solution, ingress/egress firewalls, strong authentication requirements, patch management, and other industry standard controls? An attacker often does not need to develop a customized attack against your specific technology if these traditional controls are not in place. Standard network penetration techniques should be attempted against the nodes.

DevOps

Can an attacker impact the source code for the node? This includes third-party software dependencies used to build the software or provide functionality at runtime. See the DevOps section of this document for DevOps testing practices.

Software Distribution

If code or executables are posted publicly to a web application for download, then that application and website itself becomes a target. See the application security section of this document for more information on testing strategies.

Administration

Is there centralized administration of nodes and if so, can an attacker compromise it? With private blockchains, it is sometimes the case that a single company or entity administers a significant percentage of the total number of nodes. In these cases, we recommend conducting a red team assessment to assess the possibility of an attacker compromising an admin account. See the red team section of this document for more information.