code423n4 commented 1 year ago

Lines of code

https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/QuestFactory.sol#L222 https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/QuestFactory.sol#L223 https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/QuestFactory.sol#L210

Vulnerability details

Description

In the mintReceipt function there is a check of the claimSignerAddress signature:

if (keccak256(abi.encodePacked(msg.sender, questId_)) != hash_) revert InvalidHash();
if (recoverSigner(hash_, signature_) != claimSignerAddress) revert AddressNotSigned();

The signature used in claimSignerAddress may be reused in other smart contracts. Basically, if the QuestFactory is deployed on different networks (Goerli/Ethereum mainnet/Arbitrum/Optimism/Polygon) the same signature will be valid and may be replayed.

Moreover, the signed message is that simple, which may have a collision with other dApps.

Attack scenario

The attacker sees the signature of the claimSignerAddress account on another chain/another contract and uses it to call mintReceipt function.

Impact

Let's assume that claimSignerAddress is the same for different instances of QuestFactory in different chains. Then an attacker may use the signature on a different chain for which the signature wasn't expected to be.

Recommended Mitigation Steps

Use the EIP-712 scheme to avoid signature replayability.

c4-judge commented 1 year ago

kirk-baird marked the issue as duplicate of #45