Atlas NEAR - Atlas

Prepared by:

HALBORN

Last Updated Unknown date

Date of Engagement: October 14th, 2024 - October 25th, 2024

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Lacking recovery mechanism increases the risk of potential fund loss
7.2 Deposits guaranteed to fail may be re-executed repeatedly
7.3 Absence of two factor authentication for privileged functions
7.4 Exposed dangerous functions that could reset contract state
7.5 Centralization risk
7.6 Lack of mempool verification in deposit and redemption processes
7.7 Flawed logic allows deposits to be marked as minted without actually minting anything for the user
7.8 Missing input validation may result in corrupted deposits, leading to a loss of funds
7.9 Lacking pausability mechanism
7.10 Inadequate upper bound for protocol fees
7.11 Lack of state-updating upgrade functionality
7.12 Potential for atbtc to have different decimals from btc
7.13 Ineffective ownership transfer due to lack of external accessibility
7.14 Single-step ownership transfer process
7.15 Protocol fees are not incorporated into the contract logic
7.16 Unlocked pragma compiler
7.17 Public functions never called internally
7.18 Redundant state existence check during contract creation
7.19 Use of revert strings instead of custom error
7.20 Inefficient code
7.21 Misleading comment
7.22 Presence of typographical error
7.23 Possible optimizations to reduce binary size
7.24 Utility functions are made public unnecessarily
7.25 Deprecated and lacking tests

8. Automated Testing

1. Introduction

Atlas Protocol engaged Halborn to conduct a security assessment of the Atlas and atBTC token contracts for Near blockchain as well as the atBTC token for the EVM, beginning on October 14th, 2024, and ending on October 25th, 2024. This security assessment focused on the smart contracts within the Atlas Protocol Github repository.

Atlas Protocol is a BTC liquid staking protocol that allows users to deposit native Bitcoin and receive aBTC, a liquid staking token, on their chosen blockchain.

2. Assessment Summary

The team at Halborn assigned two full-time security engineers to verify the security of the smart contracts. The security engineers are blockchain and smart-contract security experts with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.

The purpose of this assessment is to:

Ensure that smart contract functions operate as intended.
Identify potential security issues with the smart contracts.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were successfully addressed by the Atlas Protocol team. The main ones were the following:

Implement an emergency withdrawal feature for users whose deposits remain invalidated after a specified period or are likely to fail due to persistent errors.
Implement an error filtering mechanism to ensure that deposits guaranteed to fail are not rolled back.
Enable Two-Factor Authentication (2FA) for all privileged actions.
Remove the state-resetting functions from the Atlas contract prior to deployment.

3. Test Approach and Methodology

Halborn performed a combination of the manual view of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques help enhance the coverage of smart contracts. They can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:

Research into the architecture, purpose, and use of the platform.
Manual code reading and walkthrough.
Manual assessment of the use and safety of critical Rust variables and functions to identify potential arithmetic vulnerabilities.
Cross-contract call controls.
Logical controls related to architecture.
Scanning of Rust files for vulnerabilities using tools like cargo audit.
Integration testing using the NEAR testing framework.

4. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

4.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A) Specific (AO:S)	1 0.2
Attack Cost (AC)	Low (AC:L) Medium (AC:M) High (AC:H)	1 0.67 0.33
Attack Complexity (AX)	Low (AX:L) Medium (AX:M) High (AX:H)	1 0.67 0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C)	0 0.25 0.5 0.75 1
Integrity (I)	None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C)	0 0.25 0.5 0.75 1
Availability (A)	None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C)	0 0.25 0.5 0.75 1
Deposit (D)	None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C)	0 0.25 0.5 0.75 1
Yield (Y)	None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C)	0 0.25 0.5 0.75 1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Severity	Score Value Range
Critical	9 - 10
High	7 - 8.9
Medium	4.5 - 6.9
Low	2 - 4.4
Informational	0 - 1.9

5. SCOPE

REPOSITORY

(a) Repository: atlasprotocol

(b) Assessed Commit ID: 46760b4

tokens/solidity_contract/atBTC.sol
tokens/src/lib.rs
tokens/Cargo.toml

↓ Expand ↓

Out-of-Scope: Third party dependencies and economic attacks.

Out-of-Scope: New features/implementations after the remediation commit IDs.

6. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Security analysis	Risk level	Remediation Date
Lacking Recovery Mechanism Increases The Risk Of Potential Fund Loss	Medium	Solved - 01/16/2025
Deposits Guaranteed To Fail May Be Re-Executed Repeatedly	Medium	Solved - 12/04/2024
Absence Of Two Factor Authentication For Privileged Functions	Medium	Solved - 12/04/2024
Exposed Dangerous Functions That Could Reset Contract State	Low	Solved - 01/09/2025
Centralization Risk	Low	Solved - 12/18/2024
Lack of Mempool Verification in Deposit and Redemption Processes	Low	Solved - 01/09/2025
Flawed Logic Allows Deposits To Be Marked As Minted Without Actually Minting Anything For The User	Low	Solved - 12/20/2024
Missing Input Validation May Result In Corrupted Deposits, Leading To A Loss Of Funds	Low	Solved - 12/03/2024
Lacking Pausability Mechanism	Low	Solved - 12/17/2024
Inadequate Upper Bound for Protocol Fees	Low	Solved - 12/03/2024
Lack Of State-Updating Upgrade Functionality	Low	Solved - 12/22/2024
Potential for atBTC to Have Different Decimals from BTC	Low	Solved - 12/03/2024
Ineffective Ownership Transfer Due to Lack of External Accessibility	Low	Solved - 12/02/2024
Single-Step Ownership Transfer Process	Low	Solved - 12/02/2024
Protocol Fees Are Not Incorporated Into The Contract Logic	Informational	Solved - 12/05/2024
Unlocked Pragma Compiler	Informational	Solved - 11/24/2024
Public Functions Never Called Internally	Informational	Solved - 11/26/2024
Redundant State Existence Check During Contract Creation	Informational	Solved - 12/03/2024
Use of Revert Strings Instead of Custom Error	Informational	Solved - 11/26/2024
Inefficient Code	Informational	Solved - 12/03/2024
Misleading Comment	Informational	Solved - 12/03/2024
Presence Of Typographical Error	Informational	Solved - 11/24/2024
Possible Optimizations To Reduce Binary Size	Informational	Solved - 12/03/2024
Utility Functions Are Made Public Unnecessarily	Informational	Solved - 12/19/2024
Deprecated And Lacking Tests	Informational	Solved - 12/19/2024

Remediation Comment

7.4 Exposed Dangerous Functions That Could Reset Contract State

Low

Description

Description

Proof of Concept

BVSS

AO:S/AC:L/AX:L/R:N/S:U/C:N/A:H/I:H/D:C/Y:N (2.8)

Recommendation

Remediation Comment

7.8 Missing Input Validation May Result In Corrupted Deposits, Leading To A Loss Of Funds

Low

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Lacking recovery mechanism increases the risk of potential fund loss
7.2 Deposits guaranteed to fail may be re-executed repeatedly
7.3 Absence of two factor authentication for privileged functions
7.4 Exposed dangerous functions that could reset contract state
7.5 Centralization risk
7.6 Lack of mempool verification in deposit and redemption processes
7.7 Flawed logic allows deposits to be marked as minted without actually minting anything for the user
7.8 Missing input validation may result in corrupted deposits, leading to a loss of funds
7.9 Lacking pausability mechanism
7.10 Inadequate upper bound for protocol fees
7.11 Lack of state-updating upgrade functionality
7.12 Potential for atbtc to have different decimals from btc
7.13 Ineffective ownership transfer due to lack of external accessibility
7.14 Single-step ownership transfer process
7.15 Protocol fees are not incorporated into the contract logic
7.16 Unlocked pragma compiler
7.17 Public functions never called internally
7.18 Redundant state existence check during contract creation
7.19 Use of revert strings instead of custom error
7.20 Inefficient code
7.21 Misleading comment
7.22 Presence of typographical error
7.23 Possible optimizations to reduce binary size
7.24 Utility functions are made public unnecessarily
7.25 Deprecated and lacking tests

Atlas NEAR

Atlas

Table of Contents

1. Introduction

2. Assessment Summary

3. Test Approach and Methodology

4. RISK METHODOLOGY

4.1 EXPLOITABILITY

Attack Origin (AO):

Attack Cost (AC):

Attack Complexity (AX):

Metrics:

4.2 IMPACT

Confidentiality (C):

Integrity (I):

Availability (A):

Deposit (D):

Yield (Y):

Metrics:

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Scope (S):

Metrics:

5. SCOPE

6. Assessment Summary & Findings Overview

7. Findings & Tech Details

7.1 Lacking Recovery Mechanism Increases The Risk Of Potential Fund Loss

Description

BVSS

Recommendation

Remediation Comment

7.2 Deposits Guaranteed To Fail May Be Re-Executed Repeatedly

Description

BVSS

Recommendation

Remediation Comment

7.3 Absence Of Two Factor Authentication For Privileged Functions

Description

BVSS

Recommendation

Remediation Comment

7.4 Exposed Dangerous Functions That Could Reset Contract State

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment

7.5 Centralization Risk

Description

BVSS

Recommendation

Remediation Comment

7.6 Lack of Mempool Verification in Deposit and Redemption Processes

Description

BVSS

Recommendation

Remediation Comment

7.7 Flawed Logic Allows Deposits To Be Marked As Minted Without Actually Minting Anything For The User

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment

7.8 Missing Input Validation May Result In Corrupted Deposits, Leading To A Loss Of Funds

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment

7.9 Lacking Pausability Mechanism

Description

BVSS

Recommendation

Remediation Comment

7.10 Inadequate Upper Bound for Protocol Fees

Description

BVSS

Recommendation

Remediation Comment

7.11 Lack Of State-Updating Upgrade Functionality