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.