Authors:Jacob Baines Risk：High CVE：CVE-2018-10468 0day:Smart Contract 0day -id:0DAY-176120 Date：2018-04-29
The transferFrom function of a smart contract implementation for Useless Ethereum Token (UET), an Ethereum ERC20 token, allows attackers to steal assets (e.g., transfer all victims’ balances into their account) because certain computations involving _value are incorrect, as exploited in the wild starting in December 2017, aka the “transferFlaw” issue.
Our automated scanning system at PeckShield discovered a new vulnerability named transferFlaw (CVE-2018–10468). This particular vulnerability affects a publicly traded ERC20 token listed in a top exchange. Different from batchOverflow  and proxyOverflow  we identified before, this vulnerability does not lead to generating countless tokens. Instead, this one, when exploited, can be used by attackers to steal others’ tokens.
Our in-depth code analysis further indicates that it is probably a scam token. We have promptly notified affected exchanges to delist the related token. Note that the token has been publicly tradable for about 10 months even though at a relatively low trade volume, we believe it poses a realistic threat to legitimate users and cryptocurrency market as a whole.
We have analyzed a number of related smart contracts. In the following, we show the vulnerable transferFrom() function.
Figure 1: A transferFlaw-affected Smart Contract
In order to understand the vulnerability, let’s suppose that a victim user _tocurrently has a balances[_to]=1 and the attacker _from has no balance yet (i.e., balances[_from]=0). When the attacker sends a transaction invoking the vulnerable function with argument _value=0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (64 f’s),
transferFrom(_from, _to, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff)
the execution proceeds as follows:
line 53) fromBalance=0, line 54) allowance=0, line 56) sufficientFunds=TRUE, line 57) sufficientAllowance=TRUE, line 58) overflowed=FALSE.
Finally, the condition in line 60 will be evaluated TRUE:
line 60) (sufficientFunds && sufficientAllowance && !overflowed) = TRUE
With that, the code in line 61 makes balances[_to] =0, and the code in line 62 changes balances[_from] to 1. In other words, the balances of victim “_to” has been transferred to the attacker “_from”.
While scanning through our collection of smart contracts that are deployed in mainnet, we have found tens of them affected by transferFlaw. Among them, a token named UET caught our attention as it is currently tradable in a top exchange, i.e., hitBTC.
Even worse,our analysis also shows that this vulnerability has been already exploited in the wild since 2017/12/23 in multiple transactions. In Figure 2, we show a recent one:
Figure 2: A Suspicious UET Token Transfer (with huge amount)
Upon the detection of in-the-wild exploitation, we have immediately notified hitBTC with the vulnerability details. Fortunately, hitBTC quickly gets back to us and we will work together to get the problem solved.
In the meantime, to better protect legitimate users, we feel necessary to make it known to public. Moreover, while performing an in-depth investigation of the smart contract, we made an interesting observation that makes us to consider this vulnerability might be intentionally planted. Specificially, let’s take a closer look at the transfer() function right above the vulnerable transferFrom() function.
Figure 3: transfer() of UET Token Contract
If we compare the code in lines 35–36 (sufficientFunds and overflowed) in figure 3 with the counterparts in figure 1, it is quite ludicrous as the vulnerability could be eliminated by a simple copy-and-paste action in consideration of their similar functionality. From the typical programming practice perspective, it is an extremely unusual behavior!
The recent flurry of smart contract vulnerabilities (i.e., batchOverflow , proxyOverflow , and now transferFlaw) reminds us the importance of auditing smart contracts before their deployment. Also, since some affected tokens are publicly traded in a variety of exchanges, we believe exchanges need to step up by requiring high-quality (or even publicly verifiable) smart contract audits before allowing related tokens to be listed for trading.
In addition, exchanges also share the responsibility of establishing a transparent, reliable security response process that not only serves their best interests (in providing safe and reliable trading services to their own customers), but also helps improve the community as a whole.
-  batchOverflow (CVE-2018–10299): https://www.peckshield.com/2018/04/22/batchOverflow/
-  proxyOverflow (CVE-2018–10376): https://www.peckshield.com/2018/04/25/proxyOverflow/