Vulnerabilities > CVE-2018-11446 - Integer Overflow or Wraparound vulnerability in Gold Reward Project Gold Reward
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
NONE Integrity impact
PARTIAL Availability impact
NONE Summary
The buy function of a smart contract implementation for Gold Reward (GRX), an Ethereum ERC20 token, allows a potential trap that could be used to cause financial damage to the buyer because of overflow of the multiplication of its argument amount and a manipulable variable buyPrice, aka the "tradeTrap" issue.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Forced Integer Overflow This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.
Seebug
| bulletinFamily | exploit |
| description | [Update: (2018-06-12) The BMB (BMB) contract (0x0e935e976a47342a4aee5e32ecf2e7b59195e82f) is NOT affected by tradeTrap. We sincerely apology for mistakenly listing it as a vulnerable ERC20 token.] Quoted from our last blog [1], “publicly tradable ERC-20 tokens have considerable high market value. Various exchanges, either centralized (e.g., Binance, Huobi.pro, and OKex) or decentralized (e.g., IDEX, EtherDelta, ForkDelta), provide the marketplace by listing them, especially with high-liquidity ones, for public trading. Evidently, the transparency and security of their corresponding smart contracts is paramount. In practice, there is a de-facto requirement for these contract to be publicly verifiable on etherscan.io. Moreover, reflecting the fundamental ‘code-is-law’ spirit and trust of blockchain technology, these contracts once deployed should not be further subject to centralized control or manipulation.” After publishing our blog [1], we have been contacted by a number of affected cryptocurrency exchanges. As we believe the corresponding mitigation mechanism is now in place, it is the time to disclose the details of tradeTrap. As emphasized in [1], once smart contracts of publicly tradable ERC-20 tokens are deployed, they should not be further subject to centralized control or manipulation. Unfortunately, tradeTrap plagues 700+ ERC20 tokens and we have so far confirmed at least dozens of them are publicly tradable on current exchanges, including Binance, Huobi.pro, OKex, OKCoinKR, CoinEgg, Kucoin, Allcoin, HitBTC, Bitbns, ZB, OTCBTC, CoinBene, COSS, EtherDelta, ForkDelta, IDEX, YEX, Tidex, Radar Relay, Yobit, WazirX, CoinExchange, CoinSpot, Bluetrade, CEX, and Livecoin. The full list of tradeTrap-affected ERC20 tokens is available here. While we intend to think these contracts are deployed with good will and without any hidden or unintentional purpose, the existence of highly manipulatable interfaces (or knobs), however, could be exploited to either make inappropriate arbitrage or even directly control buy / sell prices of affected tokens. All these will eventually result in financial loss for trading customers and essentially reflect lack of enough security of affected exchanges when listing these tokens for trading. In the following, we would like to disclose two types of manipulatable interfaces which could be exploited to achieve unfair arbitrage. ### Security Issue 1: Arbitrary Increase in Token Balance Firstly, we would like to expose an interface which can be used to arbitrarily increase the token balance of arbitrary address, completely at the control of contract owner! As shown in Figure 1, a function named mintToken() is implemented in these ERC20 smart contracts.  Figure 1: The questionable mintToken() function of affected smart contracts In general, this function is accessible only by the contract owner, which is used to increase the token supply. However, in spite of a reasonable functionality during the presale period, the invocation to this function should be constrained in some way to avoid any abuse. Otherwise, a malicious owner is capable of sending tokens to a specified addresses arbitrarily. These tokens issued with zero-cost could completely destroy the market at the cryptocurrency exchanges. As of this writing, we have discovered 10 tradable tokens that suffer from this issue: | Name (Symbol) | Address | Exchanges | | ------------ | ------------ | ------------ | | PolyAI (AI) | 0x5121e348e897daef1eef23959ab290e5557cf274|CoinExchange, Mercator, EtherDelta, ForkDelta, Tradesatoshi, Novaexchange | |Substratum (SUB) | 0x12480e24eb5bec1a9d4369cab6a80cad3c0a377a |Binance, OKEx, ZB, OKCoinKR, Kucoin, HitBTC, Bitbns, COSS, IDEX, EtherDelta, ForkDelta, Tidex, Radar Relay, Yobit, WazirX, CoinExchange, CoinSpot | |Internet Node Token (INT) | 0x0b76544f6c413a555f309bf76260d1e02377c02a |OKEx, CoinEgg, YEX, Allcoin, EtherDelta, ForkDelta| |Fujinto (NTO) |0x8a99ed8a1b204903ee46e733f2c1286f6d20b177 |Etherdelta, ForkDelta| |GOAL Bonanza (GOAL) |0x7b69b78cc7fee48202c208609ae6d1f78ce42e13 |Etherdelta, ForkDelta| |Target Coin (TGT)|0xac3da587eac229c9896d919abc235ca4fd7f72c1|HitBTC, CoinExchange, IDEX, EtherDelta, ForkDelta| |BitAsean (BAS)|0x2a05d22db079bc40c2f77a1d1ff703a56e631cc1|HitBTC, Etherdelta, Forkdelta| |ClassyCoin|0x30cc0e266cf33b8eac6a99cbd98e39b890cfd69b|EtherDelta, ForkDelta| |FaceCoin (FC)|0xe6923e9b56db1eed1c9f430ea761da7565e260fe|EtherDelta, ForkDelta| |TBOT (TBT)|0xafe60511341a37488de25bef351952562e31fcc1|Etherdelta, Forkdelta| These 10 tokens are listed in 23 exchanges, including top ones like Binance and OKEx. Part of the tokens are tradable with high transaction volume and may affect tens of thousands of trading customers once being exploited. ### Security Issue 2: Manipulatable Prices and Unfair Arbitrage Secondly, we would like to expose a series of functions that can be directly used to achieve arbitrage. In essence, there exists three manipulatable interfaces, defined in corresponding functions i.e., setPrices(), buy() and sell() (Figure 2). The setPrices() function, protected by the onlyOwner modifier, merely allows the owner to set the buy / sell prices of the tokens. The buy() and sell() functions are public accessible and can be used by any trading customers to buy some tokens or sell the tokens they owned.  Figure 2: The manipulatable interfaces of affected smart contracts A keen reader may notice that the aforementioned buy / sell prices seem a little bit weird, as the prices of a tradable token should be determined by the market (i.e., exchanges). Here comes the tricky but interesting part: anyone can be an arbitrager of these tokens if she wants. Here are simple steps she may want to take: One can make a profit by buying tokens with buyPrice and then sell them with the market selling price if the latter is greater than the former; One can make a profit by buying tokens with the market buying price and then sell them with the sellPrice if the latter is greater than the former; As it is impossible to guarantee that the buy / sell prices are identical to their counterparts (i.e., the market prices) all the time, one can always find an opportunity to make (inappropriate) arbitrage. As a result, the circulation of the tokens would not be maintained anymore. Moreover, as both buyPrice and sellPrice are modifiable by the owner, the owner becomes the one to directly control the market price! As of this writing, we have discovered 8 tradable tokens that suffer from the issue: | Name (Symbol) | Address | Market Cap (USD) | Exchanges | | ------------ | ------------ | ------------ | ------------ | |Substratum (SUB) |0x12480e24eb5bec1a9d4369cab6a80cad3c0a377a |152,704,344 |Binance, OKEx, ZB, OKCoinKR, Kucoin, HitBTC, Bitbns, COSS, IDEX, EtherDelta, ForkDelta, Tidex, Radar Relay, Yobit, WazirX, CoinExchange, CoinSpot | |Internet Node Token (INT)|0x0b76544f6c413a555f309bf76260d1e02377c02a|31,154,850|OKEx, CoinEgg, YEX, Allcoin, EtherDelta, ForkDelta| |SwftCoin (SWFTC)|0x0bb217e40f8a5cb79adf04e1aab60e5abd0dfc1e|35,954,769|OKEx, OEX, Huobi.pro, HitBTC, OTCBTC, EtherDelta, ForkDelta, Bluetrade, CoinBene, CEX| |Target Coin (TGT)|0xac3da587eac229c9896d919abc235ca4fd7f72c1|5,862,720|HitBTC, CoinExchange, IDEX, EtherDelta, ForkDelta| | Gold Reward (GRX)| 0x219218f117dc9348b358b8471c55a073e5e0da0b| Unknown| EthereDelta, ForkDelta, CoinExchange, Livecoin, IDEX | |SEC (SEC)|0xc6689eb9a6d724b8d7b1d923ffd65b7005da1b62|Unknown|CoinEgg| |ClassyCoin (ClassyCoin)|0x30cc0e266cf33b8eac6a99cbd98e39b890cfd69b|Unknown|EtherDelta, ForkDelta | |FaceCoin (FC)|0xe6923e9b56db1eed1c9f430ea761da7565e260fe|Unknown|EtherDelta, ForkDelta| We point out that a case of similar nature has been reported [2] in the context of a crypto game. However, our analysis shows that the issue is much more severe than we thought. Some of the listed tokens, such as SUB, are tradable on top exchanges with large amounts of market cap and impact. As they are vulnerable to the inappropriate arbitrage mentioned before, the trading of normal customers turns out to be a high risk activity. ### Additional Overflows Finally, during our investigation, we also come across integer overflow vulnerabilities in those smart contracts, which can be further classified in the following two categories: 1. BuyTrap: Traders may buy tokens but get nothing because of an integer overflow triggered by manipulating the buying price; 2. SellTrap: Traders may sell tokens but receive no payment because of an integer overflow triggered by manipulating the selling price; Each case, if being exploited, would lead to financial loss to trading customers. We show in Figure 3 the vulnerable buy() function. Notice that the amount is a determined by a multiplication operation in line 393. Because the SafeMath multiplication is not used here, the simple math operation would not revert when an overflow caused by the multiplication of msg.value and buyPrice.  Figure 3: The buyTrap category of affected smart contracts In Figure 4, we show the vulnerable sell() function that has a similar logic, The transfer balance is determined by the multiplication of amount and sellPrice, which may lead to an overflow because of the simple math operation used in line 222.  Figure 4: The sellTrap category of affected smart contracts The buyPrice and sellPrice, as you might recall, can be manipulated by the owner in the setPrices() function, as shown in Figure 2. A benign owner may not attempt to manipulate these sensitive prices for profit. However, the existence of these manipulating interfaces (mixed with above vulnerabilities) makes the motivation behind the vulnerable code questionable! ### Conclusion Due to the fact of a relatively large number of affected tokens (including tradable ones in top exchanges), we are still in the process of notifying affected development teams and relevant cryptocurrency exchanges. It is encouraging to notice that some of them (e.g., Binance and Substratum/SUB) have immediately taken preventative actions to protect trading customers or token holders. In the meantime, we strongly encourage affected development teams and cryptocurrency exchanges to contract us and we are willing to offer any necessary help! Together, we can make the blockchain ecosystem better! ### 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 (including the need for smart contract auditing), please contact us at telegram, twitter, or email. |
| id | SSV:97409 |
| last seen | 2018-07-09 |
| modified | 2018-07-09 |
| published | 2018-07-09 |
| reporter | Knownsec |
| title | Full Disclosure of Highly-Manipulatable, tradeTrap-Affected ERC20 Tokens in Multiple Top Exchanges(CVE-2018-11446) |