This is Part I of a two-part post.

Last night, as I’m sure most of you have already heard, it was reported that the decentralized exchange Bancor was “hacked” and about 25,000 ETH (~$12.5M), 230,000,000 NPXS (~$1M), and 3,200,000 BNT (~$10M) were stolen in the process. The stolen BNT were later frozen, using Bancor’s safety hatch, but the remaining funds are still running loose.

The investigation is still underway and it’s far too early to draw any major conclusions, so I really wanted this to be a blameless initial analysis of what has happened and how similar attacks might be prevented. Losing these sums shouldn’t happen to anyone. I sincerely hope that the Bancor community and team will be able to recover all of these lost funds and that this incident will make us all stronger, as a community, Bancor in particular.

Bancor suspended trading immediately:

What Went Wrong?

There are many hints that the malicious behavior actually started a few days ago. On July 9th, at around 12AM (UTC), about 22,000 of EtherTokens were withdrawn from the BancorConverter smart contract by by the 0x009bb5e9fcf28e5e601b7d0e9e821da6365d0a9c account. The tokens, in addition to other tokens which were retrieved in a similar way, were used for some buying and selling operations and were eventually “cashed out.”

The first malicious transaction

EtherToken, for those of you who aren’t aware, is an ERC20 token which is used by Bancor relays to convert between Ether and various token pairs. For all intents and purposes, it’s fully convertible to Ether on a 1:1 basis. In effect, stealing EthereTokens is equivalent to stealing actual Ether.

You might ask yourself, how was this even possible in the first place?

First of all, it’s important to note that the 0x009bb5e9fcf28e5e601b7d0e9e821da6365d0a9c address was a designated “owner” of the BancorConverter smart contract (a widely used Solidity access restriction design pattern).

As part of Bancor’s safety hatch/backdoor (which was criticized by Udi Wertheimer here and followed Bancor’s response here), this address was granted special permission to withdraw any deposited funds:

This feature, alongside the ability to forcefully issue, burn, and transfer any Bancor Smart Tokens tokens, was introduced as a security countermeasure, but it definitely looks like it has backfired.

What Can We Learn From this?

We should be very mindful of security when introducing centralized security counter-measures. It doesn’t always make sense (some will even claim it never makes sense) and can backfire just as easily. In the event that you have to give some special privileges to a specific account, please consider a Multi-signature Wallet address instead. Of course, while we know that Ethereum multisigs introduce other attack vectors (e.g., the nefarious Parity hacks) and may contains bugs themselves, it can still be a great tradeoff. For example, requiring a minimum of 12 out of 15 signatures in order to withdraw tokens is a much better scheme that relying on a single account’s signature (it also mitigates other undesired scenarios, such as losing the private key, extortion or worse). Always prefer working with a Hardware Wallet. It’s an unbelievably easy, affordable, and convenient way to store your private keys with great security. Consider introducing, or reevaluate your “Plan B” countermeasures. For example, similarly to the DAO incident, one could add a built-in execution delay with a revocation ability. In this scenario, even if the “owner” (which with a multisig account, mind you, requires thata committee of entities agreed to this arrangement in the first place) decides to withdraw some tokens, the actual transfer will only happen 24 hours/1 week/30 days after the request. Additionally, there is another committee that can cancel this request during this period of time.

We also believe that any security measures should be conveniently provided by the underlying infrastructure, without the need for DYI solutions (unlike in Ethereum, for example).

In Conclusion

It’s very important to understand that there is no silver bullet. Adopting any approach or counter measure should be carefully considered as yet another layer, or merely a speed bump. Every such layer is meant to increase the cost of an attack, and hopefully, deter it altogether.

If there’s no “one size fits all” solution — does it mean that there is no hope and we shouldn’t do anything? Of course not. We have to keep making our best effort and be mindful of security.

This is Part I of a two-part post. Click here for Part II.