Normal behavior:
set_secret
lets a signer create or update their own Vault
containing a secret.
get_secret
is supposed to allow only that same signer to retrieve it.
Specific issue:
get_secret
takes an arbitrary caller: address
parameter instead of being signer-bound.
The only check is assert!(caller == @owner, NOT_OWNER)
, which validates the argument against the stored vault but does not confirm that the transaction signer is the same as caller
.
Any user can read another user’s secret simply by supplying their address.
Likelihood:
Any external account can call get_secret(@victim)
because it’s not restricted to a signer.
The module doesn’t use capabilities or ownership checks tied to the signer.
Impact:
All secrets stored with set_secret
can be exfiltrated by anyone.
Breaks all confidentiality and any protocol relying on secure storage.
a)
Alice set the secret.
An attacker Bob can use the commande-line to retrieve the secret
aptos move view --function-id <program address>::vault::get_secret --args address:<owner address>
b) With code
Make get_secret
signer-bound just like set_secret
. Remove the untrusted caller
parameter and read the vault based on address_of(user)
.
This guarantees only the owner of a vault can retrieve its secret, matching the secure pattern already used by set_secret
.
Reference: https://aptos.dev/build/smart-contracts/move-security-guidelines
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.