GivingThanks:updateRegistry
is unprotected, allowing any attacker to replace the registry contract, which can lead to Denial of Service (DoS) and token minting exploits through reentrancy attacks.
The GivingThanks:updateRegistry
enables attackers to take control over the Registry
. In combination with GivingThanks:donate
, this enables to deny or increase gas cost for donations to legit Charities
or bypass Bad Charities
through isVerified
function. Therefore, allowing Malicious Contracts
repeatedly reenter donations
.
Legitimate charities
might be denied, and reentrancy vulnerabilities could exploit the minting mechanism or alter the tokenCounter order.
Manual Review and static analysis
DOS Scenario
Attacker: Creates a Malicious Register
.
Attacker: Updates GivingThanks:Registry
,
Donor: Calls donate
.
Malicious Register: Charge with higher gas or deny isVerified
condition.
Charity: Receives donation or not.
2: Reentrancy and Minting Scenario
Attacker: Creates a Malicious Register
and Malicious Charity
.
Attacker: Updates GivingThanks:Registry
,
Attacker: Calls donate
to Malicious Charity
.
Malicious Register: Bypasses isVerified
condition.
Malicious Charity: receives donation then reenters donate
to himself, mining n
tokens desired.
Add owner requirement to proceed Registry
update.
protect donate
with NonReentrant modifier.
cache tokenCounter before transfer.
Impact: High, one charity can reenter the donate function with the same ETH provided and mint several NFT. Likelyhood: Low, any malicious charity can do it but Admin is trusted and should verify the charity contract before "verifying" it.
Likelyhood: High, anyone can change it at anytime Impact: High, can bypass the verification process
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.