#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
Link to Proof of Concept
https://gist.github.com/periniondon630/9f86f0fae7e782aab93ca256cb7c60dd
Proof of Concept
Proof of Concept
Apply patch for core & shardeum repos from gist
Build, start network, add extra nodes for rotation, stake.
Activate attack mode on attacker's node:
See logs on the nodes how nodereward internal transactions are rejected.
Log samples:
Attacker:
Victim:
Was this helpful?