Summary

Since users are supposed to send ERC 20 tokens to an address, and then later deploy a contract with that address to distribute funds, A malicious entity can steal the tokens as long as they know the address of a Proxy contract that will be deployed in the future. Which is made public knowledge every time anyone calls getProxyAddress()

Vulnerability Details

Alice calls getProxyAddress() and sends 1000 USDC to the outputted address as the reward for a new contest. Bob who is watching the contract sees this and quickly deploys to the Proxy address in order to steal the 1000 USDC.

Impact

Rewards meant for contest winners would be stolen.

Furthermore, if the malicious user self-destructs the contract after stealing the funds, the user/admin of the protocol would be able to deploy the Proxy, but couldn't distribute the funds.

Double furthermore, if a Proxy has been hijacked and the Sparkn owner tries to call distibuteByOwner(), they would be making a function call with data to a malicious contract. The logic inside the malicious contract could make the owner interact with additional contracts/functions they don't want to. More simply, they could just cause the owner to spend all their gas.

Tools Used

Manual review and Remix IDE

Recommendations

There are multiple different options to fix this issue, one would be to calculate the Proxy address in a different more secure way that doesn't expose what the addresses of the future will be to the entire blockchain, maybe as a part of the off-chain components the protocol has. Another way would be to change how the rewards are distributed, instead of sending them to the Proxy before being deployed, you could send rewards to the ProxyFactory or another contract, then when the Proxy is deployed the ProxyFactory/other contract would send the rewards to the Proxy and call distribute().