Halborn Logo

Desktop Wallet - Anatha


Prepared by:

Halborn Logo

HALBORN

Last Updated 04/26/2024

Date of Engagement by: April 12th, 2022 - May 31st, 2022

Summary

0% of all REPORTED Findings have been addressed

All findings

13

Critical

4

High

2

Medium

6

Low

1

Informational

0


1. INTRODUCTION

Anatha engaged Halborn to conduct a security assessment on their Desktop wallet, beginning on 2022-04-12 and ending on 2022-05-31. The security assessment was scoped to Anatha Desktop Wallet. To begin the test, the Client’s team provided the code source of the Desktop Wallet to Halborn to conduct security testing using tools to scan, detect, validate possible vulnerabilities found in the wallet and report the findings at the end of the engagement.

2. AUDIT SUMMARY

The team at Halborn was provided a timeline for the engagement and assigned two full-time security engineers to audit the security of the smart contract. 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 goals of our security audits are to improve the quality of systems we review and aim for sufficient remediation to help protect users.

In summary, Halborn identified many security risks that need to be addressed by the Anatha Team.

3. TEST APPROACH & METHODOLOGY

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the pentest. While manual testing is recommended to uncover flaws in logic, process and implementation; automated testing techniques assist enhance coverage of the infrastructure and can quickly identify flaws in it.
The following phases and associated tools were used throughout the term of the audit:

    • Storing private keys, mnemonic, seed, and assets securely

    • Exposure of any critical information during user interactions with the blockchain and external libraries

    • Any attack that impacts funds, such as draining or manipulating of funds

    • Application Logic Flaws

    • Areas where insufficient validation allows for hostile input

    • Exploitation of the webview to gain control of the wallet

    • Application of cryptography to protect secrets

    • Brute Force Attempts

    • Input Handling

    • Fuzzing of all input parameters

    • Test for Injection (XSS/JSON/HTML)

    • Web extension misconfiguration

    • Technology stack-specific vulnerabilities and Code Audit

    • Known vulnerabilities in 3rd party / OSS dependencies.

4. SCOPE

