Anatomy of a Hacking Business

On July 7, 2018, we watched as a hack of our ERC20 token smart contract unfolded. What followed over the next few days cast light on how close the hacking activity lies to the booming industry of security reviews and vetting of smart contracts in the Ethereum space. This mirrors what I have long suspected takes place in the anti-virus space, and possibly other cybersecurity arenas.

Let me first give some background. Our company builds a number of products that use Blockchain technology, but we are not an Ethereum shop. That is to say, we are not focussed on using Ethereum specific tools, and we are generally neutral as to Blockchain technologies. We have created our own consensus technology, rooted in a low-cost ASIC that will be embedded in our own hardware (routers) and various smart devices — hopefully also those from other companies. However, our tech is not yet fully developed, so we created a token using the ERC20 standard, which is used by the overwhelming majority of players in the crypto and ICO world.

In order to create the ERC20 compliant token, one writes a smart contract that issues the set number of tokens, and then shuts down. Think of it as a micro-central bank that prints a certain amount of currency, then closes its doors.

Since we are not Ethereum people, we hired an outside firm to write our smart contract, and had it reviewed for security purposes. Green lights.

We launched our contract, minted some tokens, sold a few privately, and then listed them on an exchange. (Not as easy as all that, but you get the drift).

Then, a few days after listing, we saw a large number suddenly appear for sale in the exchange. According to our numbers that should not have been possible. The exchange had a lot of tokens in hand, since we had to place tokens there to have liquidity for people wanting to buy, but they confirmed they were not selling. So where did the tokens come from?

Blockchain is a wonderful thing. You have a public ledger that allows you to check the providence of tokens, and every transaction involving the transfer of tokens. So we started digging.

It didn’t take long to find the problem. Someone had identified a vulnerability our vetting process had missed, and had started exploiting it. Basically they use what is generically an integer overflow exploit. By issuing an instruction to the contract for a number that is larger than the defined size of a value, a large number of tokens appear out of fresh air. It fools the ledger for that token to not increase the global number of tokens, while crediting tokens to a particular wallet. A very dangerous exploit.

To cover his/her tracks, the hacker then sent the vast majority of these illicit tokens to the null address, which effectively “burns” them. 0x0000000000000000000000000000000000000000

The tokens that remain can then be sold in the market. In our case on an exchange, in exchange for ETH. The hacker proceeded to sell these illicit tokens to unsuspecting customers, and before the exchange could comply with our request to freeze all trading (sent at 2am Hong Kong time, when senior decision makers could not be reached), managed to extract some of it from the exchange. The damage was exceptionally small in this space, limited to us compensating the buyers of the illicit tokens with actual tokens when we remediate the situation, and start trading again. Some projects lose millions in such a hack, but we suffered only minimal losses.

We tracked the ETH, and it became evident that ours was not the first hack. Several other tokens had been exploited, and the hacker was doing a roaring trade.

With a bit of sleuth work we identified at least one exchange (they do not publish their wallet addresses) to which the illicitly garnered ETH had been sent to launder, and possibly turn into cash. We sent information, requesting information. So far no answers, but we are hopeful.

This highlights another problem. Will an exchange willingly give up a hacker who is moving value through their exchange, unless compelled to do so by a court order? For many years a similar conundrum plagued mobile networks. Stolen phones could be identified on a mobile network through their IMEI numbers, and it is entirely within the capability of an operator to deny service to such a phone. However, even stolen phones generate call and data revenues for an operator. What is the incentive to shut them down? The loss lay with the handset owner, not the network. So, even though an exchange can identify criminal wallets and transactions, why would they if they are still gaining revenues?

This is a fairly predictable course of events, but what came next was a bit of a surprise.

Within 24 hours the first articles started to appear on Chinese blog sites. Within 48 hours the first Medium article appeared in English — an almost direct translation of the Chinese blog articles, but with a difference. The Chinese blog article promotes the services of BYSEC.IO Security Lab, and the English article promotes the services of SECBIT Labs, also a Chinese operation.

While we are not an Ethereum shop, we do have some pretty awesome coders and security experts in-house. They were surprised at the speed at which this discovery was made — considering we are really very low profile in this space — and written up by blog writers, and disseminated. Since there is no evidence of collusion once would have to draw your own conclusions.

This does not conclude our investigation, and there are many questions. How are such vulnerabilities found and reported on so quickly? The one article claims they tried to contact us, but no such contact was made. This article by Davey Winder from 2016 makes for interesting reading.

Disclaimer: My views are my own, and are not those of my employer, or any associated entity.