Blockchain as disruptive innovation, a flood of Initial Coin Offerings, aka ICOs, and corresponding software implementations called smart contracts – those intrigued by technological progress and societal advancements have a lot to digest these days. Nevertheless, the traditional laws and dynamics of software development still apply: any source code is prone to errors. In a world where smart contracts are executed by a network of mutually distrusting nodes without a central authoritative entity - potentially handling large numbers of value units, transformable into “real” money - security plays a pivotal role. However, security matters are often neglected – with dire consequences, as seen in cases like DAO and Parity Wallet Breach. This article provides some insight and recommendations on how to expect and deal with attack vectors.
Smart Contracts & Decentralized Apps
Blockchain technology has come a long way since Bitcoin and its simple scripting language. Today, advanced architecture and functionality allows for smart contracts as the blockchain-based back end of so-called decentralized applications (DApps).
A lot of emerging platforms for decentralized applications like the global players Ethereum and Hyperledger Fabric, as well as others like Lisk, Emercoin, etc., promise the next digital revolution, expanding the benefits of blockchain far beyond crypto-currencies.
Relevance of Smart Contract Security
However, the vast differences between conventional and blockchain development have to be taken into account.
Just following intuition instead of best practices may only lead to unwanted loopholes. The well-known DAO (Decentralized Autonomous Organisation) hack can be considered a prime example for overlooked side effects in smart contracts. The Ethereum-based DAO began as the world’s largest crowd-funding project, yet quickly turned into one of the most memorable failures when the exploit of a recursive call pattern resulted in sudden removal of DAO funds. The following hard fork of the Ethereum blockchain to undo the damage of over $50 million (see http://www.zeit.de/digital/internet/2016-06/the-dao-blockchain-ether-hack) only fueled controversy.
Just as severe, with damage totalling $30 million (see https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach), was the Parity wallet breach related to Ethereum in July 2017. A careless use of a delegate call command in a critical library enabled the attacker to gain ownership of a multisignature wallet and to redirect all of its funds.
Even though developers are usually quick to react when it comes to minimizing damage, prevention is far more important while working on an immutable ledger where “code is law”. Navigating through this complex world of decentralized consensus, cryptography, transparent code, and possible hard forks may prove difficult at first, and user-friendliness is still not quite in reach. And with much of its potential yet to be revealed, adapting to the blockchain environment is an ongoing process.
So even though the underlying technology can be considered secure, and the correct operation of the biggest blockchains has yet to be challenged, the development process of DApps is still prone to human error and calls for its own security approach.
A Security Assurance Approach
A rough blueprint for a security assurance approach is sketched in the following. This is intended to introduce the high-level scheme required for drawing and applying a comprehensive, detailed picture, which is mandatorily applied in practical, real-world implementation scenarios.
Technology stack analysis. Before starting with a development based on a blockchain, it is vital to accept the fact that smart contract code is not an isolated piece of technology. There is a lot more happening behind the scenes, and many layers below the actual code have to be considered. Like which blockchain to use. Every blockchain consists of many nodes and it has to be evaluated who these are. It is certainly not possible to get this kind of information in detail for every node, but an overview should be obtained. Conducting such research helps to find the most suitable blockchain and allows an estimation of how great the danger of a 51%-attack is.
Penetration testing. As soon as the solution is initially available, even as a prototype, start penetration testing. Make it a habit – this is not something that has to be just done once, it is an ongoing process. Penetration testing focuses on testing the whole system and checking for security issues. The goals which one would like to achieve with penetration testing are the identification of vulnerabilities, the identification of potential errors resulting from misuse, and the increase of security on the technical and organizational levels. So even if a public permissionless blockchain is used, where it is not possible to test all clients involved in the blockchain, penetration testing is in fact very helpful. Potential issues with the deployed DApp and the blockchain node used can occur and early intervention can prevent possible damage.
Source code review. As the examples shown above indicate, it is necessary to review the source code of DApps thoroughly before deploying them on the blockchain. As one of the main blockchain characteristics, immutability does not only ensure data integrity, it also prevents code published on the ledger from being modified in any way, making further updates to a contract impossible. This and the accessibility of code for everyone (in case of a public ledger) can be a dangerous combination as attackers may quickly find and exploit vulnerabilities in the irrevocably published code. Therefore source code review – as it is important for any application – is highly important for all blockchain-based applications. More true than ever: Better to be safe than sorry!
Consider any Attack Vectors
To embrace a security attitude, thinking like an attacker is crucial – always expect the worst malicious intent of highly skilled renegades. Even if the code of the smart contract is not faulty, the classic problem nowadays of a Denial of Service attack can be applied to a smart contract. However, this means spamming the whole blockchain it is operated on. Still, it can be done. Additionally, consider “dumb” users: As long-term practical experience shows, anything that can be done with your software – including smart contracts – will be done. To go beyond that, not-so-skilled users may be attacked by traditional phishing attacks, meaning that their private keys get compromised. This causes real damage to the user and reputational damage to the smart contract, even if it is perfectly secure. All in all, diving into attack vectors requires acceptance of real bugs and design flaws allowing undesired functions, as well as general technology risks and user errors. Furthermore, smart contract developers always have to remember that their own mistakes and those of people they rely on have to be taken into account.
While the disruptive potential of blockchain and distributed ledger technology (DLT) offer a lot of chances and opportunities, breaking new ground still comes with risks. Growing and ever-changing environments – such as with decentralized apps – also attract people with malicious intent. Constant review of code and proper analysis of possible attack vectors become a necessity – and one of the most important aspects of keeping up with blockchain evolution.
This article provided a brief introduction into the challenging realm of smart Contract Security. There is obviously much more to it than what can be transported here. Hence in your blockchain endeavor, involving your trusted advisor is strongly encouraged.
Dr. André Kudra is CIO of esatus AG, a consulting company specialized in in-formation security matters. He has more than 12 years of consulting experience and held various key positions in major information security projects of global enterprise organizations. He leads the working group “Blockchain” of TeleTrusT – IT Security Association Germany and actively contributes to ISO’s Blockchain Identity standardization efforts.
Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s own and do not reflect the view of the publisher, eco – Association of the Internet Industry.