The security assessment was scoped to:

    • github/Anatha Wallet Release Version v2.0.0-12

    • Some tests were performed regarding the endpoints on (https://wallet-backend.mainnet.anatha.net/) with which the Wallet communicates

5. 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

6. SCOPE

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

7. Assessment Summary & Findings Overview

Critical

4

High

2

Medium

6

Low

1

Informational

0

Impact x Likelihood

HAL-05

HAL-01

HAL-02

HAL-03

HAL-04

HAL-07

HAL-08

HAL-09

HAL-06

HAL-11

HAL-12

HAL-10

HAL-13

Security analysisRisk levelRemediation Date
LEAKED REPO, WRITE:PACKAGES GITHUB TOKENCritical-
HARDCODED MNEMONIC PHRASES STORED ON DISKCritical-
HARDCODED PRIVATE KEYS STORED ON DISKCritical-
UNENCRYPTED MNEMONIC PHRASE IN-MEMORY (DEMONIC)Critical-
PIN MECHANISM BYPASSHigh-
WORLD WRITABLE TRANSLATIONS GOOGLE DOCHigh-
CONTEXT ISOLATION DISABLEDMedium-
NODE INTEGRATION ENABLEDMedium-
USE OF PACKAGES WITH KNOWN VULNERABILITIESMedium-
LACK OF RESOURCES AND RATE LIMITINGMedium-
REMOTE MODULE ENABLEDMedium-
APPLICATION ERROR LEAKS INFORMATION ABOUT TECHNOLOGY USEDMedium-
SEED PHRASE NOT VALIDATED AFTER WALLET CREATIONLow-

8. Findings & Tech Details

8.1 LEAKED REPO, WRITE:PACKAGES GITHUB TOKEN

// Critical

Description

During the assessment, we have identified that the Anatha Desktop Wallet leaks a GitHub key with repo and write:packages permissions. The Token is leaked in the [Installation Folder]/resources/app.asar file. Any attacker who installs the Anatha Desktop Wallet can retrieve this Token and use it to push (backdoor) code to private Anatha GitHub repositories. They can also use to push packages to the GitHub package repo under the Anatha organization.

Code Location

These are the locations in the codebase where the GitHub Token exists, and which must be removed before deployment:

platform/wallet-desktop/electron-builder.env

APPLE_ID = "some@mail.com"
APPLE_ID_PASSWORD = "cbgs-jnze-vgpn-cgda"

GH_TOKEN = "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"

platform/wallet-desktop/src/renderer/electron-shared/Environment.ts

static readonly UPDATER_PROVIDER: any = {
    provider: 'github',
    repo: 'wallet-release-test',
    owner: 'anathatech',
    token: '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'
};
Searching for the token in app.asar The GitHub Token in app.asar The permissions and validity of the GitHub Token The owner/organization of the GitHub Token The permissions of the token on specific private repositories Part 1 The permissions of the token on specific private repositories Part 2 Using the GitHub Token to upload test file for PoC to Anatha Private Repositories
Score
Impact: 5
Likelihood: 5

8.2 HARDCODED MNEMONIC PHRASES STORED ON DISK

// Critical

Description

During the assessment, we have identified that the Anatha Desktop Wallet leaks Mnemonic Phrases for wallets that belong to the Anatha Organization. The Mnemonic Phrases are leaked in the [Installation Folder]/resources/app.asar file. Any attacker who installs the Anatha Desktop Wallet can retrieve these Mnemonics and use them to access the wallet to transfer tokens out of it into their wallets. There are three such leaked Mnemonic Phrases, possibly used by Anatha for testing purposes, or to distribute tokens/rewards to their clients' wallets.

Code Location

These are the locations in the codebase where the Mnemonic Phrases exist, and which must be removed before deployment:

platform/common/src/clients/anatha/fixtures/keys.ts

const m1 = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

const m2 = [
  'puppy',
  'coil',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'stomach',
  'rent'
].join(' ');

platform/common/src/clients/anatha/tests/keypair.test.ts

const mnemonic = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

platform/common/src/clients/bch/tests/keypair.test.js

const mnemonic = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

platform/common/src/clients/bnb/tests/keypair.test.js

const mnemonic = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

platform/common/src/clients/btc/tests/keypair.test.js

const mnemonic = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

platform/common/src/clients/dash/tests/keypair.test.js

const mnemonic = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

platform/common/src/clients/xrp/tests/keypair.test.js

const mnemonic1 = [
  'fragile',
  'duck',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'fun',
  'account',
].join(' ');

const mnemonic2 = [
  'armed',
  'bundle',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'pumpkin',
  'athlete',
].join(' ');

platform/common/src/clients/cosmos/tests/keypair.test.js

const mnemonic2 = [
  'armed',
  'bundle',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  '*****',
  'pumpkin',
  'athlete',
].join(' ');
Searching for the 1st Mnemonic in app.asar Wallet Assets for the 1st Mnemonic Displaying the 1st Mnemonic in the Wallet Searching for the 2nd Mnemonic in app.asar Wallet Assets for the 2nd Mnemonic Displaying the 2nd Mnemonic in the Wallet Searching for the 3rd Mnemonic in app.asar Wallet Assets for the 3rd Mnemonic Displaying the 3rd Mnemonic in the Wallet
Score
Impact: 5
Likelihood: 5

8.3 HARDCODED PRIVATE KEYS STORED ON DISK

// Critical

Description

During the assessment, we have identified that the Anatha Desktop Wallet leaks private keys for wallets that belong to the Anatha Organization. The private keys in the [Installation Folder]/resources/app.asar file. Any attacker who installs the Anatha Desktop Wallet can retrieve the keys and use them to perform transaction on the respective wallets. There are five such leaked private keys.

Code Location

These are the locations in the codebase where the Private Keys exist, and which must be removed before deployment:

platform/common/src/clients/anatha/fixtures/keys.ts

const addr1 = 'anatha1rugv0xeflk2zrj46dnwl89nx92k8z7jm66wmy9';
const addr2 = 'anatha1s0jfgrwsh0ccpw3u04h4c3u2th7xesrptlpy79';

const priv1 = '453268f9acf09be***************607b4ffbd4b8483c9674e';
const priv2 = '6b8a64f5b2c730d***************5ac10c39c10db58b5b7c0';

platform/common/src/clients/web3/fixtures/keys.ts

const priv1 =
  '7fb2eac5245d140e0f8d1***************fa0a256dfcdd60dad997fd353b5f';
const priv2 =
  '00e0f8adb0a022de08ef3***************07b7898c9f02b95ccc6ffdbfe9fc';
const priv3 =
  '4b64874042478e82b3db8***************3326e6b371285d5e6fb3e3ca94b5';
Leakage of Private Keys in app.asar Leakage of Private Keys in app.asar
Score
Impact: 5
Likelihood: 5

8.4 UNENCRYPTED MNEMONIC PHRASE IN-MEMORY (DEMONIC)

// Critical

Description

The Mnemonic Phrase in the wallet is not encrypted in memory. As a result, an attacker who has compromised a user’s machine can exfiltrate and steal their Mnemonic Phrase.

The Mnemonic Phrase is leaked into memory after the creation of a wallet, the unlocking of the wallet (using password or seed phrase) and the import of the wallet using the seed phrase

Mnemonic Leakage in Memory after creating a Wallet Mnemonic Leakage in Memory after recovering a Wallet by importing the Mnemonic and then locking the wallet Mnemonic Leakage in Memory after unlocking the Wallet with the password Mnemonic Leakage in Memory after unlocking the Wallet with the password and then locking it Mnemonic Leakage in Memory after unlocking the Wallet with the Mnemonic and then locking it
Score
Impact: 5
Likelihood: 5

8.5 PIN MECHANISM BYPASS

// High

Description

We have identified that, It is possible to bypass PIN mechanism and get the seed phrase of wallet, which can lead to takeover of user wallet. We observed that by just crossing the PIN window can bypass this mechanism and perform privilege actions like getting the seed phrase of user's wallet.

PIN-bypass.png{width=400 height=500}

Loom Video: PIN Mechanism Bypass

Score
Impact: 5
Likelihood: 3

8.6 WORLD WRITABLE TRANSLATIONS GOOGLE DOC

// High

Description

The application fetches translations for various messages in various languages from a Google Doc which is world-writable. The Google Doc URL is in plaintext and can be retrieved from the app.asar file of the installed application. A malicious actor can edit this document to anything they want and the next time developer runs npm run locale import all they will get the malicious changes.

The leaked Google Doc URL in app.asar

Loom Video: Unauthenticated changes of the locales

Score
Impact: 4
Likelihood: 4

8.7 CONTEXT ISOLATION DISABLED

// Medium

Description

Context isolation is an Electron feature that allows developers to run code in preload scripts and in Electron APIs in a dedicated JavaScript context. Even when nodeIntegration: false is used, to truly enforce strong isolation and prevent the use of Node primitives contextIsolation must also be used.

If contextIsolation is not used, malicious JS code can tamper with JavaScript native functions as well as preload script code via prototype pollution.

Code Location

/wallet-desktop/app/main.dev.js

      webPreferences: {
      nodeIntegration: true,
      nodeIntegrationInWorker: true,
      enableRemoteModule: true,
      contextIsolation: false,
      devTools: IS_DEV_QA_MODE,
    },
  });
