Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • crown-core crown-core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 75
    • Issues 75
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Crown
  • crown-corecrown-core
  • Issues
  • #160

Closed
Open
Created Apr 15, 2018 by Alex H.@higherbridgeReporter

masternode/systemnode install script - small RPC password vulnerability

Current approach

As I understand it, the masternode/systemnode install script (https://raw.githubusercontent.com/Crowndev/crowncoin/master/scripts/crown-server-install.sh) uses the following line to generate the rpc password: PW=$(date +%s | sha256sum | base64 | head -c 32 ;)

This approach uses the time of installation (in seconds) to generate the rpc password. If someone were to be able to make an estimation of when the script was installed, it reduces the possibilities an attacker would need to guess to several thousand options or less.

Issue

For this to be a larger scale vulnerability, an attacker would need several items:

  1. Access to the server where the masternode/systemnode is hosted

  2. There would need to be (unsecured) funds in the wallet that the attacker can steal OR It would need to have access to 51% of the servers that are active on the network (51% attack)

Possible fix

I was approached by an attendant at Crypto010 about this vulnerability. he suggested we use the /dev/random package (https://en.wikipedia.org/wiki//dev/random) to generate a better randomized password.

It's a small issue, but it may be solved with an easy fix

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking