New burnOverflow Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-11239)

Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5]). Some of them could be used by attackers to generate tokens out of nowhere while others can be used to steal tokens from legitimate holders.

Today, we would like to report another vulnerability called burnOverflow that affects a few ERC20-related tokens. In particular, one such token, i.e., Hexagon Token (HXG), has already been attacked in the wild. Specifically, on 5/18/2018, 12:55:06 p.m. UTC, PeckShield detected such attacking transaction (as shown in Figure 1) where someone calls transfer() with a huge amount of HXG token — 0xffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,fffe to another address without actually spending any HXG token.

Figure 1: An Abnormal HXG Token Transfer (with Huge Amount)

From our investigation, we show in Figure 2 the implementation logic of the standard ERC-20 transfer() function in the HXG smart contract. It simply calls _transfer() (in line 26) to perform the actual task.

Figure 2: ERC-20 Standard transfer() Implementation

In the _transfer() function, we can see that in line 81, the calculation of _value + burnPerTransaction could be overflowed for bypassing the check of sender’s balance.

Figure 3: A burnOverflow-affected Smart Contract

Since burnPerTransaction is set as 2, the attacker can make _value + burnPerTransaction = 0 by making _value = 0xffff,ffff,ffff,….,fffe. As the balance of _to is less than 2, the check in line 85 could be passed. Then, the balance of _from is decremented by 0 (_value + burnPerTransaction) in line 85. Finally, the tremendous amount of HXG token is added to balanceOf[_to] in line 87.

Since HXG token is currently listed in token.store for trading, we contact the development team at the first place to prevent any possible financial loss. As warned in our vulnerability reports, all the calculations without utilizing SafeMath can easily introduce vulnerabilities in smart contracts and cause undesirable damage or loss.