Score
Impact: 4
Likelihood: 3

8.8 NODE INTEGRATION ENABLED

// Medium

Description

In Electron, nodeIntegration is a boolean option that can be used to determine whether node integration is enabled, allows JavaScript to leverage Node.js primitives and modules.

As a result, this could lead to full remote system compromise if you are rendering untrusted content.

For instance, a remote untrusted domain rendered in a browser window could invoke Node.js APIs to execute native code on the user’s machine. Similarly, a Cross-Site Scripting (XSS) vulnerability on a website can lead to remote code execution.

Code Location

/wallet-desktop/app/main.dev.js

      webPreferences: {
      nodeIntegration: true,
      nodeIntegrationInWorker: true,
      enableRemoteModule: true,
      contextIsolation: false,
      devTools: IS_DEV_QA_MODE,
    },
  });
Score
Impact: 4
Likelihood: 3

8.9 USE OF PACKAGES WITH KNOWN VULNERABILITIES

// Medium

Description

The Anatha Desktop Wallet application uses a third-party dependency to delegate handling of program arguments. However, the dependency creates an expected disadvantage in that the actual application's security posture now rests on it.

Specifically, the axios <=0.21.1 package suffers from a high vulnerability, the elliptic<=6.5.3 package suffers from a high vulnerability, the follow-redirects<=1.14.7 suffers from a high vulnerability, the lodash<=4.17.20 package suffers from a critical vulnerability and the node-notifier<8.0.1 suffers from a medium vulnerability.

Code Location

The output of 'npm audit'

axios  <=0.21.1
Severity: high
Incorrect Comparison in axios - https://github.com/advisories/GHSA-cph5-m8f7-6c5x
Server-Side Request Forgery in Axios - https://github.com/advisories/GHSA-4w2v-q235-vp99
Depends on vulnerable versions of follow-redirects
No fix available
node_modules/axios
  @binance-chain/javascript-sdk  *
  Depends on vulnerable versions of axios
  node_modules/@binance-chain/javascript-sdk

