Three Sandbox Endpoints, One MPC Core

The brief lists three in-scope targets: sb-console-api.fireblocks.io, sb-mobile-api.fireblocks.io, and sandbox-api.fireblocks.io. All are tagged Cryptography and Cryptocurrency, and the program description explicitly ties them to the MPC protocol for ECDSA and EdDSA signatures used by Bitcoin, Ethereum, and other chains. No other hosts or subdomains are in scope, so the engagement boundary is tight and well-defined.

Because the scope rating is 1 out of 4, the attack surface is narrow by design. The review should therefore treat the three endpoints as facets of a single cryptographic service rather than independent applications. Any authorization flaw, parameter tampering, or state confusion that lets an attacker influence which key shares participate in signing — or which message digest gets signed — is the primary risk the program wants surfaced.

  1. Confirm each endpoint's base path and API version through the developer docs before any request is sent.
  2. Enumerate the authentication scheme (API key, JWT, mTLS) for each target and note where they diverge.
  3. Record which endpoints expose transaction signing, key derivation, and policy evaluation.

Sources: Get Started — public program brief

Sandbox Account Provisioning With @bugcrowdninja.com

Access requires a researcher-controlled account registered with an @bugcrowdninja.com email address; the brief states registration will not work with any other domain. This is a hard prerequisite — no testing can begin until the account is provisioned and the identification header (as specified in the brief) is confirmed working against all three endpoints.

Plan to create at least two accounts: one primary for standard flows and a second for cross-account authorization tests. Document the onboarding steps, any KYC-lite checks in the sandbox, and the exact header name/value the program expects for researcher identification. Treat this as a future checkpoint: if the header is rejected or the sandbox returns an unexpected error code, pause and verify the registration flow before proceeding.

  1. Register two @bugcrowdninja.com accounts and complete sandbox onboarding.
  2. Capture the exact researcher-identification header value required by the program.
  3. Verify each endpoint returns 200/401 (not 403/5xx) for authenticated health-check calls.

Sources: Get Started — public program brief

Unauthorized Funds Transfer and Signature Manipulation

The program lists "Performing unauthorized actions with an emphasis on unauthorized funds transfer" as the first focus area. In an MPC context, this translates to: can an authenticated user cause a signature to be produced for a transaction they are not authorized to sign? Look for insecure direct object references on vault accounts, policy bypasses that skip quorum checks, and any API parameter that lets the caller supply or override the message digest.

Secondary priorities are disclosure of sensitive material (key shares, derivation paths), XSS/CSRF in privileged console flows, and injection in any metadata fields that reach the signing pipeline. RCE and directory traversal are in scope but less likely on a managed sandbox; still, any file-upload or template-rendering feature should be noted for later review.

  1. Map every signing-related endpoint to its required policy ID, vault account ID, and asset type.
  2. Identify all user-supplied fields that influence the digest or derivation path.
  3. List any admin-only or multi-user approval flows exposed via the console API.

Sources: OWASP Web Security Testing Guide

Parameter Validation and Policy Enforcement in the Signing Pipeline

For each signing endpoint, trace the request from authentication through policy evaluation to the MPC node interaction. The critical question is whether the server re-derives the digest from canonical transaction fields or trusts a client-supplied hash. If the latter, test whether an attacker can submit a digest that corresponds to a different transaction (same scheme, different recipient/amount) while passing policy checks.

Also examine cross-endpoint consistency: does the mobile API enforce the same policy logic as the console API? Are there endpoints that sign arbitrary messages (EdDSA) versus structured transactions (ECDSA)? Any discrepancy is a candidate for authorization bypass. Keep tests non-destructive: use researcher-controlled vault accounts, small test amounts, and the sandbox's native testnet assets.

  1. Send a signing request with a valid policy but a researcher-chosen digest; observe rejection or acceptance.
  2. Attempt to reference another account's vault ID in the signing payload using the primary account's credentials.
  3. Compare policy evaluation responses across console, mobile, and core APIs for identical inputs.

