Block Agent security record

The RewardsBank contract allows users to register campaigns. Each campaign requires a user to lock funds in exchange for reward tokens. Any user can register a new campaign, however only the contract's owner can fund the campaign, i.e. increase the rewards. The registerCampaign function, responsible for creating new campaigns, contains a validation logic that was meant to prevent recreating an already existing campaign. However, it was identified that the require statement implementing this logic will always return true, making the whole validation ineffective. As a consequence, multiple unintended scenarios may take form.New campaign is registered by a legitimate user - Alice. The contract's owner then funds this campaign, and another legitimate user, Bob, deposits tokens. At this point, there is a data structure representing the campaign. This structure identifies Alice as the campaign's owner. It also tracks a non-zero balance for a reward token, a locked token deposited by Bob, and also a non-zero value corresponding with the lock time. A malicious user can call the registerCampaign function again, using the _id used by Alice. The validation logic will pass, because the balance field will be greater than 0, and the campaign will effectively be taken over by the malicious user.Another potencial scenario may occur after a legitimate user registers a campaign. When this user is ready to deposit tokens or the admin is about to fund reward tokens, a malicious user may frontrun these transactions with a transaction of his own to reregister the campaign, effectively taking it over and eventually steal all the tokens.

The RewardsBank contract allows users to lock their tokens in the campaigns of their choosing. In exchange for locking their tokens for a specified amount of time, users will get potentially more tokens as a reward. The depositTokens function is responsible for locking the user's tokens. The depositTokens functions contains a verification mechanism that would prevent users from locking their tokens if another user already did so before. However, this verification is faulty, as it does not prevent users from locking their tokens in inactive campaigns. The function does not verify if the campaign was actually created, as it only checks if current balance of bbTokens field in a corresponding structure is equal to 0. This field will be equal to 0, even if the campaign does not exist, as 0 is the default value for uint256 type.Additionally, if the campaign does exist, but it is already over, i.e. the bbTokens were already withdrawn from a given campaign, the verification mechanism present in depositTokens functions will pass again making it possible for users to deposit into campaigns that are already over.

The Bonusblock's ERC721 contract implements a setTokenURI function that allows updating a given token's URI. The function is callable by anyone, however the arguments need to be signed and validated against a previously set public key. To prevent replay attacks, the contract utilizes nonces. However, it was observed that it does so incorrectly. The require statement is checking whether the nonce has already been used, and if it has, it allows the function to execute.

The Bonusblock's RewardsBank contract is responsible for handling the campaign logic. Each campaign requires funding. The fundCampaign function contains a require statement that was meant to assure that funding would be possible only for the existing campaigns. However, the check used for this verification checks if an uint256 value is bigger or equal to 0, which is always true. The vulnerability originates from the fact that mappings for keys that were not previously inserted will return default values. This principle applies to structs as well - making it return a structure with all of its members be default values.

Floating pragmas is a feature of Solidity that allows developers to specify a range of compiler versions that can be used to compile the smart contract code. For security purposes specifically, the usage of floating pragmas is discouraged and not recommended. Contracts should be compiled and deployed with a strict pragma, the one which was thoroughly tested the most by developers. Locking the pragma helps ensure that contracts do not accidentally get deployed using too old or too recent compiler versions that might introduce security issues that impact the contract negatively.It should be noted however that, pragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package.The smart contracts of Bonusblock's protocol make use of floating pragmas. These are not intended for use as libraries for other developers and, as such, should be locked of their pragma.

The MyToken ERC721 contract defines an updateKey function. It is used to update the publicKey variable, which in turn is used to verify signatures. However, the updateKey function is missing the length check on the provided newKey.

The constructor of the contract possesses the keyword payable, which means Ether can be sent to the contract during its deployment. However, any sent Ether may not be claimed as there is no implemented functionality that allows it.It should be noted that the severity of this finding has been reduced due to the fact that this may only happen during the deployment of the smart contract and by mistake.

It was observed that the RewardsBank contract defines a calculatePercentage function, however this function is not used anywhere in the contract.