Possible attack method, what am I missing?

English Community Technical Support
1

This occurred to me, whilst experiencing a problem that I’ve posted about.
Scenario:

Attacker learns victims wallet address. Attacker mints a few thousand tokens with long asset names to their wallet (mint or mint & batched transfer) rendering the victims wallet unusable. Attacker informs victim what they did. Attacker proves their identify by minting unique asset. Attacker demands ransom to burn assets.

Victims wallet will be unusable because the output tx will be over 16KB and victim will get OutputTooBigUTxO / MaxTxSizeUTxO when trying to send anything.

This is pretty bad, or am I missing something?

2 Likes
2

the attacker would need the victim’s wallet keys to burn as this cannot be done remotely without possession of BOTH the policy and the target asset which to burn (which is not in the attackers wallet)

so first and foremost there’s no incentive

and at the end of the day, wallets can adapt to simply ignore using “whack” utxos as tx inputs

1 Like
3

@ADAfrog is correct that a wallet would need to just ignore the offending UTxO. The attack could be a big annoyance for users of wallet software that cannot handle this, but the other UTxOs at the address are still safe.

However, defending against an attack like this is a serious consideration for smart contracts whose logic allows consuming its UTxO(s) in a transaction that also outputs to the smart contract. (I’ve been calling it a “nuisance token attack”, but it might have another name.) If the smart contract holds a token whose UTxO has a datum with part of the contract’s state, then such at attack might be able to lock the contract’s token with the other nuisance tokens into an unspendable UTxO: this would disable the contract. For example, the oracle that I’ve been running on mainnet specifically prevents this attack by rejecting nuisance tokens.

1 Like
4

@ADAfrog I see - not really viable as a profitable attack then. It’s not like you could just send the nuisance policy and expect a user to burnt the tokens either.

@bwbush I see, I’m glad to know that it’s been considered.

1 Like
5

Moving away from secrets that are injected at build time to using a runtime secret store. This is part of a larger project to better handle configuration management in our data center environments. In our Azure environments, we already use KeyVault and AppConfig to do this.