New smart contract Bug BatchOverflow - updated

[AlekSandRAx]

2018-04-25
OKEx and Poloniex suspended all ERC-20 tokens deposits and withdrawals to review all smart contracts for exposure to the new smart contract bug BatchOverFlow. While Poloniex already re-enabled deposits and withdrawals, OKEx's deposits are still suspended.

BatchOverflow Bug is a classic integer overflow issue. By exploiting the bug, attackers can generate an extremely large amount of tokens, and deposit them into a normal address. This makes many of the ERC-20 tokens vulnerable to price manipulations of the attackers.

The first detection of New proxyOverflow Bug occurred on 2018-04-22 by PeckShield. During the scan and analysis of Ethereum-based (ERC-20) token transfers, which they built on their earlier efforts in analyzing EOS tokens, PeckShield's system raised an alarm caused by an unusual BEC token transaction.(Figure 1)


Figure 1: Huge amount of BEC Token Transfer



The study of the code has revealed that such transfer comes from an ''in-the-wil'' attack that exploits a previously unknown vulnerability in the contract.

The vulnerable function is located 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 and _value. The second parameter, i.e., _value, can be an arbitrary 256 bits integer, say 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000(63 0’s). 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. Finally, here comes the interesting part: as shown in lines 262–265, the balance of the two receivers would be added by the extremely large _value without costing a dime in the the attacker’s pocket!

PeckShield (https://peckshield.com/2018/04/22/batchOverflow/)


Figure 2: The Vulnerable Function: batchTransfer()




Further analysis shown that more than a dozen of ERC20 contracts are vulnerable to this bug. To demonstrate, they've successfully transacted with one vulnerable contract (not tradable in any exchange) as a proof-of-concept exploit (Figure 3).


Figure 3: Proof-of-Concept Exploit



On 2018-04-24 they detected more of suspicious token transactions (Figure 4 & 5).


Figure 4: Unusual MESH token transaction




Figure 5: Unusual SMT token transaction




Figure 6: proxyTransfer() function classic integer overflow problem

As shown in Figure 6, both _fee and _value are input parameters which could be controlled by the attacher. If _fee + _value happens to be 0 (the overflow case), the sanity checks in line 206 could be passed. It means the attacker could transfer huge amount of tokens to an address (line 214) with zero balance. Also, a huge amount fee would be transferred to the msg.sender in line 217.

PeckShield (https://peckshield.com/2018/04/25/proxyOverflow/)

Affected ERC20 tokens list:

	|		|	Token	|	Related Contract	|
	|	1	|	MESH	|	0x01f2acf2914860331c1cb1a9acecda7475e06af8	|
	|	2	|		|	0x3ac6cb00f5a44712022a51fbace4c7497f56ee31	|
	|	3	|	UGToken	|	0x43ee79e379e7b78d871100ed696e803e7893b644	|
	|	4	|	SMT	|	0x55F93985431Fc9304077687a35A1BA103dC1e081	|
	|	5	|	SMART	|	0x60be37dacb94748a12208a7ff298f6112365e31f	|
	|	6	|	MTC	|	0x8febf7551eea6ce499f96537ae0e2075c5a7301a	|
	|	7	|	FirstCoin	|	0x9e88770da20ebea0df87ad874c2f5cf8ab92f605	|
	|	8	|	GG Token	|	0xf20b76ed9d5467fdcdc1444455e303257d2827c7	|
	|	9	|	CNY Token	|	0x041b3eb05560ba2670def3cc5eec2aeef8e5d14b	|

|

10

|

CNYTokenPlus

|

0xfbb7b2295ab9f987a9f7bd5ba6c9de8ee762deb8

|

For more informations on the subject, see the links bellow.

Sources:

* https://peckshield.com/2018/04/22/batchOverflow/
* https://peckshield.com/2018/04/25/proxyOverflow/
* https://support.okex.com/hc/en-us/articles/360003019292-ERC-20-Tokens-Deposit-Suspended
* https://cryptoslate.com/batchoverflow-exploit-creates-trillions-of-ethereum-tokens/
* https://twitter.com/Poloniex/status/989123551788785666
* https://www.reddit.com/r/CryptoCurrency/comments/8esjp2/worlds_first_octodecillionaire_1056_is_here/#bottom-comments

[1715564514]

1715564514

[1715564514]

1715564514

[1715564514]

1715564514

[1715564514]

1715564514

[1715564514]

1715564514

[1715564514]

1715564514

[paxmao]

Quanstamp has audited all tokens from Binance finding that none of them were vulnerable to this attack.

https://themerkle.com/quantstamp-successfully-audited-all-of-binances-erc20-tokens/

"This is where Quantstamp and other companies can make a positive impact in the future. The firm specializes in performing security audits of smart contracts [...]

As such, the company assisted Binance by auditing all of its listed ERC20 tokens. The main focus was on determining whether or not these tokens were subject to batchOverflow and proxyOverflow 0-day vulnerabilities. [...] Quantstamp audit found that Binance’s supported tokens are all safe from harm at this stage. This confirms that not every ERC20 tokens is created equal, but it is good to see the damage limited to just a handful of tokens rather than the majority of ERC20 tokens."