Today’s post is authored by Stefan Beyer, CEO @ Cryptonics, Blockchain Consultant and Smart Contract Auditor. If you are interested in learning about blockchain technology, we recommend you to check the recently created Cryptonics Academy. Please enjoy.
A False Sense of Security
Blockchains are protected by complex mathematical protocols and by decentralization. Cryptographic primitives, such as digital signatures and hashing, are used to verify transaction authenticity and the integrity of the data stored on the blockchain. It is only through these primitives that the concept of digital ownership can be secured. Decentralization makes it incredibly hard for an attacker to gain sufficient control over a blockchain to alter transaction history or apply censorship.
This means that blockchains are quite secure at the protocol level. Although there are confirmed incidents of protocol-level breaches, such as 51% attacks, these are relatively rare and confined to smaller blockchains. Nevertheless, digital assets represented on blockchains are stolen on an alarmingly regular basis, even from large established networks.
In a recent article, we already identified smart contracts as a significant risk vector. In this article, we look at two recent high profile attacks, in order to highlight hidden dangers in the security of support systems that allow attackers to sidestep the sophisticated cryptographic defense mechanisms blockchain protocols provide. This type of attack is typically called a supply chain attack, as it focuses on less secure parts of a project’s supply chain.
Case Study 1: The 2019 Monero Attack
In November 2019 an embarrassing incident compromised the funds of users of the Monero blockchain.Monero prides itself on its sophisticated cryptographic signature protocol, which provides a degree of privacy through the use of ring signatures. However, it did not take any mathematical wizardry for the attackers to breach complex cryptography to break the system and steal users’ funds.
In fact, the incident exploited a very traditional aspect of cybersecurity, namely website security. The attackers simply broke into Monero’s website and managed to replace the official Monero wallet download with a compromised version. New users, and users wishing to upgrade their wallet, from then on unknowingly installed the compromised version, instead of the official version. This version simply sent the seeds of newly created wallets to the attackers’ servers, allowing the attackers to gain access to all private keys belonging to the created wallets.
Fortunately, the attack was discovered very quickly by a tech-savvy user who noticed that the hash value of the download did not match the one published on GitHub. These hash values identify a file’s content precisely. Even a minor change in the file results in a completely different hash value, allowing any manipulation to be detectable. Of course, most end-users do never check hash values of downloads, and it was an extremely lucky turn of events that the incident was discovered quickly by an advanced user. While an unspecified amount of money was lost, the impact of the attack was relatively minor.
The case does highlight, however, that traditional cybersecurity of off-chain components related to a project is as important as protocol security. In fact, traditional off-chain vulnerabilities are probably an even bigger risk vector than on-chain vulnerabilities, due to the number of aspects involved and the existing know-how of bad actors.
Case Study 2: The 2020 IOTA Security Breach
More recently, an even more serious supply chain attack affected the IOTA distributed ledger. IOTA, which uses a directed acyclical graph instead of a traditional blockchain data-structure, prides itself on its innovative cryptographic protocols, which are designed to be quantum-resistant.
However, as in the Monero incident, attackers managed to place malicious code in an official wallet application, in order to steal users’ private keys. The code introduced via a third-party dependency gave the attackers full access to all newly installed or updated Trinity wallets during a 2.5 week period.
The attack seemed to have been carefully planned and professionally executed. The wallet software included an externally developed module allowing users to directly purchase IOTA. This dependency was included in the Trinity codebase via the content delivery network (CDN) used by the provider. However, the attackers managed to substitute the module with a compromised version by intercepting and redirecting CDN API calls. This led to IOTA compromising their own built and distributing it through official channels.
In their postmortem analysis, the IOTA team claims to have been aware of the inherent danger of CDN-delivered dependencies. However, planned changes to the distribution method had not been implemented for some reason.
Apart from the monetary impact of the attack, the incident let to the IOTA network being halted for almost an entire month, producing an additional denial of service effect and highlighting the fact that IOTA is still a centralized network that can be halted at will by the IOTA foundation.
What End-users Can Do
Supply chain attacks put end-users in a difficult situation since the above incidents show that even the official sources may unknowingly distribute malicious software. There is only so much an end-users can do to protect themselves, including the following:
- Verify downloads. Downloaded files should be checked for integrity. Any downloads should be checked for their correct hash values. This, obviously, depends on the provider facilitating the correct hash values in a secure format, preferably in a signed file. The recent Monero guidelinesare a good example of how this can be implemented. Unfortunately, this process is cumbersome and not particularly friendly for users without knowledge of hash values and cryptographic signatures.
- Check audit reports. One measure users can take is to only trust projects with a transparent full-stack audit report, that does not only evaluate protocol-level security but also look at all off-chain components and internal security policies.
- Use a hardware wallet. Finally, a hardware wallet is highly recommended for any critical keys that secure important funds. These devices usually require some physical user interactions for users to confirm transactions and are generally more secure than any downloadable wallet software.
What Projects Must Do
Blockchain projects, wallet providers, and critical software providers in general, however, can do much more to prevent supply chain attacks (and other attacks), including the following measures:
- Have security policies that cover the whole supply chain. Any serious company should have a security policy. Such a policy should cover technical aspects, such as key management, but also logistical aspects, for instance, who can approve certain suppliers and under which circumstances. Importantly, this policy should cover the whole supply chain and take into account how dependencies are included and how providers are chosen.
- Audit the full stack, including all off-chain components. External security audits for smart contracts and protocol code are now fairly standard. However, companies should consider performing full-stack audits, that cover everything that might have an impact on critical code or serve critical code. For example, it is generally a good idea to get an external security assessment of the project’s website and infrastructure setup.
- Vet dependencies. Dependencies, in particular, code dependencies in the form of libraries, are unavoidable in modern multi-layered software stacks. However, providers of such dependencies should be vetted carefully, not only for the quality of the software provided but also for the provider’s security policies and distribution procedures.
- Have contingency plans. Even if all best practices are applied, sometimes things just go wrong and efforts have to change from defense to mitigation and recovery. Plans should be in place for how an organization reacts in case of a security incident. This not only helps to reduce the impact of an attack but also to restore users’ confidence. It is not an acceptable contingency plan for a serious blockchain platform to halt all transactions for almost an entire month, as happened in the recent IOTA incident.
Concluding Remarks
The two recent examples discussed above show that significant damage can be done to blockchain projects through attacks to parts of the system deemed non-critical. Digital assets are not always stolen at the smart contract or protocol level. Traditional cybersecurity of off-chain components and the whole supply chain is equally important. Projects must include these parts into their security policy and include them in external audit processes.
For inquiries on our smart contract and full-stack audits, please contact us at Cryptonics.
(Disclaimer: Cryptonics Consulting is a spin-off of S2 Grupo, specialized in blockchain and cibersecurity).
