Cube3 security record

In several places across the codebase, contracts reference addresses of other contracts. A validation is performed that simply verifies whether these addresses are equal to the zero-address. This assures calling only an existing address in the blockchain, however, it does not ensures that this address is able to properly receive the call. Such validation is performed via ERC165's supportsInterface() function which makes sure that a given address implements an expected interface. Additionally, such a validation indirectly asserts that the the given address is a not a zero-address.

OpenZeppelin implements several standards used all across blockchain development, especially in Solidity and the Ethereum Virtual Machine. These standards primary goal is to unify and normalize development patterns so that the entire blockchain may be more understandable and readily usable.The Cube3 smart contracts implement source code that mimics or is very similar to components already implemented by OpenZepellin, and could therefore, be switched with the more the standard well-known approach. Such source code is included in:RouterStorage.sol contract pausability features, can be substituted with OpenZeppellin's implementation of PausableUpgradeable.It should be noted that the usage of bigger libraries does not constitute an overuse of gas, since only the functions that are used are included on the bytecode of the smart contract.

It was observed that in certain scenarios it is possible to bypass one REVOKED integration status via another REGISTERED one. The scenario is as follows:Suppose there are two integrations connected to the protocol, one of them is REGISTERED and another one is REVOKED.The malicious owner of a REVOKED integration colludes with the corruptible owner of a REGISTERED integration.The REGISTERED integration calls the function routeToModule directly, however using the arguments received from the REVOKED integration.This results in a REGISTERED integration using the Cube3 protocol for the REVOKED one's benefit effectively bypassing the REVOKED status.It should be noted that any future modules that do not make use of msg.sender will be more impacted by this finding.

The function validateSignature() in the signature module is used for validating the signature present in the cube3SecurePayload. This signature is generated with multiple input parameters, while bearing in mind two important variables. One of them is a boolean value identifying whether nonce tracking is enabled or not, and another is the respective nonce if the tracking is indeed enabled.The fact that it is possible for a customer to choose whether they enable nonce tracking or not, a possibility to be vulnerable to signature replay attacks is presented. When nonce tracking is disabled, signatures can be replayed.For example, if a customer protected function implements logic for a user to receive 10 tokens, but nonce tracking was forgetfully left disabled, the same user can use the same signature and retrieve 10 more tokens an infinite number of times.