The DAO Hack and Blockchain Security Vulnerabilities

Security considerations override all other considerations in software in general and in blockchain specifically. If security fails, nothing else matters. Blockchain proves decentralized, trustless transactions work, but many blockchain security vulnerabilities remain nonetheless.

Security exploits exist at the design and architectural level, at the coding stage, and in the operational phase. And in case you were wondering, yes, the blockchain can be hacked.

Blockchain Security Vulnerabilities – From Here to Eternity

Diamonds are forever, and smart contracts live for as long as the blockchain they are deployed on continues to be used. Consequently, all bugs and blockchain security vulnerabilities also live as long as the contract does.

Typically, each blockchain provides its own programming language to implement smart contracts. Let’s take a closer look.

Smart Contract Languages

Blockchain environments include their own languages for developing smart contracts.

The Ethereum platform, for example, includes the Solidity language to write smart contracts. The creators designed Solidity to be a Turing complete language.

A Turing complete language essentially allows the programmer to implement anything the underlying system is capable of. Consequently, this gives programmers abilities like implementing loops in the code, which can potentially cause blockchain security vulnerabilities.

Turing Completeness

Turing complete languages contain complexity by nature, and complexity invites bugs and vulnerabilities.

The Bitcoin network also has a programming language which it calls Script. Script is purposely not Turing complete to enhance security.

The fewer options that are given to a programmer, the less likely for blockchain security vulnerabilities to enter the system.

To minimize the risk of releasing faulty code into the wild, programmers must understand common pitfalls and anti-patterns inherent in smart contract programming. (Anti-patterns represent bad programming practices).

The DAO Hack: The Reentrancy Problem

The DAO Hack

The reentrancy problem probably ranks highest among blockchain security vulnerabilities programmers coded into smart contracts. Reentrancy drains an account through multiple expenditures for the same transaction. The use case of processing refunds lends itself to this exploit, but this flaw affects any kind of transaction if not addressed at the design and coding stage.

In one of the most infamous cryptocurrency attacks to date, hackers of the DAO exploited reentrancy. No organizational leader dictated how to run the DAO (or Decentralized Autonomous Organization), and the DAO proposed to empower users with the ability to vote on projects to invest in.

It raised over $150 million in funding in its first month. On June 17, 2016, hackers drained $50 million from the organization through the reentrancy flaw. The hard fork from Ethereum Classic (ETC) to Ethereum (ETH) resulted in an effort to resolve the problems this hack created.

Anti-Pattern Vulnerable to Reentrancy

A vulnerable reentrant logic for code looks like this:

function to process a payment () {

(1) check the validity of the transaction, the recipient, and the account balance;

(2) process the transaction;

(3) update the state of the system to show the transaction has been processed;

}

At first glance, the logic looks correct and complete, but the flaw resides in the order of doing step 2 before step 3.

While the first call to the function continues processing step 2, another call for the same transaction can enter the function. Since state information remains in its initial state and not yet processed in step 3, the second call checks out as a valid transaction to process.

Consequently, the system spends currency for the same obligation a second time. Hackers rush multiple transactions to the function before the state gets set properly.

Cure for Reentrancy

This change to the algorithm corrects the above problem:

function to process a payment () {

(1) check the validity of the transaction, the recipient, and the account balance;

(2) update the state of the system to show the transaction has been processed;

(3) process the transaction;

}

The code must account for all necessary exception handling, and it must account for all logical dependencies as well.

Overflow

Overflow is another common security flaw programmers need to be aware of.

Some programming languages provide strong typing, and others provide weak typing. Strongly typed languages refuse to allow programmers to assign string data to a numeric variable, for example, and weakly typed languages allow such actions.

Strongly typed languages enforce range restrictions. If an array is ten elements, programmers cannot attempt to access the eleventh element. Weakly typed languages allow such behavior, but crashes result. If the maximum allowable value a variable holds is 99, and you assign it a value of 100, watch it crash when you run it!

Consequently, overflow is an exploit that hackers use. If a hacker feeds a parameter to a smart contract that is out of the range the code can process, a crash results. Such a crash fuels multiple exploits. The crash could trigger a denial of service attack (DDoS attack), and vital information about the internals of the system sometimes reveal themselves in error messages.

In web applications, hackers often fill memory with their own malicious code, so when the program crashes and goes to a random spot in memory, the malicious code executes.

Weakly typed languages provide power and dynamic flexibility, but they also require more rigorous design and testing to be hardened against attacks.

The Many-Headed Hydra

A multitude of security issues plagues the software world. As new technology emerges, new threats appear. Besides the exploits mentioned above, these notable flaws represent just a few of the many other blockchain security vulnerabilities.

Bad cryptography creates many headaches. Cryptography ensures privacy, and when privacy breaks, everything breaks. The IOTA team made the mistake of writing their own cryptographic library from scratch in the initial version of their product. The problem inherent in rolling your own cryptography is that all complex software contains bugs, so you are guaranteed to have buggy cryptography.

Established cryptographic libraries survive vetting by academics and prove reliable over time through life in the wild.

In the world of wallets, random number generation must be truly random. Particularly in the early days of cryptocurrency, some wallets failed this requirement.

Cryptocurrency addresses require addresses that must be unique. Uniqueness comes from a random number generator, and the random number generator needs a seed to begin the process. If the seed fails to be truly random, the system fails.

One result of bad randomness means the same address gets created multiple times. Picture the scenario where a wallet assigns address X to person A, and then sometime later assigns address X to person B. When a payment goes to address X it only goes to one person. Which person gets the money?

Another problem with bad randomness arises when a hacker figures out the algorithm used to create the seed. The hacker regenerates the seed for himself and owns the system.

The Road Goes On Forever and the Party Never Ends

Security is a never-ending battle, and even if programmers, architects, and testers remove all vulnerabilities from the code, operational vulnerabilities remain.

In a Proof of Work environment, if bad actors control 51% of the network, integrity is destroyed. Game theory provides mitigation for this attack. A new cryptocurrency with a small network exposes most risk to this attack. But a 51% attack destroys the value of the currency, so attackers just hurt themselves.

Blockchains live on the internet and share all the same exposure to hackers as the internet. For instance, suppose you buy coins from an exchange on a website. Injection attacks, cross-site scripting, phishing attacks and all the other traditional website hacks prevail.

Final Thoughts

Just as programmers guard against bugs, programmers must factor security into their development. Some tools exist to aid programmers in the task, but programmers must first understand their own vulnerabilities to guard against them.

The Decentralized Application Security Project (DASP) aspires to be a repository of information and resources on blockchain security. They model themselves somewhat on the Open Web Application Security Project (OWASP). The annual OWASP Top 10 definitely lists the primary web application vulnerabilities currently in existence. The DASP Top 10 hopes to provide the equivalent resource for blockchain.

Not all attacks are known beforehand. A zero-day exploit defines an exploit hackers know about before anyone else does. So programmers must think like attackers when designing and implementing software. If you don’t find the vulnerabilities in your code, expect a hacker looking for profit to find them.