39872 [W&A-Critical] bypass receipt signing validation
#39872 [W&A-Critical] Bypass Receipt Signing Validation
Submitted on Feb 9th 2025 at 15:55:37 UTC by @Blockian for Audit Comp | Shardeum: Ancillaries III
Report ID: #39872
Report Type: Websites and Applications
Report severity: Critical
Target: https://github.com/shardeum/archive-server/tree/itn4
Impacts:
Direct theft of user funds
Description
Shardeum Ancillaries
Bypass Receipt Signing Validation
Description
A vulnerability in the storeReceiptData function allows a malicious validator to bypass signing validation. This enables them to store arbitrary receipts and overwrite any account data on the archive server. (Including Global Account)
Root Cause
The function verifyAppliedReceiptSignatures validates signaturePack by ensuring that the signatures themselves are valid. However, it does not check whether the signatures originate from actual nodes within the system.
At first glance, this seems acceptable since signaturePack goes through a prior validation in verifyReceiptData. However, this verification contains a critical flaw. Let's examine the relevant snippet of verifyReceiptData:
The Exploit Strategy
There are two primary validation steps in verifyReceiptData:
The number of signatures in
signaturePackmust be greater than or equal torequiredSignatures.The number of unique public keys from valid nodes in
signaturePackmust also be greater than or equal torequiredSignatures.
A malicious validator can exploit these checks as follows:
Populate
signaturePackwith at leastrequiredSignaturesvalid signatures, which can be generated by any key controlled by the attacker.Include the public keys of all valid nodes, but pair them with invalid signatures.
This results in signaturePack containing 2 * requiredSignatures entries:
Half are valid signatures produced by the attacker.
Half are invalid signatures that falsely claim to originate from valid nodes.
Despite the invalid signatures, verifyReceiptData considers the validation successful because the length condition is met.
Now, when verifyAppliedReceiptSignatures runs, it finds requiredSignatures valid signatures and passes the check, allowing the malicious validator to bypass signature validation.
Impact
This vulnerability has the same impact as the issue reported here
A malicious validator can modify any account data stored on an archive server if it is connected to the validator via a socket.io connection. This includes the global network account, posing a significant security risk.
Proposed Fix
To prevent this exploit, verifyAppliedReceiptSignatures should:
Verify each signature only if it originates from a valid node.
Reject signatures from unverified sources before counting them.
Proof of Concept
Proof of Concept
Apply the following
git diffon the Archiver for some nice logs and clarity:
Apply the following
diffon the Core:
Send the following payload to the new
blockianroute after the network reaches cycle 15.
Now, you'll be able to see the logs of the global account changing:
Last updated
Was this helpful?