Vulnerabilities > CVE-2018-12703 - Improper Input Validation vulnerability in Block18

047910
CVSS 5.0 - MEDIUM
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
NONE
Integrity impact
PARTIAL
Availability impact
NONE
network
low complexity
block18
CWE-20

Summary

The approveAndCallcode function of a smart contract implementation for Block 18 (18T), an tradable Ethereum ERC20 token, allows attackers to steal assets (e.g., transfer the contract's balances into their account) because the callcode (i.e., _spender.call(_extraData)) is not verified, aka the "evilReflex" issue. NOTE: a PeckShield disclosure states "some researchers have independently discussed the mechanism of such vulnerability."

Vulnerable Configurations

Part Description Count
Application
Block18
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
description[Update: (2018-06-24) With swift, coordinated response from Huobi.pro, we appreciate the announcement [11] on suspending the deposits and withdrawals of affected tokens!] Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflow[1], proxyOverflow[2], transferFlaw[3], ownerAnyone[4], multiOverflow[5], burnOverflow[6], ceoAnyone[7], allowAnyone[8], allowFlaw[9]), tradeTrap[10]). Some of them could be used by attackers to generate tokens out of nowhere or steal tokens from legitimate holders, while others can be used to take over the ownership from legitimate contract owner (or administrator). In this blog, we disclose a new type of vulnerability named evilReflex. By exploiting this bug, the attacker can transfer an arbitrary amount of tokens owned by a vulnerable smart contract to any address. Specifically, whenever a smart contract has non-zero token balance, those tokens could be swept out by an attacker. ![](https://images.seebug.org/1531120450985-w331s) Credit: https://gdblogs.shu.ac.uk/b5023021/2017/02/22/self-reflection/ In Figure 1, we show the vulnerable approveAndCallcode() function of an evilReflex-affected smart contract. The issue is in line 135, where _spender.call() is invoked with the user-controllable parameter _extraData. By design, the intended use of this callback function is to send out related notification while finishing an approve() operation. However, by tweaking the _extraData, an attacker can completely hijack the callback to do something unintended by the original design. ![](https://images.seebug.org/1531120461634-w331s) Figure 1: An evilReflex-affected Smart Contract In other words, such vulnerability will essentially allow an attacker to call any contract address from a vulnerable contract, with arbitrary parameters! One thing she immediately obtains would be the privileges of the victim contract. In some smart contracts, the contract address itself might be used for authorization purposes so that certain privileged operations will only be issued from the contract itself. From another perspective, if the vulnerable contract happens to own certain tokens, which are likely the case for the contract to receive ETH payments or distribute certain ERC20 tokens, an attacker might easily steal these crypto assets. How to do that? The attacker can exploit the evilReflex bug by making the contract to call the transfer() function of itself. Specifically, she can simply set _spender as the contract address with a tweaked _extraData. And the tweaked _extraData starts from the signature of transfer() followed by the two parameters to and value. This way, the contract issues a transfer() call which could transfer all of its tokens out. Figure 2 illustrates a tweaked _extraData we observed in an “in-the-wild” attack. ![](https://images.seebug.org/1531120473245-w331s) Figure 2: Tweaked *_extraData* Used in An "In-the-Wild" Attack So far, our system has found at least 28 vulnerable smart contracts which are affected by this bug. And several of them are tradable on top cryptocurrency exchanges. Furthermore, one of the tradable ERC20 tokens had been attacked in the wild with at least 100 tokens stolen. As for this writing, we are still in the process of contacting related project teams behind these tokens and affected cryptocurrency exchanges [11] to remedy this issue. Please contact us if we can be of any help regarding evilReflex. We would like to point out that we internally discovered this vulnerability about a month ago. However, due to the severity of affected tokens and tradable facts in related exchanges, we chose not to disclose the vulnerability until today – after the coordinated response with major exchanges [11]. In the meantime, some researchers have independently discussed the mechanism of such vulnerability in the same nature, though in a different ERC223 context [12]. About US PeckShield Inc. is a leading blockchain security company with the goal of elevating the security, privacy, and usability of current blockchain ecosystem. For any business or media inquires (e.g., smart contract auditing), please contact us at telegram, twitter, or email.
idSSV:97414
last seen2018-07-09
modified2018-07-09
published2018-07-09
reporterKnownsec
titleNew evilReflex Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-12702, CVE-2018-12703)