ARK Security Vulnerabilities Disclosure — #1
Producing software inherently comes with risks. All software, especially new releases and large code re-writes, have a higher probability of producing bugs during production and initial release. To combat this, the ARK team has introduced modern testing methods, higher test coverage, a custom developed e2e testing framework and increased the availability for testing on our Development Network prior to release. Despite all of that, no one can catch every potential issue. This new reporting series will serve as a public disclosure of any discovered and patched vulnerabilities within the ARK Blockchain Platform (Core, Desktop Wallet, Mobile Wallet, ARK Pay & Deployer).
During our internal and public Development Network testing phase a LOT of bugs were found and patched. While the ARK team does considerable testing, a fresh pair of eyes can often discern issues that we may have overlooked. That is why we value community feedback and put a lot of effort into our bounty programs (which we recently updated).
But, as already said by Edsger W. Dijkstra:
”Program testing can be used to show the presence of bugs, but never to show their absence!”
After the successful launch of ARK Core v2 by the ARK Team and the public migration of the network by the ARK Network Delegates, several critical security vulnerabilities were disclosed to our team by ARK community members & Delegates. Due to the critical nature of these disclosures and the impact they could have had on the network, we would like to thank those responsible for their hard work and efforts to report these issues responsibly. The security vulnerabilities are disclosed below with additional explanations and details on the associated patches. Due to the professionalism of our community security researchers, at no point was anything tested or abused on the Public Network and the integrity of the ARK blockchain remains intact.
After the disclosures, it became increasingly important for Ark to notify those utilizing the ARK Blockchain Platform (ARK Forks) of the identified critical bugs to allow them to mitigate any potential vulnerabilities in a timely manner. Sharing known vulnerabilities and the associated patches benefits all parties involved and keeps the lines of communication open between projects, which can help on other aspects of development as well (avoiding duplication of effort). That is why we have improved our steps related to our security vulnerability disclosure process. If you are running a project based on the ARK Platform, we highly recommend appointing a dedicated team member to check the parent repository and follow any changes.
New Disclosure Process
The whole security vulnerability disclosure process is being standardized on our end. From now on this process will be streamlined. Public critical disclosure information will be released after said vulnerability has been patched on Ark’s Public Network. We will also notify all the related forks (that we are aware of) in an automated manner after patches are closed so they have every opportunity to patch critical vulnerabilities in a timely manner.
List of Closed Security Vulnerabilities
This section lists the security vulnerabilities that were identified and patched since the release of ARK Core v2.
1. Invalid block received
Cause: The lastDownloadedBlock variable was not reset when discarding invalid blocks. This caused network nodes to continually attempt to download new blocks from the wrong height, effectively halting the network. This issue would have allowed a malicious user to disrupt network nodes and the network itself.
Reported by: delegate fun
Solution: Reset last downloaded block after discarding an invalid block.
2. Generating new Ark using multi signature transaction
Cause: In a multi-signature transaction, the transaction handler only verified the signatures and did not properly conduct balance checks. This made it possible to generate new ARK tokens on the network utilizing a multi-signature transaction.
Reported by: delegate fun
Solution: Perform wallet balance checks for multi signature transactions.
3. Second signature transaction replay
Cause: Attaching a second signature to a previous transaction sent from any wallet that does not have a second passphrase would allow the transaction to be infinitely forged and replayed over and over again.
Reported by: delegate pierce
Solution: Ensure that the sender wallet has a second public key and if not reject the transaction.
4. IP spoofing
Cause: The whitelist could be bypassed by IP spoofing due to the way we determined the IP of a request. This could also be used to fill up the peer list with loopback IP addresses to cause a DoS attack and prevent block propagation.
Reported by: delegate fun
Solution: Use request.info.remoteAddress as provided by Hapi to get an IP of the peer.
List of Known and Open Vulnerabilities
While we continually work to improve and patch all known issues, some require more in depth solutions at the conceptual and protocol levels and can be fundamental issues in the nature of Proof-of-Stake and Delegated-Proof-of-Stake consensus models. These issues can be attributed to the inherent trust placed in the delegates in a DPoS network or are related to things such as the users losing their security keys (mnemonic code words) or just someone acting as a bad forger/delegate or as an attacker.
The currently open challenges we’d like to fix are the following:
1. Double forging a block
Many of the public testers might have thought that double forging was mitigated and solved during the testing phase, but this was never the case. Double forging appeared to be working more correctly due to the way we handled transaction propagation in the initial versions of Core v2. All nodes had homogeneous transaction pools and broadcasted to all peers. The double forged blocks had the same content and same IDs. That is why it was not detected as an issue during initial public testing.
That being said, at any given time a malicious forger could and still can forge multiple distinct blocks and broadcast them to different peers causing instability in the network.
There is an AIP-24: Double Forging Improvements draft in progress that will address this issue, but requires careful consideration.
Until then, forging delegates need to make sure they do NOT run two or more servers with the forger process ‘on’ and passphrase set, have more relay nodes in front of their forging delegate, and that they don’t run automatic scripts to switch the forgers. We have seen failover scripts cause double forging that halts the network in the past and until a solution is in place, this practice risks harming the network.
The network as of now detects double forging and tries to recover via fork management, but this isn’t optimal and still leaves room for user or script errors.
2. Transaction replay attack with known 2nd signature passphrase / multisignature
Cause: It is currently possible to generate distinct signatures for the same transaction from the same private key which can all be verified by the same public key. The 2nd signature changes the ID of a transaction so it is not considered to be a duplicate, but a new transaction. That means if your second passphrase is lost/stolen an attacker can replay your previous transactions by simply changing the 2nd signature.
Reported by: delegate pierce
Solution: An AIP to address this is in progress and we have started evaluating the best possible solution to address this. This means a hard fork at some milestone level and a mitigation script for transactions prior to the included milestone. When the AIP is finalized — we will share it with everyone, as always. Until then — keep your passphrase safe and do NOT share it with anyone (even if it is just the 2nd one)! Utilizing the 2nd signature with a 2nd party as a form of multi-signature was never the intended use of the 2nd signature and as per the above, can lead to theft or misuse of funds.
Takeaway for All of Us
A new product with a fresh code base was recently launched and despite our best efforts to deliver bug free code, there were several critical issues found and also patched in the shortest possible time. Again thank you to everyone that helped, especially to delegate fun for being the most active during this testing phase.
We will do our best to continue to improve our testing and validation models and will take what we have learned and utilize it to improve our best practices. As for the network maintainers and all others, make sure your passphrase (mnemonic code words) is safely stored and printed.
We would also like to invite all security researchers and interested parties to audit the current codebase, to take their time and go through the critical sections, especially related to transaction validation and transaction processing.
If you missed it, we recently updated our development and security bounty program for 2019. Previous years have taught us how to improve the program and make it more fair for all participants, with revised tiers so everyone can predict their earnings. The revised program will emphasize quality over quantity.
We also announced the acquisition of security and penetration testing services from Bugcrowd — the planet’s premier crowd sourced security platform! Highly skilled and trusted white hat hackers from all over the world will try to breach the ARK hull and attempt to expose vulnerabilities before they pose a risk to the ARK Ecosystem. The private ARK-Bugcrowd testing is already discovering and reporting bugs from verified Bugcrowd members. This program should be opening to the wider public very soon as they optimize everything behind the scenes.
This concludes the first iteration of The ARK Security Vulnerabilities Disclosure series. Through a stronger focus on testing and validation and with your continued vigilance on our Developer Network, we hope to minimize the number of entries in this series moving forward. Thank you for all of your hard work and we look forward to working together to keep the ARK Network secure and bug free in 2019!
