Atlas Backend - Atlas Protocol


Prepared by:

Halborn Logo

HALBORN

Last Updated 02/17/2025

Date of Engagement: October 9th, 2024 - October 18th, 2024

Summary

100% of all REPORTED Findings have been addressed

All findings

6

Critical

0

High

0

Medium

3

Low

2

Informational

1


1. Introduction

Atlas engaged Halborn to conduct a security assessment of the Atlas web application beginning on 2024-10-09 and ending on 2024-10-18. The security assessment was scoped to the assets provided to the Halborn team.

2. Assessment Summary

The team at Halborn was provided one and a half weeks for the engagement and assigned a full-time security engineer to verify the security of the web application. The security engineer is a penetration testing expert with advanced knowledge in web, recon, discovery & infrastructure penetration testing and blockchain protocols.

The goals for this assessment are:

- Improve the security of the application by testing it as white-box approach

- Identify potential security issues that could be affecting the web application

In summary, Halborn identified three medium, two low and one informative security issues.

This security assessment focused on two parts. The review of the web application and backend source code, specifically the evaluation of the exposure and configuration of API endpoints, with focus on security implications. In this regard, the backend source code was found to contain a limited number of API endpoints, and all the endpoints were exclusively GET requests, which is usually a safer method for data retrieval since it should not alter server state. Some of these endpoints accepted parameters, but they were mainly related to obtain or filter non-sensitive information. It is important to note that pagination should take place in the returned response of the server, in order to avoid Denial-of-Services problems related to long processing times. In the code, the pagination system is not implemented, yet it is planned to be implemented.

In the other section of the assessment, the validator node, no important logical vulnerabilities were found in it. However, since the validators manage very sensitive information, it is important to note several things regarding security. This analysis highlights key factors that are crucial to maintaining the security and integrity of the validators:

    • Secure sources of truth: a critical part of validator security is the assumption that all sources of truth are accurate and secure. Validators obtain information about networks such as NEAR.

    • Code integrity: ensuring that the code running on each validator node is tamper-free is essential. Code integrity safeguards the validation process from being exploited. In this case, the validators can be run in a decentralized network, which is prone to some validators acting maliciously.

    • Single Private Key per validator: validator security is heavily dependent on the use of one Private Key per validator. It is important that a validator is only able to validate the transaction one time, and not more.

    • Limited functionality - validation only: validators are designed to strictly perform validation tasks, without any capability to execute other operations (such as transaction execution). It is important that they are not allowed any other functionality inside the Smart Contract.

    • Secrets held by validators: validators have access to sensitive information, such as private keys. Protecting these secrets is paramount to ensuring validator integrity. If the validator integrity cannot be assured, then it is important to ensure that this sensitive information is as minimal as possible.

Other than that, during the security assessment, other several vulnerabilities were identified regarding the repositories source code, including the presence of vulnerable third-party dependencies. In the web application scope, the usage of weak encryption ciphers or the leakage of sensitive technical information in the headers returned by the server was found.

It is recommended to resolve all the security issues listed in the document to improve the security health of the application and its underlying infrastructure.

3. Test Approach and Methodology

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process and implementation; automated testing techniques help enhance coverage of the code and can quickly identify items that do not follow security best practices.

Several tests were carried out during the assessment; including, but not limited to:

- Vulnerable or outdated software or dependencies

- Brute force protections

- Access Handling

- Input Handling

- Source code audit

- Fuzzing of all input parameters

- Sensitive information disclosure

- Application Logic Flaws

- Identify other potential vulnerabilities that may pose a risk to Atlas

4. RISK METHODOLOGY

