Prepared by:
HALBORN
Last Updated 04/25/2024
Date of Engagement by: April 1st, 2022 - April 8th, 2022
100% of all REPORTED Findings have been addressed
All findings
3
Critical
0
High
0
Medium
0
Low
1
Informational
2
\client engaged Halborn to conduct a security audit on their smart contracts beginning on 2022-04-01 and ending on 2022-04-08. The security assessment was scoped to the smart contracts provided to the Halborn team.
The team at Halborn was provided one week for the engagement and assigned a full-time security engineer to audit the security of the smart contract. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this audit is to:
Ensure that smart contract functions operate as intended
Identify potential security issues with the smart contracts
In summary, Halborn identified some security risks that were mostly addressed by the \client team.
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this audit. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the bridge code and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the audit:
Research into architecture and purpose
Smart contract manual code review and walkthrough
Graphing out functionality and contract logic/connectivity/functions (solgraph)
Manual assessment of use and safety for the critical Solidity variables and functions in scope to identify any arithmetic related vulnerability classes
Manual testing by custom scripts
Scanning of solidity files for vulnerabilities, security hotspots or bugs. (MythX)
Static Analysis of security for scoped contract, and imported functions. (Slither)
Testnet deployment (Brownie, Remix IDE)
IN-SCOPE: The security assessment was scoped to the following smart contracts:
ERC20ForwarderProxy.sol
ERC20ForwarderImplementationV2.sol
BiconomyForwarderV2.sol
ForwardRequestTypesV2.sol
FeeManager.sol
OracleAggregator.sol
Commit ID: 611203c53e0b225f0d1c64e8b75adf9e2fc7dd29 Fixed Commit ID: 11f8abf0c0b8c26ce7a21972b44d1c91a7c3f756
Critical
0
High
0
Medium
0
Low
1
Informational
2
Impact x Likelihood
HAL-01
HAL-02
HAL-03
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| OWNER CAN RENOUNCE OWNERSHIP | Low | Risk Accepted |
| ZERO ADDRESS NOT CHECKED | Informational | Solved - 04/12/2022 |
| MISSING EVENTS EMITTING | Informational | Solved - 04/12/2022 |
// Low
The Owner of the contract is usually the account that deploys the contract. As a result, the Owner can perform some privileged functions. In the ERC20ForwarderImplementationV2.sol, BiconomyForwarderV2.sol, FeeManager.sol and OracleAggregator.sol smart contracts, the renounceOwnership function is used to renounce the Owner permission. Renouncing ownership before transferring would result in the contract having no Owner, eliminating the ability to call privileged functions.
contract ERC20ForwarderImplementationV2 is Initializable, OwnableUpgradeable, ForwardRequestTypesV2 {
contract BiconomyForwarderV2 is ForwardRequestTypesV2, Ownable {
contract FeeManager is IFeeManager, Ownable{
contract OracleAggregator is Ownable{
RISK ACCEPTED: The Biconomy team accepted the risk of this issue.
// Informational
The function setTokenOracle within the contract OracleAggregator.sol is not verifying the callAddress parameter is not the zero address to avoid having issues retrieving the token price data feed.
function setTokenOracle(address token, address callAddress, uint8 decimals, bytes calldata callData, bool signed) external onlyOwner{
tokensInfo[token].callAddress = callAddress;
tokensInfo[token].decimals = decimals;
tokensInfo[token].callData = callData;
tokensInfo[token].dataSigned = signed;
}
SOLVED: The issue was solved in commit ID: 11f8abf0c0b8c26ce7a21972b44d1c91a7c3f756
// Informational
It has been observed that critical functionality is missing emitting event for setFeeManager function within the ERC20ForwarderImplementationV2.sol contract and the setTokenAllowed function within the FeeManager.sol contract. These functions should emit events after completing the transactions.
function setFeeManager(address _feeManager) external onlyOwner{
require(
_feeManager != address(0),
"ERC20Forwarder: new fee manager can not be a zero address"
);
feeManager = _feeManager;
}
function setTokenAllowed(address token, bool allowed) external onlyOwner{
allowedTokens[token] = allowed;
}
SOLVED: The issue was solved in commit ID: 11f8abf0c0b8c26ce7a21972b44d1c91a7c3f756
Halborn used automated testing techniques to enhance the coverage of certain areas of the scoped contracts. Among the tools used was Slither, a Solidity static analysis framework. After Halborn verified all the contracts in the repository and was able to compile them correctly into their ABI and binary formats, Slither was run on the all-scoped contracts. This tool can statically verify mathematical relationships between Solidity variables to detect invalid or inconsistent usage of the contracts' APIs across the entire code-base.
ERC20ForwarderProxy.sol ERC20ForwarderImplementationV2.sol ForwardRequestTypesV2.sol BiconomyForwarderV2.sol ForwardRequestTypesV2.sol FeeManager.sol OracleAggregator.sol
As a result of the tests carried out with the Slither tool, some results were obtained and reviewed by Halborn. Based on the results reviewed, some vulnerabilities were determined to be false positives. The actual vulnerabilities found by Slither are already included in the report findings.
Halborn used automated security scanners to assist with detection of well-known security issues, and to identify low-hanging fruits on the targets for this engagement. Among the tools used was MythX, a security analysis service for Ethereum smart contracts. MythX performed a scan on all the contracts and sent the compiled results to the analyzers to locate any vulnerabilities.
BiconomyForwarderV2.sol OracleAggregator.sol FeeManager.sol
No major issues were found by Mythx.
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed