Explaining how to exploit batchOverflow in smart contracts ERC20
According to a group of cybersecurity researchers a new discovery has been made in relation to a new vulnerability in the tokens of Ethereum. This perceived vulnerability relates to certain tokens based on the ERC-20 standard.
The vulnerability, referred to as batchOverFlow, is described by the PeckShield startup on Medium in the following article: New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018-10299) published on April 22.
The team have discovered an unusual transaction in the BeautyChain token (BEC), where a user was preparing to transfer a substantial quantity of tokens. Analysing the smart contract of the token based on the ERC-20 standard, the author of the article verifies that the transfer comes from an “in-the-wild” attack that exploits a previously unknown bug in the contract.
Performing fuzz testing among repositories of smart contracts, we have found that this function is found in other contracts also, example; UPCToken (UPCT) which has already used measures to prevent this vulnerability from being exploited by blocking this function (explained below).
What does the attack do?
This vulnerability, as shown in the image above, is to cause an overflow in the local variable amount, type uint256, confusing the contract between the number of tokens in possession, and between those transferred, allowing more tokens to be sent than are in possession.
How does it work?
- The attacker enters a quantity in _value(the amount to be sent to each user) that multiplied by the number of _receivers will be 2^256
- When calculating the variable amount, multiply _value by _receivers, as the result is one more unit than the maximum value representable by a data uint256 (2^256 – 1), an overflow occurs that converts the value of the variable amount to 0.
- The conditions of require are met, in particular, you have to look at balances[msg.sender] >= amount, since 0 is the condition, and the transaction can be carried out without having any token.
- The transaction is executed and the _valuequantity is sent to each _receiver.
Ideas to avoid this challenge
We have seen that these challenge can greatly affect the price and confidence in the token, but how can we avoid it? Are there any proposals for solution?
The answer is yes, the creators of this vulnerability themselves, have given some thought of how to protect against it, but the solution does not appear to be exhaustive.
Normally, to avoid overflows, we use a libraries originally developed by OpenZeppeling, called safeMath, which consists of functions created to perform operations “- + * /” by checking overflow, here we see how the creator uses .sub and .add in instead of “-” and “+” respectively, the failure was to perform “*” instead of .mul.
Another defense is to be able to pause the functioning of the smart contract by means of a modifier, this option is very unpopular because it gives a lot of power to the owner of the token, taking a little decentralization of it. This system was also implemented as we see here.
Currently there are several initiatives to offer Bug Bounty programs in smart contracts such as Solidified that allow rewarding found vulnerabilities.
It is important to highlight the importance of performing technical code analysis in smart contracts. From Grant Thornton we have a multidisciplinary team working in the Blockchain laboratory which is carrying out technical analysis and studying smart contracts as well as new potential vulnerabilities to detect them and report them on time.
Testing the exploit on a Testnet
It should be noted that all the mentioned contracts are paused and therefore cannot be exploited, if we want to test the exploit, we have uploaded contracts vulnerable to Ropsten: 0x0b3b8e8e48018fA9f29b15146ca20B3dFB2f04FC and Rinkeby 0xF8fB4dAeA58D2aE779DEb550B7D3E374fCe7B283 the BatchOverflow token.
Two days after reporting this vulnerability, the same cybersecurity group reported another bug called proxyOverflow with the same technique. The article “Integer Overflow (ie, proxyOverflow Bug) Found in Multiple ERC20 Smart Contracts (CVE-2018-10376)” describes the details of how through two input parameters in the proxyTransfer method an overflow could be caused to 0 with the input parameters.
The BatchOverFlow vulnerability had already been raised and discussed in July 2016 in an ethereum.stackexchange thread to help understand the maximum possible value of unsigned integers uint256. Functions such as .mul, or .sub allow for safer operations. It is always advisable to perform technical analysis of the code of a smart contract to review all possible points of failure.
Recently, several crypto exchanges had to freeze deposits and movements temporarily because of the risk this could cause users with large amounts of tokens, where the market could be manipulated. Some re-enabled deposits hours later.
We will post further about the subject as we continue our research on this topic, please visit the website to view updates.