Your Tokens Are Mine: A Suspicious Scam Token in A Top Exchange

Our automated scanning system at PeckShield discovered a new vulnerability namedtransferFlaw (CVE-2018–10468). This particular vulnerability affects a publicly traded ERC20 token listed in a top exchange. Different from batchOverflow [1] and proxyOverflow[2] 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.

Details

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 _to currently 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”.

Affected Tokens

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!

Conclusion

The recent flurry of smart contract vulnerabilities (i.e., batchOverflow [1], proxyOverflow [2], 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.

References

• [1] batchOverflow (CVE-2018-10299):https://www.peckshield.com/2018/04/22/batchOverflow/

• [2] proxyOverflow (CVE-2018-10376):https://www.peckshield.com/2018/04/25/proxyOverflow/