Threat model for detecting Redeemer Asset Substitution vulnerabilities.

What vulnerability this detects

A Redeemer Asset Substitution Attack exploits validators that trust asset identifiers (policy IDs or token names) provided in the redeemer without proper validation against the datum or transaction context.

Attack scenario

Consider a validator that accepts a redeemer like:

SellRedeemer { sold_policy_id: ByteArray, sold_token_name: ByteArray }

And only checks:

// VULNERABLE: Trusts redeemer-provided asset without datum cross-check
let token = find_token_in_inputs(redeemer.sold_policy_id, redeemer.sold_token_name)
expect token.quantity > 0

Without verifying that the provided asset matches what was actually intended (e.g., a specific token name stored in the datum).

Real-world example: Purchase Offer CTF

The purchase_offer CTF contract stores a desired policy ID and an optional token name in the datum:

Datum { owner: Address, desired_policy_id: PolicyId, desired_token_name: Option<ByteArray> }

When desired_token_name is None, the validator accepts ANY token from that policy. An attacker can:

1. See an offer for a valuable NFT (e.g., "RareNFT") from policy P
2. Acquire a worthless token "WorthlessJunk" under the same policy P
3. Fulfill the offer with "WorthlessJunk" instead of "RareNFT"
4. Claim the locked ADA, leaving the victim with a worthless token

How this threat model works

This threat model uses a "swappable pair" approach that is Phase 1 valid:

1. Find a script input — a non-key address input being spent
2. Get its redeemer — extract the ScriptData redeemer
3. Extract ByteString fields — these are potential token names
4. Get all transaction outputs
5. Find the first output with a token (policyP, originalName) where originalName matches one of the redeemer ByteStrings
6. Find a second output (different from the first) containing a DIFFERENT token (policyP, otherName) from the SAME policy where otherName /= originalName
7. Swap the tokens between the two outputs: - Output1: remove (policyP, originalName), add (policyP, otherName) - Output2: remove (policyP, otherName), add (policyP, originalName)
8. Substitute the redeemer: replace originalName ByteString with otherName in the redeemer
9. Check validation: the modified transaction should NOT validate

If the modified transaction validates (accepting the swapped token names), the validator is vulnerable because it accepts any token name without cross-checking the datum.

Why Phase 1 validity matters

Cardano transactions go through two phases of validation:

• Phase 1: Ledger rules checking (value preservation, signatures, etc.)
• Phase 2: Script execution (Plutus validators)

Phase 1 enforces that total value in = total value out + fees. A transaction that claims to send a token that doesn't exist in any input would be rejected at Phase 1 before the validator script even runs.

By swapping EXISTING tokens between outputs (rather than inventing non-existent tokens), this threat model creates transactions that pass Phase 1 and actually reach the validator for Phase 2 execution. This tests the real attack scenario where an attacker possesses a worthless token from the same collection.

Preconditions required

The transaction must contain at least two different tokens from the same policy in different outputs. This naturally happens when:

• The wallet holds multiple tokens from the same policy (e.g., a valuable NFT and a worthless one from the same collection)
• Coin selection includes a UTxO containing extra tokens from the same policy
• The fulfill transaction sends one token to the contract owner and returns another as change

How to satisfy preconditions in TestingInterface

When writing a TestingInterface instance, the perform action for the relevant scenario should ensure the wallet holds multiple tokens from the same policy.

Example approach:

1. In the setup/mint action, mint BOTH a "valuable" token AND a "worthless" token from the same policy to the attacker's wallet
2. When the attacker calls perform on the fulfill action, coin selection will naturally include the UTxO containing both tokens
3. The fulfill transaction will have one token going to the contract owner's output and the other in the change output
4. The threat model can now find the swappable pair and test the vulnerability

This mirrors the real attack scenario: the attacker legitimately possesses a worthless token from the same NFT collection and uses it to fraudulently fulfill an offer meant for a valuable token.

Consequences of the vulnerability

1. Asset theft: Attackers fulfill offers with worthless tokens
2. Protocol manipulation: Wrong assets can satisfy contract conditions
3. Value extraction: Locked funds can be drained with substitute tokens

Mitigation

A secure validator should:

• Store specific asset identifiers (including token name) in the datum
• Always validate redeemer-provided values against datum or script context
• Never trust attacker-controlled redeemer data for asset identification
• Use token name in datum when specificity is required