Vulnerabilities > CVE-2018-11239 - Integer Overflow or Wraparound vulnerability in Hexagontoken Hexagon
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
NONE Integrity impact
HIGH Availability impact
NONE Summary
An integer overflow in the _transfer function of a smart contract implementation for Hexagon (HXG), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized increase of digital assets by providing a _to argument in conjunction with a large _value argument, as exploited in the wild in May 2018, aka the "burnOverflow" 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 | 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]). Some of them could be used by attackers to generate tokens out of nowhere while others can be used to steal tokens from legitimate holders. Today, we would like to report another vulnerability called burnOverflow that affects a few ERC20-related tokens. In particular, one such token, i.e., Hexagon Token (HXG), has already been attacked in the wild. Specifically, on 5/18/2018, 12:55:06 p.m. UTC, PeckShield detected such attacking transaction (as shown in Figure 1) where someone calls transfer() with a huge amount of HXG token — 0xffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,ffff,fffe to another address without actually spending any HXG token.  Figure 1: An Abnormal HXG Token Transfer (with Huge Amount) From our investigation, we show in Figure 2 the implementation logic of the standard ERC-20 transfer() function in the HXG smart contract. It simply calls _transfer() (in line 26) to perform the actual task.  Figure 2: ERC-20 Standard transfer() Implementation In the _transfer() function, we can see that in line 81, the calculation of _value + burnPerTransaction could be overflowed for bypassing the check of sender’s balance.  Figure 3: A burnOverflow-affected Smart Contract Since burnPerTransaction is set as 2, the attacker can make _value + burnPerTransaction = 0 by making _value = 0xffff,ffff,ffff,….,fffe. As the balance of _to is less than 2, the check in line 85 could be passed. Then, the balance of _from is decremented by 0 (_value + burnPerTransaction) in line 85. Finally, the tremendous amount of HXG token is added to balanceOf[_to] in line 87. Since HXG token is currently listed in [token.store](https://token.store/trade/HXG) for trading, we contact the development team at the first place to prevent any possible financial loss. As warned in our vulnerability reports, all the calculations without utilizing SafeMath can easily introduce vulnerabilities in smart contracts and cause undesirable damage or loss. |
| id | SSV:97321 |
| last seen | 2018-06-26 |
| modified | 2018-05-31 |
| published | 2018-05-31 |
| reporter | My Seebug |
| title | New burnOverflow Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-11239) |