Vulnerabilities or issues observed by Halborn are ranked based on the risk assessment methodology by measuring the LIKELIHOOD of a security incident and the IMPACT should an incident occur. This framework works for communicating the characteristics and impacts of technology vulnerabilities. The quantitative model ensures repeatable and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the Risk scores. For every vulnerability, a risk level will be calculated on a scale of 5 to 1 with 5 being the highest likelihood or impact.
RISK SCALE - LIKELIHOOD
  • 5 - Almost certain an incident will occur.
  • 4 - High probability of an incident occurring.
  • 3 - Potential of a security incident in the long term.
  • 2 - Low probability of an incident occurring.
  • 1 - Very unlikely issue will cause an incident.
RISK SCALE - IMPACT
  • 5 - May cause devastating and unrecoverable impact or loss.
  • 4 - May cause a significant level of impact or loss.
  • 3 - May cause a partial impact or loss to many.
  • 2 - May cause temporary impact or loss.
  • 1 - May cause minimal or un-noticeable impact.
The risk level is then calculated using a sum of these two values, creating a value of 10 to 1 with 10 being the highest level of security risk.
Critical
High
Medium
Low
Informational
  • 10 - CRITICAL
  • 9 - 8 - HIGH
  • 7 - 6 - MEDIUM
  • 5 - 4 - LOW
  • 3 - 1 - VERY LOW AND INFORMATIONAL

5. SCOPE

Files and Repository
(a) Repository: atlasprotocol
(b) Assessed Commit ID: 5749e1b
(c) Items in scope:
  • backend/
Out-of-Scope:
Files and Repository
(a) Repository: atlasvalidator
(b) Assessed Commit ID: 3404d2f
(c) Items in scope:
    Out-of-Scope:
    Remediation Commit ID:
    • b8a7686
    Out-of-Scope: New features/implementations after the remediation commit IDs.

    6. Assessment Summary & Findings Overview

    Critical

    0

    High

    0

    Medium

    3

    Low

    2

    Informational

    1

    Impact x Likelihood

    HAL-01

    HAL-02

    HAL-03

    HAL-04

    HAL-05

    HAL-06

    Security analysisRisk levelRemediation Date
    OUTDATED VERSIONS OF TLS SUPPORTEDMediumSolved - 12/06/2024
    VULNERABLE THIRD-PARTY DEPENDENCIESMediumSolved
    MISSING IMPORTANT SECURITY HEADERSMediumSolved - 01/16/2025
    DEPENDENCIES SHOULD BE PINNED TO EXACT VERSIONSLowSolved
    INFORMATION DISCLOSURE IN HTTP HEADERSLowSolved - 12/09/2024
    ABSENCE OF CLIENT-SIDE CONTROLInformationalSolved - 12/09/2024

    7. Findings & Tech Details

    7.1 OUTDATED VERSIONS OF TLS SUPPORTED

    //

    Medium

    Description

    Several misconfigurations were identified within the application's TLS configuration that could compromise the security of communications.

    Scoped URLs in the application have been identified to support the deprecated and vulnerable versions of TLS: v1.0 and TLS v1.1. These versions are no longer deemed secure due to numerous cryptographic design flaws. As technology advances, so does the capability to exploit these vulnerabilities. While current attacks targeting weak cipher suites or vulnerable algorithms might seem sophisticated and complex, the relentless growth in computational power means these attacks will only become more feasible and straightforward to execute as time goes on.

    These outdated TLS versions have been superseded by newer versions (e.g., TLS v1.3) which provide enhanced security features and address many of the vulnerabilities found in their predecessors. By supporting these older versions, the application not only endangers the integrity and confidentiality of data in transit but also risks non-compliance with modern security standards and regulations.

    Specifically, the risks of using these deprecated TLS versions include but are not limited to:

    - Cipher Suite Attacks: Adversaries can exploit weak cipher suites to decrypt sensitive data.

    - Session Hijacking: Vulnerabilities in older versions can allow attackers to hijack a user's session.

    - Man-in-the-Middle Attacks: An attacker can intercept and possibly alter the communication between two parties without either party noticing.

    Proof of Concept

    Observe the TLS protocols enabled in the affected servers:

    • https://audit.atlasprotocol.com

    TLS procotols enabled in https://audit.atlasprotocol.com
    Score
    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N(6.5)
    Recommendation

    It is recommended to review and update the TLS configuration across all servers according to the following best practices:

    - Disable support for outdated protocols such as TLS 1.0 and TLS 1.1.

    - Remove support for weak cipher suites.

    - Use strong encryption methods, ensuring key lengths of at least 256 bits for symmetric encryption and 4096 bits for RSA. For ECC algorithms, use a minimum key size of 512 bits.

    Remediation

    SOLVED: The Atlas team solved this issue.

    References

    7.2 VULNERABLE THIRD-PARTY DEPENDENCIES

    //

    Medium

    Description

    The scoped repository uses multiple third-party dependencies. Using vulnerable third-party libraries can result in security vulnerabilities in the project that can be exploited by attackers. This can result in data breaches, theft of sensitive information, and other security issues. However, some of them were affected by public-known vulnerabilities that may pose a risk to the global application security level.

    Proof of Concept

    Using the command npm audit:

    Third-party dependencies vulnerabilities of repositoryThird-party dependencies vulnerabilities of repository
    Score
    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N(5.4)
    Recommendation

    Update all affected packages to its latest version.

    It is strongly recommended to perform an automated analysis of the dependencies from the birth of the project and if they contain any security issues. Developers should be aware of this and apply any necessary mitigation measures to protect the affected application.

    Remediation

    SOLVED: The Atlas team solved this issue.

    Remediation Hash
    b8a768634e6e709585720f40705dd4dc73ce9f95

    7.3 MISSING IMPORTANT SECURITY HEADERS

    //

    Medium

    Description

    The application lacks several important HTTP security headers, which are instrumental in enhancing the security posture of web applications by instructing browsers on how to behave when handling the site's content. The absence of these headers leaves the application vulnerable to various attack vectors, including Man-in-the-Middle (MITM) attacks, Cross-Site Scripting (XSS), clickjacking, and MIME-type sniffing.

    Missing security headers:
    • Strict-Transport-Security: the lack of the HTTP Strict Transport Security (HSTS) header exposes the application to MitM attacks by allowing the use of insecure HTTP connections.

    • Content-Security-Policy (CSP): without a CSP header, the application is more susceptible to XSS attacks as it fails to restrict the sources of content that the browser can load.

    • X-Frame-Options: the absence of the X-Frame-Options header increases the risk of clickjacking attacks by allowing the site to be framed by potentially malicious third-party sites.

    • X-Content-Type-Options: not implementing the X-Content-Type-Options header with nosniff allows the browser to MIME-sniff the content type, which can lead to incorrect execution of non-script MIME types as scripts.

    Proof of Concept

    In the images below, it is possible to observe the security headers returned by the servers in the response:

    • https://audit.atlasprotocol.com: the server does not return the Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or X-Content-Type-Options headers:

    Headers returned by the server
    • https://api-audit.atlasprotocol.com: the server does not return the Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or X-Content-Type-Options headers:

    Headers returned by the server
    Score
    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N(4.2)
    Recommendation

    It is recommended to implement the missing HTTP security headers with appropriate policies. Implementing these security headers will significantly enhance the security of the application by preventing various web-based attacks and ensuring safer interactions with the user's browser.

    Remediation

    SOLVED: The Atlas team solved this issue.

    References

    7.4 DEPENDENCIES SHOULD BE PINNED TO EXACT VERSIONS

    //

    Low

    Description

    The application contained multiple dependencies that were not pinned to an exact version, but they were set to a supported version (ˆx.x.x). This could potentially allow dependency attacks.

    Proof of Concept
      "dependencies": {
        "@bitcoinerlab/secp256k1": "^1.1.1",
        "@cobo/cobo-waas2": "^1.2.1",
        "@ethereumjs/common": "^4.3.0",
        "@ethereumjs/tx": "^5.3.0",
        "@ethereumjs/util": "^9.0.3",
        "bitcoinjs-lib": "^6.1.6",
        "cors": "^2.8.5",
        "dotenv": "^10.0.0",
        "ethers": "^6.13.1",
        "express": "^4.18.3",
        "json-bigint": "^1.0.0",
        "near-api-js": "^5.0.0",
        "node-cron": "^3.0.3",
        "openssl": "^2.0.0",
        "viem": "^2.18.2",
        "web3": "^4.11.0"
      }
    }
        "dependencies": {
            "@bitcoinerlab/secp256k1": "^1.1.1",
            "@ethereumjs/tx": "^5.3.0",
            "@ethereumjs/util": "^9.0.3",
            "axios": "^1.6.8",
            "bitcoinjs-lib": "^6.1.6",
            "ethers": "^6.13.1",
            "near-api-js": "^5.0.0",
            "viem": "^2.18.2",
            "web3": "^4.11.0"
        }
    }
    Score
    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N(3.7)
    Recommendation

    The repository dependencies in the package.json file should be pinned to exact versions to prevent dependency attacks.

    Remediation

    SOLVED: The Atlas team solved this issue.

    Remediation Hash
    b8a768634e6e709585720f40705dd4dc73ce9f95

    7.5 INFORMATION DISCLOSURE IN HTTP HEADERS

    //

    Low

    Description

    This vulnerability occurs when sensitive information is unintentionally exposed within the HTTP headers of server responses. This vulnerability allows attackers to gain access to information that can aid in further attacks, such as the version of the web server, framework details, software versions, etc.

    Proof of Concept

    In the images below, it is possible to observe the headers returned by the servers in the response:

    • https://api-audit.atlasprotocol.com: the Server and X-Powered-By headers return specific information about versions and technologies used:

    Headers returned by the server
    Score
    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N(3.7)
    Recommendation

    To remediate this vulnerability, we recommend avoiding returning specific versions or technology information in the HTTP headers of the servers responses.

    In addition, it is recommended regularly update the server and application software to the latest version, as new security patches and updates are often released to address known vulnerabilities.

    Remediation

    SOLVED: The Atlas team solved this issue.

    7.6 ABSENCE OF CLIENT-SIDE CONTROL

    //

    Informational

    Description

    Even if user input controls should be established at least in the backend side, it is important to ensure that client-side controls also work as expected.

    Proof of Concept

    During the security assessment, it was possible to input an invalid receiving address when staking sBTCs, leading to the transaction failing:

    Invalid address input

    The finding does not have impact (the transaction failed anyway).

    Score
    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:N(0.0)
    Recommendation

    Even if the finding does not have impact (the transaction failed), it is important to ensure that only logically valid transactions are sent to their processing.

    Remediation

    SOLVED: The Atlas team solved this issue.

    Remediation Hash
    b8a768634e6e709585720f40705dd4dc73ce9f95

    8. Automated Testing

    Static Analysis Report
    Description

    Halborn utilized automated security scanners to detect well-known security issues and vulnerabilities in the codebase. The tools used included npm audit, SonarQube, Semgrep, CodeQL, NodeJsScan, Snyk, detect-secrets and whispers. These tools helped identify potential security flaws by performing static code analysis and vulnerability scanning on the project’s dependencies and source code.

    The security assessment included both automated and manual testing methodologies. Automated testing involves static code analysis and vulnerability scanning using specialized tools to identify potential security flaws. Manual testing complemented these efforts through comprehensive code walkthroughs, which focused on identifying security anti-patterns, verifying adherence to best practices, and ensuring compliance with coding standards. The assessment also involved evaluating the implementation of security controls and thoroughly reviewing the codebase for common vulnerabilities. Below are some example screenshots of the automated tools used during the assessment:

    Use of CodeQLUse of detect secretsUse node NodeJSscanUse of semgrepUse of SnykUse of SonarQubeUse of Whispers

    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.

    © Halborn 2025. All rights reserved.