Built on earlier efforts with analyzing EOS tokens, we have developed an automated system that can scan and analyze Ethereum-based (ERC-20) token transfers. Specifically, our system will automatically send out alerts if any suspicious transactions takes place.
An unusual BEC token transaction (shown in Figure 1). In this particular transaction, someone transferred a large amount of BEC tokens — 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000(63 0’s — In fact, there’re actually two such large token transfers, with each transfer involving the same amount of tokens from the same BeautyChain contract but to two different addresses).
Figure 1: A Suspicious BEC Token Transfer (with large amount)
This anomaly prompted us to look into the related smart contract code. The study shows that such transfer comes from an “in-the-wild” attack that exploits a previously unknown vulnerability in the contract. For elaboration, we call this particular vulnerability batchOverflow. We point out here that batchOverflow is basically a classic integer overflow issue. In the following, we examine in more details the batchOverflow vulnerability.
Figure 2: The Vulnerable Function: batchTransfer()
The vulnerable function is found in batchTransfer and the code is shown in Figure 2. As indicated in line 257, the amount local variable is calculated as the product of cnt & _value. The second parameter, i.e., _value, may be an arbitrary 256 bits integer, say 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000(63 zeros). By having two _receivers passed into batchTransfer(), with that extremely large _value, we can overflow amount and make it zero. With amount zeroed, an attacker can then pass the sanity checks in lines 258–259 and make the subtraction in line 261 irrelevant.
Here comes the interesting part: as shown in lines 262–265, the balance of the two receivers would be added by the large _value without costing a nickel in the the attacker’s pocket.
Results show that more than a dozen of ERC20 contracts are also vulnerable to batchOverflow. To demonstrate, we have successfully transacted with one vulnerable contract (that is not trade-able in any exchange) as our proof-of-concept exploit (Figure 3).
Figure 3: Proof-of-Concept Exploit against batchOverflow
With the touted “code-is-law” principle in Ethereum blockchain, there is no traditional well-known security response method in place to cure these vulnerable contracts.
With potential values associated with these tokens unfortunately are not in the position to react by suspending the trading of vulnerable tokens in multiple exchanges. Fortunately, effectively at 4:13 p.m. GMT+8, OKEx made an announcement to suspend the withdrawal and trading of BeautyChain (BEC), a batchOverflow-affected token. Nevertheless, other exchanges also need to be coordinated and there still exist other trade-able tokens vulnerable to batchOverflow. The presence of non-centralized exchanges with offline trading services might pose additional issues as they can not stop attackers from laundering their tokens.
We might face additional serious complexities. Specifically speaking, it is very likely for an attacker to possess a huge amount of tokens by exploiting these vulnerable contracts.
With the extremely large amount of tokens in possession (likely larger than totalSupplyin circulation), the attack might easily manipulate the price of related cryptocurrencies. This immediately reminds us the recent Binance incident  happened early last month that the criminal crew drove up Viacoin by controlling Binance customers’ accounts to cash out on the other side.