#39973 [BC-Critical] Standard node rewarding flow can be blocked

Submitted on Feb 11th 2025 at 23:57:05 UTC by @periniondon630 for Audit Comp | Shardeum: Core III

  • Report ID: #39973

  • Report Type: Blockchain/DLT

  • Report severity: Critical

  • Target: https://github.com/shardeum/shardeum/tree/bugbounty

  • Impacts:

    • Direct loss of funds

Description

Brief/Intro

An attacker can frontrun validator reward transactions across the entire network and disrupt the reward distribution process.

Vulnerability Details

When the network deactivates or removes a node, it issues a nodereward transaction. An attacker can censor this transaction across the entire network, effectively disrupting the reward distribution process.

Root Cause

The issue lies in the hash field of network transactions, as defined in the AddNetworkTx interface:

The hash field is not properly validated each time a node receives a gossip message containing a new network transaction. Instead, it is directly used to determine whether the node has already received the transaction:

Attack Mechanism

Since all nodes generate the same network transactions based on cycle records, an attacker can precompute the hash of a new transaction and inject a modified transaction with a new hash but an old payload. On target nodes, the new hash will occupy a key in the txAdd hashmap, effectively preventing the valid transaction from being propagated and processed. The attacker must craft the old payload in a way that allows it to bypass initial filtering so that it gets added to the txAdd hashmap:

Once the transaction passes validation in beforeAddVerifier, it is added to addProposals and subsequently included in txAdd through the sendRequests function:

By injecting a new hash with an old payload, the attacker prevents the legitimate transaction from propagating across the network. This censorship can also be performed at the node level, as the gossip protocol and internal transaction flow both rely on the same hashmap:

Impact Details

Targeted (specific node) or full network node reward process disruption, allowing an attacker to manipulate or delay validator payouts.

References

https://github.com/shardeum/lib-types/blob/ebf34c1538e8ece8a6e022cf4774ee27fd4ddcc7/src/p2p/ServiceQueueTypes.ts#L9 https://github.com/shardeum/core/blob/5515dedc5f67d621c9e179f22a32e54e66e8682d/src/p2p/ServiceQueue.ts#L77 https://github.com/shardeum/core/blob/5515dedc5f67d621c9e179f22a32e54e66e8682d/src/p2p/ServiceQueue.ts#L628C5-L641C16 https://github.com/shardeum/core/blob/5515dedc5f67d621c9e179f22a32e54e66e8682d/src/p2p/ServiceQueue.ts#L455

https://gist.github.com/periniondon630/9f86f0fae7e782aab93ca256cb7c60dd

Proof of Concept

Proof of Concept

  1. Apply patch for core & shardeum repos from gist

  2. Build, start network, add extra nodes for rotation, stake.

  3. Activate attack mode on attacker's node:

  1. See logs on the nodes how nodereward internal transactions are rejected.

Log samples:

Attacker:

Victim:

Was this helpful?