During the time frame of February 28 to April 15, 2022, Shellboxes was tasked by NAOS Finance limited to assess the security of the NAOS Finance protocol. Our examination involved a systematic evaluation of the potential security risks related to the utilization of smart contracts. Our approach spotlighted any mismatch between the code and design of the smart contracts and proposed further enhancements to optimize the code. Our findings indicated that despite numerous security and performance problems, there is still room for improvement in the current version of smart contracts.
NAOS Finance is a decentralized lending protocol that allows individuals to borrow crypto-native assets using real-world assets as collateral. With a vast network of corporate borrowers and financing licenses in various regions, NAOS aims to bridge the gap between centralized and decentralized finance. By taking an ecosystem approach, the company is looking to establish strategic partnerships to expand the scope of decentralized finance and create a more interconnected network of financial services.
The ShellBoxes team was faced with the challenge of balancing various important factors such as speed, efficiency, accuracy, and scope when conducting their security testing. To address this challenge, they decided to use a combination of both manual and automated testing methods.
Manual testing was considered essential for detecting errors in logic, procedure, and execution. It also played an important role in verifying the protocol’s invariants from the business logic to ensure that they aligned with the code implementation. This level of manual scrutiny was deemed necessary to ensure that any potential security threats were identified and addressed.
On the other hand, automated testing was utilized to broaden the scope of the security assessment and to quickly detect any code that did not comply with the established security best practices. Automated testing allowed the ShellBoxes team to cover a larger surface area and detect any potential security issues at a much faster pace.
In this way, the team was able to strike a balance between speed, practicality, accuracy, and scope, thereby ensuring that the security evaluation was comprehensive and thorough.
The smart contracts used by NAOS Finance, which are a fork of the OlympusDAO, are generally well-designed and constructed. However, during the evaluation process, several vulnerabilities of varying severity were identified, including 2 high-severity, 2 medium-severity, and 3 low-severity issues. To optimize and improve the overall security of the contracts, NAOS Finance is advised to address and resolve these discovered flaws in their implementation. By leveraging the fork of the OlympusDAO, NAOS Finance can benefit from the established security features and protocols provided by the parent project, making it a crucial aspect of the overall safety and stability of the platform. Nevertheless, it is still essential to continuously monitor and update the contracts to mitigate any potential risks.
The first one was about a missing verification of the boolean returned value of the transfer call, the ERC20 standard token implementation returns the result of a transaction as a boolean value, indicating whether the transaction was successful or not. To guarantee that the intended actions are carried out correctly, it is crucial for developers to check the return status of the function calls and use the require() statement to enclose them. This will ensure that, in case the intended ERC20 function returns false, the caller transaction will also fail, avoiding situations where the token transfer did not pass but the transaction still succeeds.
The second one is a centralization risk where the Policy have super control over the treasury. The withdraw() function allows the policy to send any amount of any token to any destination from the treasury balance. This poses a significant threat as the policy holds too much control over the treasury funds and its usage. It is imperative to ensure that proper checks and balances are in place to mitigate the potential misuse of these funds.
In the examination of the project, two medium-severity issues were discovered. The first issue is that the restriction in the setAdjustment() function, which ensures that the policy cannot increment the rate by more than 3, can be bypassed. This occurs when the policy calls the setAdjustment() function with the addition argument set to true and then calls the deposit() function multiple times, causing the controlVariable to be incremented each time by the rate value. The second issue is the possibility of desynchronization in the deposit function, where the policy can add a new CustomBond contract and have it call the deposit function, causing a desynchronization between the bond and treasury contracts.
The low severity issues identified include the missing address verification and the floating pragma. The missing address verification was found in certain functions of the project, which lack a safety check for the address-type argument, resulting in the possibility of some of the contract’s functionality becoming inaccessible. Additionally, the contract makes use of the floating-point pragma 0.7.5. However, it’s advisable to lock the pragma version and deploy the contract using the same compiler version and flags that were used during the testing process to prevent potential issues from being introduced into the contract system.
In the section regarding best practices, it was suggested to use the latest version of Solidity for the contract implementation. The current pragma version used in the contract is 0.7.5, however, there are newer versions available that offer breaking changes such as overflow protection, revert opcode after failing assertions, and internal checks like division by zero or arithmetic overflow, along with explicit conversions between literals and address types. Utilizing the latest version of Solidity is recommended to take advantage of these new features and improve the security of the contract system.
In this initial phase of NAOS Finance, the design and implementation of the contracts were thoroughly examined. Our auditors at Shellboxes discovered a number of issues with varying levels of severity. The NAOS Finance team has been proactive in addressing four issues raised in our initial report and has implemented the necessary fixes to address these concerns.
However, there were some remaining issues that were deemed as low-probability risks. It’s essential for the NAOS Finance team to continue to maintain a vigilant approach to ensure that these findings are kept in mind and addressed appropriately to prevent any future complications. Our auditors at Shellboxes advise the NAOS Finance team to stay aware of these issues and take proactive measures to mitigate any potential risks.
© 2024 ShellBoxes All Rights Reserved