elliptic  <=6.5.3
Severity: high
Use of a Broken or Risky Cryptographic Algorithm - https://github.com/advisories/GHSA-r9p9-mrjm-926w
Signature Malleabillity in elliptic - https://github.com/advisories/GHSA-vh7m-p724-62c2
fix available via `npm audit fix --force`
Will install @dashevo/dashcore-lib@0.18.15, which is a breaking change
node_modules/@dashevo/dashcore-lib/node_modules/elliptic
node_modules/bitcore-lib-cash/node_modules/elliptic
node_modules/bitcore-lib/node_modules/elliptic
node_modules/litecore-lib/node_modules/elliptic
  @dashevo/dashcore-lib  <=0.18.11 || >=0.19.0
  Depends on vulnerable versions of elliptic
  node_modules/@dashevo/dashcore-lib

follow-redirects  <=1.14.7
Severity: high
Exposure of Sensitive Information to an Unauthorized Actor in follow-redirects - https://github.com/advisories/GHSA-pw2r-vq6v-hr8c
Exposure of sensitive information in follow-redirects - https://github.com/advisories/GHSA-74fj-2j2h-c42q
No fix available
node_modules/follow-redirects
  axios  <=0.21.1
  Depends on vulnerable versions of follow-redirects
  node_modules/axios
    @binance-chain/javascript-sdk  *
    Depends on vulnerable versions of axios
    node_modules/@binance-chain/javascript-sdk

lodash  <=4.17.20
Severity: critical
Prototype Pollution in lodash - https://github.com/advisories/GHSA-jf85-cpcp-j695
Prototype Pollution in lodash - https://github.com/advisories/GHSA-fvqr-27wr-82fm
Prototype Pollution in lodash - https://github.com/advisories/GHSA-p6mc-m468-83gw
Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm
Regular Expression Denial of Service (ReDoS) in lodash - https://github.com/advisories/GHSA-x5rq-j2xg-h7qm
fix available via `npm audit fix --force`
Will install bitcore-lib-cash@8.25.25, which is outside the stated dependency range
node_modules/bitcore-lib-cash/node_modules/lodash
node_modules/bitcore-lib/node_modules/lodash
node_modules/litecore-lib/node_modules/lodash
  bitcore-lib  <=8.22.1 || >=9.0.0
  Depends on vulnerable versions of lodash
  node_modules/bitcore-lib
  bitcore-lib-cash  <=8.22.1 || >=9.0.0
  Depends on vulnerable versions of lodash
  node_modules/bitcore-lib-cash
  litecore-lib  *
  Depends on vulnerable versions of lodash
  node_modules/litecore-lib

node-notifier  <8.0.1
Severity: moderate
OS Command Injection in node-notifier - https://github.com/advisories/GHSA-5fw9-fq32-wv5p
fix available via `npm audit fix --force`
Will install jest@27.5.1, which is a breaking change
node_modules/node-notifier
  @jest/reporters  <=26.4.0
  Depends on vulnerable versions of node-notifier
  node_modules/@jest/reporters
    @jest/core  <=25.5.4
    Depends on vulnerable versions of @jest/reporters
    node_modules/@jest/core
      jest-cli  24.2.0-alpha.0 - 25.5.4
      Depends on vulnerable versions of @jest/core
      node_modules/jest-cli
        jest  24.2.0-alpha.0 - 25.5.4
        Depends on vulnerable versions of jest-cli
        node_modules/jest

/platform/common/package.json

