- How was the bug discovered?
The system was configured to send, automatically, out alerts of any suspicious transactions (e.g., involving unreasonably large tokens).
- What is this vulnerability called?
The particular vulnerability was called batchOverflow. Which is categorized as an integer overflow attack. An integer overflow attack occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of digits – either higher than the maximum or lower than the minimum representable value. An overflow/underflow condition may give results leading to unintended behavior. In particular, if the possibility has not been anticipated, overflow/underflow can compromise a program’s reliability and security.
- Which function is vulnerable?
The batchTransfer. Below we can see the code:
The vulnerable function is located in batchTransfer and the code is shown in Figure above. As indicated in line 257, the amount local variable is calculated as the product of cnt and _value .
- The variable cnt counts the number if the receivers (declared as an array of addresses)
- The variable _value accepts the amount to be transferred as a user input (declared as 256 bits integer)
- The variable _value was overflowed with zeros and got zeroed out.
- When the variable _value is zeroed out the require checks got bypassed.
The code (line 258):
require(_value >0 && balances[msg.sender] <=0);
The actual value checks became: 0>0 && balances <=0
The code (line 261):
require(balances[msg.sender] = balances[msg.sender].sub(amount));
The actual value checks became: attacker balance = attacker balance - 0 = attacker balance
Above we can see the logic of the attacker and how he by passed the checks. What is interesting how the require check behaved when validating the 0 > 0 mathematical operation.
- Why was the vulnerability present in several ERC20 tokens?
Because is not an easy and obvious code error to see. Also all ERC20 tokens have to implement certain functions in order to comply with the standard. More specifically the ERC20 standard, forces tokens to standardize set of commands to communicate with the range of tokens they manage. This includes interaction rules between different tokens, as well as token purchase rules. Put simply, the ERC20 standard defines a set of functions to be implemented by all ERC20 tokens so as to allow integration with other contracts, wallets, or marketplaces.
The subset of functions is rather short and basic, but demonstrates the type of functions, that have to be included in all ERC20 tokens:
function totalSupply() public view returns (uint256);
function balanceOf(address tokenOwner) public view returns (uint);
function allowance(address tokenOwner, address spender)
public view returns (uint);
function transfer(address to, uint tokens) public returns (bool);
function approve(address spender, uint tokens) public returns (bool);
function transferFrom(address from, address to, uint tokens) public returns (bool);
Note: Above we can see that all ERC20 tokens have to implement the transfer function. We can conclude from that the batchTransfer function was created as part of the ERC20 mentality.
- Why is “code is law” mentality problematic when it comes to fixing bugs?
The code is law principle is the principle that no one has the right to censor the execution of code on the ETC blockchain. This principle mandates that every digital asset is governed by code. The security, usefulness, availability, transferability, and general malleability of any digital asset are all determined through the code by which it is created and stored. In this way, code is law, and the rule of law controls the asset. And therefore there is no traditional well-known security response mechanism in place to remedy these vulnerable contracts. This principle is essentially the immutability of the contract.
- How did exchanges react to this vulnerability?
Due to lack of coordination between CEX’s and DEX’s no immediate response took place. This results into hacking attacks taking place for a long period of time, even when the hack does not go unnoticed.
