Security is of utmost importance in blockchain networks. History shows us that there are lots of attack vectors in centralized infrastructure. Cryptocurrency exchange hacks and other instances of lost customer funds have accompanied the space since its inception. Notable examples include the Mt. Gox insolvency, the QuadrigaCX episode, and the very recent Binance hack.
In Proof-of-Stake, node operators (validators) participate in network consensus on behalf of cryptoassets staked with them. Validators don’t have custody over funds staked with them, but staking cryptoassets means assets are put at risk and used as collateral. Many networks have a slashing mechanism to punish misbehavior and rewards for staking are tied to validator performance. Being offline means losing out on rewards. Trying to cheat results in loss of collateral. These (dis)incentives exist to ensure validators follow the protocol and operate performant infrastructure.
But it’s not enough to faithfully run the node software on adequate hardware, especially if your infrastructure is effectively securing multiple million dollars worth of cryptoassets. There are many ways in which validation infrastructure could be compromised by an outsider. Running a validator requires operators to design their systems in a way that minimizes the likelihood of such a scenario taking into consideration among other things access control and key management.
Chorus One has assigned the highest priority to the security of our infrastructure. Today, we release the results of a first security audit that we undertook in April 2019 as part of this commitment. The external penetration test carried out by renowned cyber security experts ECSC Group uncovered the following vulnerabilities:
- Medium Vulnerability: Inclusion of TLS1.0 and TLS1.1 in accepted TLS versions. The default AWS Load Balancer TLS configuration supports TLS 1.0 and TLS 1.1 in order to ensure backward compatibility with older browsers. This was remedied by using an up to date TLS policy that does not permit the establishment of connections based upon TLS1.0 or TLS1.1 protocol versions.
- Low vulnerability: Exposure of system configuration by ‘Server:” header. Unfortunately, this is unable to be remedied at this point in time. Load balancers provided by a vendor, AWS, expose the ‘Server: awsalb’ header, and this cannot be overridden by the consumer at this time.
- Low vulnerability: Absence of multiple security headers to reduce potential attack vectors:
- Cosmos RPC and LCD endpoints do not allow the definition of HTTP security headers. An issue has been raised with the cosmos-sdk project (https://github.com/cosmos/cosmos-sdk/issues/4304).
The above issues have been remediated since the delivery of the report by ECSC.
Overall, the report serves as a first reassurance of the security of our design, reflected by the low overall risk rating:
In addition to the above defects, a further issue was highlighted although it is not considered a vulnerability - but it is included here for completeness:
- Low vulnerability: Exposure of IP addresses on https://cosmos.chorus.one:26657/genesis. This is a publicly available file (https://github.com/cosmos/launch/blob/master/genesis.json), it’s existence is intentional, and it does not confer any private information about the Chorus One setup.
We are proud to be one of the first validators to have undertaken a security audit of our infrastructure. We strive for continuous improvement of our platforms and processes, and look forward to bringing our infrastructure to upcoming Proof-of-Stake networks. We are working on releasing more technical content about our setup in the future, and will soon also open-source important parts of it. Follow us to stay tuned about those updates!
If you are interested in staking or working together with Chorus One please contact us at firstname.lastname@example.org or on Telegram. The full audit report will be made accessible to our partners that are interested in the comprehensive evaluation of our architecture.