Vulnerabilities > CVE-2018-10468 - Improper Input Validation vulnerability in Uetoken Useless Ethereum Token

047910
CVSS 7.5 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
HIGH
Integrity impact
NONE
Availability impact
NONE
network
low complexity
uetoken
CWE-20

Summary

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.

Vulnerable Configurations

Part Description Count
Application
Uetoken
1

Common Weakness Enumeration (CWE)

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Buffer Overflow via Environment Variables
    This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
  • Server Side Include (SSI) Injection
    An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands.
  • Cross Zone Scripting
    An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security. In a zone-based model, pages belong to one of a set of zones corresponding to the level of privilege assigned to that page. Pages in an untrusted zone would have a lesser level of access to the system and/or be restricted in the types of executable content it was allowed to invoke. In a cross-zone scripting attack, a page that should be assigned to a less privileged zone is granted the privileges of a more trusted zone. This can be accomplished by exploiting bugs in the browser, exploiting incorrect configuration in the zone controls, through a cross-site scripting attack that causes the attackers' content to be treated as coming from a more trusted page, or by leveraging some piece of system functionality that is accessible from both the trusted and less trusted zone. This attack differs from "Restful Privilege Escalation" in that the latter correlates to the inadequate securing of RESTful access methods (such as HTTP DELETE) on the server, while cross-zone scripting attacks the concept of security zones as implemented by a browser.
  • Cross Site Scripting through Log Files
    An attacker may leverage a system weakness where logs are susceptible to log injection to insert scripts into the system's logs. If these logs are later viewed by an administrator through a thin administrative interface and the log data is not properly HTML encoded before being written to the page, the attackers' scripts stored in the log will be executed in the administrative interface with potentially serious consequences. This attack pattern is really a combination of two other attack patterns: log injection and stored cross site scripting.
  • Command Line Execution through SQL Injection
    An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.

Seebug

bulletinFamilyexploit
descriptionOur 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 [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. ![](https://images.seebug.org/1527734240412-w331s) 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: ![](https://images.seebug.org/1527734301602-w331s) 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. ![](https://images.seebug.org/1527734313253-w331s) 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.
idSSV:97318
last seen2018-06-26
modified2018-05-31
published2018-05-31
reporterMy Seebug
titleNew transferFlaw Bug Used For Possible Scam Token Listed In A Top Exchange(CVE-2018-10468)