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:

  1. The number of signatures in signaturePack must be greater than or equal to requiredSignatures.

  2. The number of unique public keys from valid nodes in signaturePack must also be greater than or equal to requiredSignatures.

A malicious validator can exploit these checks as follows:

  1. Populate signaturePack with at least requiredSignatures valid signatures, which can be generated by any key controlled by the attacker.

  2. 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

  1. Apply the following git diff on the Archiver for some nice logs and clarity:

  1. Apply the following diff on the Core:

  1. Send the following payload to the new blockian route 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?