Prepared by:
HALBORN
Last Updated 04/26/2024
Date of Engagement by: September 9th, 2022 - October 7th, 2022
Summary
89% of all REPORTED Findings have been addressed
All findings
9
Critical
2
High
0
Medium
2
Low
3
Informational
2
Table of Contents
- 1. Introduction
- 2. Audit summary
- 3. Test approach & methodology
- 4. Scope
- 5. Risk methodology
- 6. Scope
- 7. Assessment summary & findings overview
- 8. Findings & Tech Details
- 8.1 Api - authenticated internal users can create admin user
- 8.2 Architecture - missing internal mfa controls
- 8.3 Architecture - missing rate limit
- 8.4 Api - user enumeration
- 8.5 Log management - log injection
- 8.6 Architecture - weak password policy
- 8.7 Architecture - missing two factor authentication
- 8.8 Api - authenticated internal users can delete any other user
- 8.9 Cryptography - plain text game passwords
1. INTRODUCTION
Playground Labs engaged Halborn to conduct a security assessment on their {project} on 2022-09-09 and ending 2022-10-07. Playground Labs developed the Self-Custody node that has API Interface and interacts with external chains.
2. AUDIT SUMMARY
The team at Halborn was provided four weeks for the engagement and assigned a full-time security engineer to audit the security of the {project} in scope. The security engineer is a blockchain and smart contract security expert with advanced penetration testing and smart contract hacking skills, and deep knowledge of multiple blockchain protocols.
The purpose of this audit is to:
Identify potential security issues within the {project}
In summary, Halborn identified multiple security issues are mostly related to the API of the {project}, successful exploitation of these issues will directly lead to funds/financial loss.
Halborn's findings, descriptions and remediations have been redacted at the request of Playground Labs.
3. TEST APPROACH & METHODOLOGY
4. SCOPE
The review was focused on the Python codebase in the halborn-audit branch in the Kapital-Self-Custody-Node repository.
5. 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
6. SCOPE
7. Assessment Summary & Findings Overview
Critical
2
High
0
Medium
2
Low
3
Informational
2
Impact x Likelihood
HAL-01
HAL-03
HAL-05
HAL-06
HAL-07
HAL-08
HAL-09
HAL-02
HAL-04
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| API - AUTHENTICATED INTERNAL USERS CAN CREATE ADMIN USER | Critical | Solved - 09/22/2022 |
| ARCHITECTURE - MISSING INTERNAL MFA CONTROLS | Critical | Solved - 11/07/2022 |
| ARCHITECTURE - MISSING RATE LIMIT | Medium | Solved - 11/09/2022 |
| API - USER ENUMERATION | Medium | Solved - 11/07/2022 |
| LOG MANAGEMENT - LOG INJECTION | Low | Solved - 11/07/2022 |
| ARCHITECTURE - WEAK PASSWORD POLICY | Low | Solved - 11/07/2022 |
| ARCHITECTURE - MISSING TWO FACTOR AUTHENTICATION | Low | Solved - 11/07/2022 |
| API - AUTHENTICATED INTERNAL USERS CAN DELETE ANY OTHER USER | Informational | - |
| CRYPTOGRAPHY - PLAIN TEXT GAME PASSWORDS | Informational | Acknowledged |
8. Findings & Tech Details
8.1 API - AUTHENTICATED INTERNAL USERS CAN CREATE ADMIN USER
// Critical
Description
Inside the user_router within the create_user function which is responsible for creating new users, it was noted that the function requires only an authenticated user without any special permissions.
The user parameter within create_user is based on the UserCreate schema which includes user_role, the attacker can provide any role within the request and create a user with any role, including the admin role.
Score
Likelihood: 5
Recommendation
SOLVED: The Playground Labs team solved the issue by adding the permission checking class.
8.2 ARCHITECTURE - MISSING INTERNAL MFA CONTROLS
// Critical
Description
The authorization scheme within the API was observed, which allows an attacker to interact with the Node and perform privileged actions such as axie_claim or even sign transactions and interact with wallets by only sending the wallet address as an HTTP parameter.
Relying on addr just to interact with a wallet object and retrieve the private key for that wallet is not enough, as it does not provide an authentication layer for wallets. Multiple critical functions were found for this issue, such as wallet_web3_sign and wallet_web3_interaction.
Score
Likelihood: 5
Recommendation
SOLVED: The Playground Labs team solved the issue by adding the OTP Password in critical functions.
8.3 ARCHITECTURE - MISSING RATE LIMIT
// Medium
Description
The {project} authentication system and API implementation in general were found to lack the rate limit mechanism, which in turn exposes the {project} to brute force and denial of service attacks at the level of the application logic.
Score
Likelihood: 3
Recommendation
SOLVED: The Playground Labs team solved the issue by adding an application level rate limit.
8.4 API - USER ENUMERATION
// Medium
Description
A user enumeration vulnerability was observed within the login endpoint, a malicious actor can brute force valid usernames to find valid users on the system and use them in other attack scenarios.
Score
Likelihood: 3
Recommendation
SOLVED: The Playground Labs team solved the issue in commit 815fc73bc5f0dac4c7cb2544bcd249f45aa08135
8.5 LOG MANAGEMENT - LOG INJECTION
// Low
Description
The HTTP Server within {project} was observed to be logging HTTP requests at an early stage with the HTTP body. The attacker can fill the disk with logs simply by sending simple HTTP requests with large chunks of data within the request body to the Custody HTTP Server.
Score
Likelihood: 3
Recommendation
SOLVED: The Playground Labs team solved the issue in commit fd692d0763b9696c24f036abbb25ec6c78dabb89
8.6 ARCHITECTURE - WEAK PASSWORD POLICY
// Low
Description
During the user creation process, it was observed that a weak password policy was applied during the creation of the user's password hash, as it is only checks if the password is longer than 8 characters, which is not enough as a password strength baseline.
Score
Likelihood: 3
Recommendation
SOLVED: The Playground Labs team solved the issue in commit 3f325accdbc5824f147a986f35606ef049224e2f
8.7 ARCHITECTURE - MISSING TWO FACTOR AUTHENTICATION
// Low
Description
It was noted that the authentication system within the {project} lacks a two-factor authentication mechanism. In case of credentials theft, the attacker can perform privileged operations such as transactions and interact with other critical functions.
Score
Likelihood: 3
Recommendation
SOLVED: The Playground Labs team solved the issue by adding the OTP Password in critical functions. ebda4a69fee55bf67501eede7777a5d06fc77a4a
8.8 API - AUTHENTICATED INTERNAL USERS CAN DELETE ANY OTHER USER
// Informational
Description
Score
Likelihood:
8.9 CRYPTOGRAPHY - PLAIN TEXT GAME PASSWORDS
// Informational
Description
The {project} stores the wallet related data and private keys within a database, however, it was observed that the wallet password was stored in a plain text format without any hashing or encryption, meanwhile, the response scheme was observed to return the password in the HTTP response.
Score
Likelihood: 1
Recommendation
ACKNOWLEDGED: The Playground Labs team acknowledged this finding and the severity has been changed to informational.
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. Audit summary
- 3. Test approach & methodology
- 4. Scope
- 5. Risk methodology
- 6. Scope
- 7. Assessment summary & findings overview
- 8. Findings & Tech Details
- 8.1 Api - authenticated internal users can create admin user
- 8.2 Architecture - missing internal mfa controls
- 8.3 Architecture - missing rate limit
- 8.4 Api - user enumeration
- 8.5 Log management - log injection
- 8.6 Architecture - weak password policy
- 8.7 Architecture - missing two factor authentication
- 8.8 Api - authenticated internal users can delete any other user
- 8.9 Cryptography - plain text game passwords
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed