Fuzzing Test
Last updated
Last updated
Salus Lightning Cat also utilizes fuzzing test techniques for smart contract vulnerability detection, primarily focusing on ERC20 and ERC721 token contracts. We have identified common properties among these token contracts. For example, in ERC20 token contracts, “Total supply should be constant for non-mintable and non-burnable tokens”, “No user balance should be greater than the token's total supply”, “Token balance for address zero should be zero”. Regarding ERC721, “Calling balanceOf for the zero address should revert”, “approve() should revert on invalid token”, “transferFrom() should revert if caller is not operator”.
We then convert these common properties into invariants and assert them. This means that for each token contract, regardless of the input data, these properties should always be satisfied. If they are not, it indicates potential risk points that require further investigation and remediation.
Below, using the contract with address 0x68a75A553f49456885201c398cf1EFC38FB43073 from ethereum-sepolia as an example, the Lighting Cat tool is used to perform fuzzing test on it. In this case, you're utilizing the "Fuzzing test enhancement mode" and selecting the contract type as either ERC20 or ERC721. Additionally, this mode is compatible with contract compiler versions 0.8.13 and above.
"Assertion failed in fuzzing test" indicates the result of the fuzzing test. The reported results are as follows:
First, the assertion "Token transfers should not be possible when paused state is enabled." does not hold.
To verify the accuracy of this test result, we conducted an analysis from the perspective of the contract source code:
In the contract source code, the whenNotPaused modifier of _beforeTokenTransfer() is commented out, allowing users to transfer funds even when the contract is in a paused state. Our fuzzing test captured this anomaly.
Secondly, when calling the approve function, the input parameters are 0xa329c0648769a73afac7f9381e08fb43dbea72 and 79965918454956297384049328077319630464904949584756755868997305507459849350080, the condition "Token `transferFrom`s should not be possible when paused state is enabled." is not hold.
Both of these vulnerabilities are classified as High.