The way we think about a secure exchange of funds and information has been altered by blockchain technology.

This article focuses on the newly identified ERC20 batchOverflow vulnerability, the mistakes made during development that led to the creation of susceptible ERC20 token development, and the steps you should take to prevent making the same mistakes again.

ERC20 token vulnerability

An occurrence that was subsequently identified as the batchOverflow exploit occurred in April 2018. Vulnerable ERC20 contracts of ERC coins like BeautyChain (BEC) and MeshBox (MESH) were used in the exploit to create an unreasonable amount of tokens out of thin air.

Shortly following the discovery of the batchOverflow issue, PeckShield, a security firm, discovered many vulnerabilities in various Ethereum coins. Among the coins on the impacted list are:

• Aurora Dao (AURA)

• BeautyChain (BEC)

• UG Token (UGT)

• Smart Billions (SMART)

• FirstCoin (FRST)

• GG Token (GG)

• CNY Token (CNY)

• CNYTokenPlus (CNYt+)

• UselessEthereumToken (UET)

• Hexagon (HXG)

• Education (EDU)

• Smart Mesh (SMT)

• MTC

• SCA

These flaws were found not long after the batchOverflow attack was used. Researchers looked into questionable transactions left by attackers to locate them.

The primary indicator of questionable transactions was an abnormally high transfer rate, which occasionally exceeded the total supply of a token. Several significant exchanges have fully stopped accepting deposits and withdrawals of ERC20 tokens to stop speculation. These conversations were:

• OKEx

• Poloniex

• Changelly

• Huobi Pro

Two main problems with ERC20 tokens

Researchers found multiple attacks and gave each one a distinct name while searching for vulnerabilities in ERC20 tokens. Though, there are just two primary issues with all of these tokens:

• Overflow vulnerabilities

• Unprotected functions

Let’s take a closer look at each of these problems.

Overflow vulnerabilities

Exploiting integer overflow or underflow, a flaw in the ERC20 token standard, is the foundation of overflow vulnerabilities. When the outcome of a mathematical operation falls outside the range that a variable may represent, this issue arises.

When subtracting anything from zero in the context of Ethereum smart contracts, the result is a very big value. The outcome of adding two huge values will be close to zero and will wrap around.

In this instance, line 206 has the susceptible code. This line’s addition is not properly checked for overflow. Large values for value and feeSmart can be set to cause their sum to overflow, resulting in a value that is lower than the balance of the account and passing the condition, adding absurdly large values to the balance of the set accounts.

Unprotected function vulnerability

Unprotected functions are the second category of ERC20 token security issues. This type of ERC20 vulnerability only appears when a developer neglects to include the necessary modifier that limits function access. This means that certain essential core features may be freely called by any arbitrary user.

For instance, it’s standard procedure when creating Ethereum smart contracts to restrict access to particular features to a single account. Usually, that account is referred to as the owner.

And the AURA token experienced precisely this. The function that sets the owner isn’t restricted by an ownerOnly modification, even though the functions inside the contract are. Consequently, anybody can use the setOwner function to select a random owner by calling the contract. Fortunately, at this point the owner account can do nothing more than a regular user, so this issue is left safely unpatched.

How to avoid writing vulnerable code

As you can see, these ERC20 functionality vulnerabilities are typically the result of unintentional code errors. Additionally, there are still susceptible contracts on the Ethereum network even though these errors are well recognised and simple to prevent.

Is there any way to keep from adding to the pile? Can you, when working with create ERC20 token, avoid writing vulnerable code? Of course, you can, and of course it is doable. We provide the following advice to assist you in guaranteeing a high degree of code safety:

1. To prevent anything from being left exposed, clearly indicate visibility in functions and state variables.

2. Use libraries like OpenZeppelin’s SafeMath to stop overflows and underflows.

3. Watch out while dividing integers by rounding. Because of the constant rounding down, 5/2 equals 2, not 2.5.

4. To reduce gas usage and prevent denial of service assaults, allow users to pull tokens (in bonuses, games, airdrops, and so forth) as opposed to pushing them.

Utilize the most recent Solidity constructs: * Make appropriate use of require and assert so that an automated analyzer can officially verify your code.

• Use keccak256 in place of sha3 and self-destruct in place of suicide.

• Create a test contract using Ropsten, a public testnet. Establish a bug bounty program and allow your contracts to be tested by the community.

• Obtain an official audit of your contract’s security.

You may increase the security of your code and avoid writing susceptible code by following these simple steps.

Conclusion

The recent batchOverflow hack demonstrated how a single coding error might result in a significant security issue. Although ERC-20 tokens are susceptible to overflows, developers only need to double-check their code and take extra precautions to avoid both overflows and underflows.