"main": "dist/index.js",
"module": "dist/index.esm.js",
"types": "types/index.d.ts",
"dependencies": {
  "@binance-chain/javascript-sdk": "^2.16.2",
  "@cosmjs/proto-signing": "^0.24.1",
  "@cosmjs/stargate": "^0.24.1",
  "@dashevo/dashcore-lib": "=0.17.0",
  "anatha-sdk": "git+ssh://git@github.com/anathatech/anatha-sdk.git#011659ccd94b53d288f261d49dd54841d7dff2b9",
  "axios": "^0.19.2",

platform/common/package.json

"create-hash": "^1.2.0",
"elliptic": "^6.5.4",
"ethereumjs-tx": "^2.1.1",

platform/common/package-lock.json

"follow-redirects": {
  "version": "1.14.9",
  "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.9.tgz",
  "integrity": "sha512-MQDfihBQYMcyy5dhRDJUHcw7lb2Pv/TuE6xP1vyraLukNDHKbDxDNaOE3NbCAdKQApno+GPRyo1YAp89yCjK4w=="
}

platform/common/package.json

"litecore-lib": "^0.13.22",
"lodash": "^4.17.21",
"moment": "^2.27.0",
Score
Impact: 4
Likelihood: 3

8.10 LACK OF RESOURCES AND RATE LIMITING

// Medium

Description

API requests consume resources such as network, CPU, memory, and storage. This vulnerability occurs when too many requests arrive simultaneously and the API does not have enough compute resources to handle those requests. An attacker could exploit this vulnerability to overload the https://wallet-backend.mainnet.anatha.net/api/v1 API by sending more requests than it can handle. As a result, the API becomes unavailable or unresponsive to new requests, and there can be a depletion of third-party API tokens.

Rate limiting
Score
Impact: 3
Likelihood: 4

8.11 REMOTE MODULE ENABLED

// Medium

Description

The remote module provides a way for the renderer processes to access APIs normally only available in the main process. Using it, a renderer can invoke methods of a main process object without explicitly sending inter-process messages. This is highly discouraged since the module is considered harmful.

remote uses an internal IPC channel to communicate with the main process. "Prototype pollution" attacks can grant malicious code access to the internal IPC channel, which can then be used to escape the sandbox by mimicking remote IPC messages and getting access to main process modules running with higher privileges.

Code Location

/wallet-desktop/app/main.dev.js

      webPreferences: {
      nodeIntegration: true,
      nodeIntegrationInWorker: true,
      enableRemoteModule: true,
      contextIsolation: false,
      devTools: IS_DEV_QA_MODE,
    },
  });
Score
Impact: 3
Likelihood: 3

8.12 APPLICATION ERROR LEAKS INFORMATION ABOUT TECHNOLOGY USED

// Medium

Description

We have discovered that the backend API server with which the Anatha Desktop Wallet communicates, generates an error message that includes sensitive information about its environment, users, or associated data.

Specifically, the error shows directory structure, OS, and JS packages used.

Error on browser

This is the HTTP Request/Response that produces the error:

POST /api/v1/auth HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=utf-8
User-Agent: axios/0.19.2
Content-Length: 486
Host: wallet-backend.mainnet.anatha.net
Connection: close

{"data":{"challenge":"12345'"\'\");|]*%00{%0d%0a<%00>%bf%27'####"},"public_key":"022459a933b8b88bdb8029a9e5c7730a7d41c2ac4507e2be7889f2ba88ddc520a3","signature":"7..."}

HTTP/1.1 400 Bad Request
Server: nginx/1.16.1
Date: Wed, 25 May 2022 07:18:13 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1016
Connection: close
Content-Security-Policy: default-src 'none'
X-DNS-Prefetch-Control: off
Expect-CT: max-age=0
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
X-XSS-Protection: 0

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>SyntaxError: Unexpected token \ in JSON at position 29<br> &nbsp; &nbsp;at JSON.parse (&lt;anonymous&gt;)<br> &nbsp; &nbsp;at parse (/home/centos/wallet-backend/node_modules/body-parser/lib/types/json.js:89:19)<br> &nbsp; &nbsp;at /home/centos/wallet-backend/node_modules/body-parser/lib/read.js:121:18<br> &nbsp; &nbsp;at invokeCallback (/home/centos/wallet-backend/node_modules/raw-body/index.js:224:16)<br> &nbsp; &nbsp;at done (/home/centos/wallet-backend/node_modules/raw-body/index.js:213:7)<br> &nbsp; &nbsp;at IncomingMessage.onEnd (/home/centos/wallet-backend/node_modules/raw-body/index.js:273:7)<br> &nbsp; &nbsp;at IncomingMessage.emit (events.js:314:20)<br> &nbsp; &nbsp;at IncomingMessage.EventEmitter.emit (domain.js:483:12)<br> &nbsp; &nbsp;at endReadableNT (_stream_readable.js:1241:12)<br> &nbsp; &nbsp;at processTicksAndRejections (internal/process/task_queues.js:84:21)</pre>
</body>
</html>

Score
Impact: 3
Likelihood: 3

8.13 SEED PHRASE NOT VALIDATED AFTER WALLET CREATION

// Low

Description

When creating an account on the Anatha Desktop Wallet, the application doesn't ask the user to validate that they have written down the correct seed phrase. This can lead to loss of funds if, for any reason, the user has written down the wrong Seed Phrase. We have also identified that, It was possible to create a Wallet account with any random alphabets. Moreover, there were no checks on the length of the seed phrase as well.

Seed Phrase is shown at Wallet creation Wallet loads without asking user to validate their Seed Phrase No Limit on Seed Phrase
Score
Impact: 2
Likelihood: 2

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 2024. All rights reserved.