Prepared by:
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
Table of Contents
- 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 Outdated versions of tls supported
- 7.2 Vulnerable third-party dependencies
- 7.3 Missing important security headers
- 7.4 Dependencies should be pinned to exact versions
- 7.5 Information disclosure in http headers
- 7.6 Absence of client-side control
- 8. Automated Testing
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
- 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.
- 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.
- 10 - CRITICAL
- 9 - 8 - HIGH
- 7 - 6 - MEDIUM
- 5 - 4 - LOW
- 3 - 1 - VERY LOW AND INFORMATIONAL
5. SCOPE
- b8a7686
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 analysis | Risk level | Remediation Date |
|---|---|---|
| OUTDATED VERSIONS OF TLS SUPPORTED | Medium | Solved - 12/06/2024 |
| VULNERABLE THIRD-PARTY DEPENDENCIES | Medium | Solved |
| MISSING IMPORTANT SECURITY HEADERS | Medium | Solved - 01/16/2025 |
| DEPENDENCIES SHOULD BE PINNED TO EXACT VERSIONS | Low | Solved |
| INFORMATION DISCLOSURE IN HTTP HEADERS | Low | Solved - 12/09/2024 |
| ABSENCE OF CLIENT-SIDE CONTROL | Informational | Solved - 12/09/2024 |
7. Findings & Tech Details
7.1 OUTDATED VERSIONS OF TLS SUPPORTED
//
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
Score
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
//
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:
Observe the public vulnerabilities of the third-party dependencies of the backend project inside the repository atlasprotocol (https://github.com/atlasprotocol-com/atlasprotocol/blob/76f86d0a37f4060373c29140db7638a1555effe0/backend/package.json):
Observe the public vulnerabilities of the third-party dependencies of the repository atlasvalidator (https://github.com/atlasprotocol-com/atlasvalidator/blob/3404d2fc79bb0166dfdd903e44e78b924f9f3b97/package.json):
Score
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
7.3 MISSING IMPORTANT SECURITY HEADERS
//
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
nosniffallows 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:
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:
Score
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
//
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
Observe the versioning of the third-party dependencies of the backend project inside the repository atlasprotocol (https://github.com/atlasprotocol-com/atlasprotocol/blob/76f86d0a37f4060373c29140db7638a1555effe0/backend/package.json):
"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"
}
}Observe the versioning of the third-party dependencies of the repository atlasvalidator (https://github.com/atlasprotocol-com/atlasvalidator/blob/3404d2fc79bb0166dfdd903e44e78b924f9f3b97/package.json):
"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
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
7.5 INFORMATION DISCLOSURE IN HTTP HEADERS
//
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:
Score
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
//
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:
The finding does not have impact (the transaction failed anyway).
Score
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
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:
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.
Table of Contents
- 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 Outdated versions of tls supported
- 7.2 Vulnerable third-party dependencies
- 7.3 Missing important security headers
- 7.4 Dependencies should be pinned to exact versions
- 7.5 Information disclosure in http headers
- 7.6 Absence of client-side control
- 8. Automated Testing
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed