$150 Million Locked On the Ethereum Network — How to Protect Yourself

Complexity Is the Enemy of Security

Parity is an Ethereum implementation written in Rust, spearheaded by the very talented cofounder of Ethereum, Gavin Wood. The implementation provides an easy to use GUI for creating multi-sig wallets. The multi-sig contract that underpins this functionality was found to have a vulnerability on July 19, 2017 that resulted in a loss of $30 million. On November 7, 2017 a second vulnerability was found in the wallet contract that resulted in a lockup of $150 million in Ether. While Ethereum does not offer a simple solution for high security wallets, there are a few steps you can take to prevent falling victim to such an attack.

The bug report filed by the “attacker”

In a traditional production software environment, we’re able to deploy code to a public interface such as a website. If the code does not appear to carry the functionality we hope it does, what happens? Perhaps no one notices, perhaps a few people complain, at the end of the day we can update the code and the minor nuisance is resolved. In the world of Ethereum, once we deploy a piece of code it is there forever, for everyone to see and play with. In an ideal world, only you have access to this code, in the world of blockchain everyone has access to it. This means that if a piece of code is deployed to the Ethereum network, its in most cases not possible to update it.

A Conversation With the “attacker”

If we put $1 million in Ether into a smart contract and the smart contract is found to contain a vulnerability, a few things may occur. It may go unnoticed, it may go noticed by a hacker who decides to exploit it, or it will be uncovered by the contract owner and they will be able to recover the funds. In this case it was exploited by an individual claiming to be “researching” the previous Parity hack.

The “attacker”

So how can we protect ourselves?

KISS Principle — Keep it simple stupid

Most smart contracts introduce vulnerabilities by attempting to account for corner cases and optimizations. The first Parity vulnerability was due to an attempt to optimize the amount of gas used during execution. The current Parity vulnerability was due to the inclusion of new, untested library functionality. A manageable smart contract will contain the minimum amount of functionality necessary to complete the task. Introducing code to optimize a premature solution increases the complexity of the contract, thereby reducing the security.

Unit Tests

In common software development as well as smart contract development it can be convenient to overlook adequate unit tests. When code is non-revocable once it reaches production, a higher level of diligence is required. As a rule of thumb, your smart contract should contain adequate unit tests to verify the functionality of your smart contract as well as the corner cases.

Smart Contract Audits

Any smart contract that is sent to production should undergo a security audit. A good smart contract security auditor will have experience building real-world smart contracts, a wealth of projects on GitHub, and will share a check list of the common vulnerabilities that they look for. Ensure the auditor can engage in conversation about the various attack vectors associated with your smart contract. This may not seem like a formal approach, however the industry is still very young and this is how it operates at the moment.

Following these guidelines can help reduce the risk and anxiety associated with sending smart contracts to the Ethereum Mainnet.

Test, Audit, Deploy.