Sources: OWASP Web Security Testing Guide

Reproducible Request-Response Logs With Header Attribution

Every test must produce a reproducible artifact: the full HTTP request (method, path, headers, body) and response (status, headers, body), captured with the researcher-identification header present. Redact only secrets (API keys, signatures) — keep vault IDs, policy IDs, timestamps, and error codes intact. This lets the triage team replay the exact flow without guessing at hidden state.

For cryptographic findings, include the curve (secp256k1, ed25519), the digest algorithm (SHA-256, SHA-512), and whether the digest was client-supplied or server-derived. If a policy bypass is suspected, show the policy definition (quorum, allowed destinations) alongside the request that circumvented it. Stop evidence collection once the minimal set demonstrating the issue is captured; do not enumerate further variants.

  1. Save request/response pairs as timestamped JSON files with a consistent naming scheme.
  2. Include the researcher-identification header value in every logged request.
  3. Document the exact sandbox asset and amount used for each signing test.

Sources: OWASP Web Security Testing Guide

Conditional Fix Paths for MPC Authorization Gaps

If a digest-injection flaw is confirmed, the fix is to make the server the sole authority for digest derivation: accept only structured transaction fields, compute the hash internally, and reject any client-supplied hash parameter. This assumes the transaction schema is stable and the MPC nodes expect a server-computed digest — verify with the engineering team before proposing.

For cross-account vault reference bugs, the remediation is an explicit ownership check at the policy-evaluation layer: the vault account ID in the request must resolve to a vault the authenticated user (or their policy) controls. Rollout can be staged per endpoint; rollback is a feature flag that re-enables the old resolver. Regression verification requires a test matrix covering legitimate multi-user policies, delegated signing, and the original bypass vector.

  1. Propose server-side digest derivation with schema validation as the primary fix for hash injection.
  2. Specify an ownership-check middleware for vault-account resolution with a feature flag for rollback.
  3. Define a regression test matrix: valid policy, cross-account attempt, delegated signer, revoked policy.

Sources: OWASP Web Security Testing Guide

Post-Fix Replay and Policy Regression Suite

After a fix is deployed to the sandbox, re-run the exact evidence requests — same accounts, same headers, same payloads — and confirm the previously accepted malicious requests now return a consistent error code (400/403) without leaking stack traces. Then execute the regression matrix: legitimate signing flows must still succeed, multi-quorum approvals must complete, and revoked policies must stay revoked.

If the fix involves a new validation layer, add a negative test that probes the boundary (e.g., an extra field in the transaction object) to ensure the parser fails closed. Verification stops when the original finding is blocked, all legitimate flows pass, and no new error-class regressions appear in the logs. Document the outcome per endpoint so the triage team can close the report with confidence.

  1. Replay the original finding's request verbatim and confirm the expected error response.
  2. Run the full regression matrix across all three endpoints.
  3. Log any new validation errors introduced by the fix and confirm they are safe failures.

Sources: OWASP Web Security Testing Guide

Evidence Package Structured for Triage and Engineering

Assemble the final handoff as a single directory: a one-page summary (finding class, affected endpoints, impact scenario), the minimal reproducing request/response pair, the regression matrix results, and the conditional remediation options with their assumptions. Exclude exploratory dead ends, raw scanner output, or any data from out-of-scope hosts.

Reference the program's Vulnerability Rating Taxonomy and note where likelihood or impact modifiers might apply (e.g., sandbox-only vs. production key material). The goal is to give the Fireblocks engineering team everything needed to prioritize, fix, and verify without additional back-and-forth. No further engagement is implied; the package stands on its own.

  1. Create a summary document with finding class, endpoints, and sandbox impact scenario.
  2. Include only the minimal reproducing request/response and regression results.
  3. List remediation options with explicit assumptions and rollback paths.

Sources: OWASP Web Security Testing Guide

Sources & further reading

This post sets out a planned research approach using public program information. Actual findings follow the program’s reporting and disclosure process. Scope should be rechecked before testing.