ALERT: New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018-10299)

最新推荐文章于 2022-07-09 09:10:43 发布

转载最新推荐文章于 2022-07-09 09:10:43 发布 · 425 阅读

【区块链】同时被 2 个专栏收录

256 篇文章

订阅专栏

智能合约安全

32 篇文章

订阅专栏

本文揭示了一起涉及BEC代币的大规模异常转账事件，通过分析发现这是由于智能合约中存在未知漏洞导致的。该漏洞允许攻击者通过特定操作使转账金额溢出并归零，进而非法增加接收方账户余额。

Built on our earlier efforts in analyzing EOS tokens, we have developed an automated system to scan and analyze Ethereum-based (ERC-20) token transfers. Specifically, our system will automatically send out alerts if any suspicious transactions (e.g., involving unreasonably large tokens) occur.

In particular, on 4/22/2018, 03:28:52 a.m. UTC, our system raised an alarm which is related to an unusual BEC token transaction (shown in Figure 1). In this particular transaction, someone transferred an extremely large amount of BEC token —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 huge amount)

This anomaly prompted us the need to look into the related smart contract code. Our 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 vulnerabilitybatchOverflow. We point out that batchOverflow is essentially 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 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, say0x8000,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!

With that, we further run our system to scan and analyze other contracts. Our 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 tradable in any exchange) as our proof-of-concept exploit (Figure 3).

By the time of writing this blog, we have also made efforts to contact the teams who own these vulnerable contracts. However, with the touted “code-is-law” principle in Ethereum blockchain, there is no traditional well-known security response mechanism in place to remedy these vulnerable contracts! Moreover, with potential values associated with these tokens, we, as a third-party independent security team, unfortunately are not in the position to react by suspending the trading of vulnerable tokens in various exchanges. Fortunately, effectively at 4:12 p.m. GMT+8, OKEx made an announcement to suspend the withdrawal and trading of BeautyChain (BEC), a batchOverflow-affected token. However, other exchanges also need to be coordinated and there still exist other tradable tokens vulnerable to batchOverflow! The presence of non-centralized exchanges with offline trading services might pose additional challenges as they cannot even stop attackers from laundering their tokens.

On the other hand, we might face additional serious complexities. Specifically, it is very likely for an attacker to possess a huge amount of tokens by exploiting these vulnerable contracts. What if she go to a cryptocurrency exchange and start to trade those tokens for ETH, BTC, or even USD? With the extremely large amount of tokens in possession (likely larger than totalSupply in circulation), the attack might easily manipulate the price of related cryptocurrencies. This immediately reminds us the very recent Binance incident [1] happened early last month that the criminal crew drove up Viacoin by controlling Binance customers’ accounts to cash out on the other side.