Audit name:
[SCA] Tibia / Token / Oct2024
Date:
Nov 14, 2024
Table of Content
Introduction
We express our gratitude to the CipSoft team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Tibia is a long-standing European MMORPG where players globally engage in virtual exploration, puzzle-solving, and heroic adventures. It offers an immersive online experience through diverse landscapes and collaborative challenges. Tibia Tokens can be converted from and to Tibia Coins, Tibia's in-game currency.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for CipSoft |
| Audited By | Kornel Światłowski, Paul Clemson |
| Approved By | Grzegorz Trawinski |
| Website | https://www.tibia.com/→ |
| Changelog | 31/10/2024 - Preliminary Report; 07/11/2024 - Final Report |
| Platform | BNB Smart Chain (BSC) |
| Language | Solidity |
| Tags | ERC20, Permit Token, Signatures |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for CipSoft
- Audited By
- Kornel Światłowski, Paul Clemson
- Approved By
- Grzegorz Trawinski
- Website
- https://www.tibia.com/→
- Changelog
- 31/10/2024 - Preliminary Report; 07/11/2024 - Final Report
- Platform
- BNB Smart Chain (BSC)
- Language
- Solidity
- Tags
- ERC20, Permit Token, Signatures
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/CipSoft-Tibia/TibiaToken→ |
| Commit | e9ab1a294682d6c32f7f4c504a9eb344119b1a49 |
Review Scope
- Commit
- e9ab1a294682d6c32f7f4c504a9eb344119b1a49
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description is provided (Detailed NatSpec description).
Code quality
Best practice violations.
The development environment is configured.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
The TibiaToken contract is an upgradeable ERC-20 token with integrated pausable functionality, enabling the owner to halt transfers, minting, and burning operations when necessary. It supports gasless approvals through the ERC-20 Permit and provides controlled token minting and burning via MintPermitUpgradeable and BurnPermitUpgradeable modules. The maximal cap of tokens is not defined. Tibia Tokens can be converted from and to Tibia Coins, Tibia's in-game currency
The MintPermitUpgradeable contract facilitates controlled minting of Tibia Tokens via signatures compliant with the EIP-712 standard. It enables controlled minting by validating signatures from a designated CipSoft signer, with strict expiration and duplicate-use prevention for each permit.
The BurnPermitUpgradeable contract facilitates controlled burning of Tibia Tokens via signatures compliant with the EIP-712 standard. It enables controlled burning by validating signatures from a designated CipSoft signer, with strict expiration and duplicate-use prevention for each permit.
The CipSoftSignerUpgradeable contract provides a dedicated storage solution for managing a trusted CipSoft signing address, with controls allowing only the contract owner to modify it. This address is utilized for signature-based authorization processes in related contracts. The stored CipSoft address is used to verify that is provided signature was signed in MintPermitUpgradeable and BurnPermitUpgradeable contracts.
Privileged roles
The TibiaToken contract uses the Ownable2StepUpgradeable contract from OpenZeppelin to restrict access to key functions. The contract owner can:
Pause the smart contract. This disables mint, burn, and token transfer.
Unpause the smart contract.
Upgrade contract to the new implementation.
Set the CipSoft signing account.
Potential Risks
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Single Entity Upgrade Authority: The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
Signer Key Control Risks: The digital contract architecture relies on singer key for critical operations (mint and burn of tokens). Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.
Pausable Transfers: The contract owner retains the authority to pause token minting, burning, and transfers at any time.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6876 | Missing Storage Gaps | mitigated | Low | |
| F-2024-6862 | Potential Unauthorized Token Burn in burnPermit Due to Lack of msg.sender Check | fixed | Low | |
| F-2024-6860 | Private Function Names Do Not Follow Solidity Style Guide | fixed | Observation | |
| F-2024-6855 | Missing Events For Key Actions | fixed | Observation | |
| F-2024-6854 | Missing Checks for Zero Address in _setCipSoftSigner() | fixed | Observation | |
| F-2024-6853 | Some Public Functions Can be Declared as External | fixed | Observation | |
| F-2024-6851 | Redundant Imports and Inheritance | fixed | Observation | |
| F-2024-6850 | Missing Two-step Ownership Transfer Process | fixed | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/CipSoft-Tibia/TibiaToken→ |
| Commit | e9ab1a294682d6c32f7f4c504a9eb344119b1a49 |
| Whitepaper | - |
| Requirements | README.md |
| Technical Requirements | Nat Spec |
Scope Details
- Commit
- e9ab1a294682d6c32f7f4c504a9eb344119b1a49
- Whitepaper
- -
- Requirements
- README.md
- Technical Requirements
- Nat Spec
Assets in Scope
BurnPermitUpgradeable.solCipSoftSignerUpgradeable.solMintPermitUpgradeable.solTibiaToken.solAppendix 3. Additional Valuables
Verification of System Invariants
During the audit of Tibia, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 6 fuzzing scenarios were tested over 1,000,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Permit mint with random amount | Passed | 1,000,000 |
| Permit mint with random deadline | Passed | 1,000,000 |
| Permit mint with random ID | Passed | 1,000,000 |
| Permit burn with random amount | Passed | 1,000,000 |
| Permit burn with random deadline | Passed | 1,000,000 |
| Permit burn with random ID | Passed | 1,000,000 |
Invariant
- Permit mint with random amount
Test Result
- Passed
Run Count
- 1,000,000
Invariant
- Permit mint with random deadline
Test Result
- Passed
Run Count
- 1,000,000
Invariant
- Permit mint with random ID
Test Result
- Passed
Run Count
- 1,000,000
Invariant
- Permit burn with random amount
Test Result
- Passed
Run Count
- 1,000,000
Invariant
- Permit burn with random deadline
Test Result
- Passed
Run Count
- 1,000,000
Invariant
- Permit burn with random ID
Test Result
- Passed
Run Count
- 1,000,000
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.