Exchanges Made Misleading Claim MyEtherWallet Attack Was ERC-20 Vulnerability

Ethereum 4 min, 0 sec READ

by Martin Banov

After the $150000 MyEtherWallet phishing attack, some exchanges declared misleadingly that there was a general ERC-20 vulnerability.

On April 25th, a number of addresses on MyEtherWallet were drained as a result of the hijacking of a large chunk of Google's DNS servers. The batchOverflow hack was discovered after a trace of transactions going through a series of known scam-related addresses in Russia was discovered. Shortly after, a handful of exchanges (OKEx, Poloniex, QUOINE, and HitBTC) suspended all deposits and withdrawals of ERC-20 tokens, claiming that a newly found smart contract bug was the reason. Given that the vast majority of assets on the market conform to the ERC-20 standard, this came as quite the scare. 

This is how Poloniex put it:

"We've temporarily suspended ERC-20 token deposits and withdrawals while we review all smart contracts for exposure to the reported batchOverflow bug. We take any reports of vulnerabilities very seriously to ensure that customer funds remain safe. Thank you for your patience!"

And this is how OKEX reported it:

"To protect public interest, we have decided to suspend the deposits of all ERC-20 tokens until the bug is fixed. Also, we have contacted the affected token teams to conduct investigation and take necessary measures to prevent the attack."

This choice of wording is interesting since contract "bugs" cannot be "fixed" once live on the Blockchain. In addition, ERC-20 is a specification of token contracts defining a standard set of basic functions and meta-data that can be accepted only after extensive review by the Ethereum community. The said bug was a custom added function which had nothing to do with said ERC-20 specification. 

Furthermore, it has for a very long time now been common knowledge and standard practice that whenever writing Solidity contracts where there is arithmetic involved, the SafeMath library should be used to provide assertions against overflows of unsigned integers.

Two Important Questions

All of this leads to two questions that should be accounted for:

• Why are exchanges integrating obviously buggy contracts without doing contract audits, (which should by now be standard procedure), given the magnitude of their responsibility in handling market liquidity? 

• Why are there people writing buggy contracts vulnerable to such exploits, (whether or not they are doing so intentionally), given that, as PackShield pointed out, this is a classic integer overflow issue that can occur in any type of arithmetic and is nothing new?

Notorious Scams Repeated?

Notably, attempts to exploit overflows have been attempted before by notorious scams, which amusingly advertised themselves as such:

"We’re confident that EthPyramid is the pinnacle in affordable, repeatable, unreliable pseudo-investment opportunities for the gullible and over-rich. What if you had just one shot, one opportunity to make it big? Shouldn’t your narcotic-addled, sleep deprived mind jump at the chance to completely ignore it in order to throw your virtual internet at a few lines of code instead? If you were a pothead who stumbled onto a fortune of Bitcoin in 2012, after surfing the silk road for the newest synthetic MDMA derivative fresh out of a Chinese sweat shop, why not try one last time to squander the only shred of dignity you have left! You’re only human after all."

The easiest way to quickly verify if a contract is vulnerable is to simply check if SafeMath is used in the contract where additions, multiplications, and division operations are involved, and here are also Consensys's recommended best practices.

PackShield has listed 9 impacted tokens which used some abnormal lines of code not typical to standard ER20 tokens:

• MESH 0x3ac6cb00f5a44712022a51fbace4c7497f56ee31

• UGToken 0x43ee79e379e7b78d871100ed696e803e7893b644

• SMT 0x55F93985431Fc9304077687a35A1BA103dC1e081

• SMART 0x60be37dacb94748a12208a7ff298f6112365e31f

• MTC 0x8febf7551eea6ce499f96537ae0e2075c5a7301a

• FirstCoin 0x9e88770da20ebea0df87ad874c2f5cf8ab92f605

• GG Token 0xf20b76ed9d5467fdcdc1444455e303257d2827c7

• CNY Token 0x041b3eb05560ba2670def3cc5eec2aeef8e5d14b

• CNYTokenPlus 0xfbb7b2295ab9f987a9f7bd5ba6c9de8ee762deb8

In conclusion, it is advisable for people investing in any crypto asset to do a quick check of the smart contract code on Github and ensure that basic safety guidelines are met before depositing any funds in a token contract. Consensys has also additionally provided a smart contract security analysis and audit tool, (Mythril, found at https://github.com/ConsenSys/mythril), which can be run against Solidity contracts both locally and on mainnet as a traditional vulnerability scanner, with a single command issued from the command line.