Hyperinflation Vulnerability - Reading Assignment

  1. How was the bug discovered?
    It was discovered after Peckshield was alerted of a large transfer of ERC20 token. This led them to look into the contract code.

  2. What is this vulnerability called?
    It’s called Batch overflow.

  3. Which function is vulnerable?
    BatchTransfer

  4. Why was the vulnerability present in several ERC20 tokens?
    Several ERC20 contracts implemented the same vulnerable function in their own code.

  5. Why is “code is law” mentality problematic when it comes to fixing bugs?
    Because once the bug is known, project team is unable to stop the contract or fix the problem and other people can take advantage of the bug.

  6. How did exchanges react to this vulnerability?
    By suspending trading on affected token.

1. How was the bug discovered?
By an alert generated by an automated system to scan and analyze Ethereum-based (ERC-20) token transfers which was developed by PeckShield.

2. What is this vulnerability called?
This particular vulnerability is called batchOverflow.

3. Which function is vulnerable?
The vulnerable function is batchTransfer.

4. Why was the vulnerability present in several ERC20 tokens?
As ERC20 is a token standard, it usually gets copied and used to meke different tokens and if in the first example there is a vulnerability, it will travel across other tokens that used the same code.

5. Why is “code is law” mentality problematic when it comes to fixing bugs?
Because the code is stored in blockchain which is immutable and cannot be changed by design. This leads to the problem of changing the code in order to fix a bug.

6. How did exchanges react to this vulnerability?
OKEx made an announcement to suspend the withdrawal and trading of BeautyChain, a batchOverflow-affected token, other exchanges reacted slower.

1 Like
  1. A huge amount of BEC tokens was transferred, raisin an alarm.
  2. batchOverflow
  3. batchTransfer
  4. Probably the same functions get reused, so the vulnerabilities are also copied there.
  5. smart contracts are immutable, they are not supposed to be changed, and fixing would require a change.
  6. OKEx responded with suspension of trading, but other exchanges were too slow to react.
2 Likes
How was the bug discovered?

A). peckshield INC. built an automated EARLY WARNING SYSTEM BASED ON THEIR PREVIOUS EXPERIENCE(S). The system will will automatically send out alerts if any suspicious transactions (e.g., involving unreasonably large tokens) occur.
What is this vulnerability called?
A). BATCHOVERFLOW
Which function is vulnerable?
A). BATCHTRANSFER
Why was the vulnerability present in several ERC20 tokens?
A). In my humble Opinion, it was probably a cut and paste job from a sample contract on GITHUB. And the COWBOYdeveloper of the contract thought it was a good idea to borrow some ready made contract to save money and make some quick $$$'s :cowboy_hat_face:
Why is “code is law” mentality problematic when it comes to fixing bugs?
A). After contract has been deployed/excuted. There is no way to update such. It must be killed and a new bug free contract issued/deployed, which is not ideal but it is safe and keeps the spirit of immutable and tamper proof smart contracts alive.
How did exchanges react to this vulnerability?
A). irratically and un coordinated. A bit like BORIS AND Donalds handling of the current COVID-19 Situation. CHAOTIC IN MY OPINION. :stuck_out_tongue_winking_eye:

1. How was the bug discovered?
A whale tracker flagged transactions with a large quantity of tokens being moved
2. What is this vulnerability called?
Batch Overflow
3. Which function is vulnerable?
batchTransfer
4. Why was the vulnerability present in several ERC20 tokens?
because batchTransfer was used in other ERC20 tokens as well. All that used the function were also vulnerable to the attack
5. Why is “code is law” mentality problematic when it comes to fixing bugs?
problematic because the view that code once implemented should not be changed, does not allow for implementing solutions to bugs that are found in the future.
6. How did exchanges react to this vulnerability?
Centralized Exchanges were contacted and disabled withdrawals and trading. It is hard to get all to act quickly with an equivalent response, and no real solution to stopping the hacker from dumping on a DEX.

  1. By the transaction of an unusual large amount of BEC tokens. Peckshield picked up on this transaction and started a research into the smart contract and found a bug
  2. Batch overflow bug
  3. function batchTransfer
  4. Because the developers were unaware that batchOverflow is essentially a classic integer overflow issue
  5. Because blockchain code is immutable making bug fixes on previous deployed smart contract codes impossible
  6. Suspending and freezing the transaction and withdrawals of the BEC token
  1. the PeckShield noticed a unusually large transaction
  2. batchOverflow
  3. batchTransfer()
  4. they used the same transfer method
  5. harder to report problems to the people who may actually be able to fix things
  6. suspending withdrawing and trading
  1. The bug was discovered by a blockchain security company’s automated system, while it was scanning and analysing smart contract transactions involving transfers of ERC20 tokens, in order to detect transfers of suspiciously large amounts of tokens. An alert was triggered when the system detected a transaction involving two identical transfers of an extremely large amount of BEC tokens from the BeautyChain smart contract to two separate addresses.

  2. This vulnerability is called batchOverflow.

  3. The vulnerable function is  batchTransfer() , a type of transfer function where the same amount of tokens is transferred more than once from one address (the msg.sender) to different recipient addresses:

    function batchTransfer(
        address[] _recipients, uint256 _value
    ) public returns(bool success) {...}
  1. The vulnerability was present in several ERC20 tokens, because this particular implementation of the transfer function was fairly common, and also because it is common practice amongst developers of new ERC20 tokens to recycle code that has already been used in the smart contracts of other ERC20 tokens.

  2. When it comes to fixing bugs, the “code is law” mentality is problematic, because it isn’t accompanied by a healthy presumption that vulnerabilities are likely to exist and will require carefully coordinated action in order to find effective solutions and fixes. This leads to an environment where teams of developers don’t have the necessary procedures in place to enable a rapid and effective response whenever vulnerabilities or bugs are detected. Therefore, the risk is that action will be delayed, responses will be knee-jerk, and there will ultimately be more negative consequences than may otherwise have been the case.

  3. One exchange reacted by suspending the withdrawal of and trading in BeautyChain (BEC) tokens. Generally speaking, however, the response from exchanges was uncoordinated, and they didn’t react quickly or effectively enough to reduce the very real risk of money laundering and cryptocurrency price manipulation, which could potentially be caused by attackers exploiting the batchOverflow vulnerability and selling excessive numbers of affected tokens.

1. How was the bug discovered?
By an automated system to scan and analyze Ethereum-based (ERC-20) token transfers.
2. What is this vulnerability called?
batchOverflow
*3. Which function is vulnerable?
*batchTransfer()
4. Why was the vulnerability present in several ERC20 tokens?
I suspect that people tend to copy and paste smart contract without checking carefully,
5. Why is “code is law” mentality problematic when it comes to fixing bugs?
Because there is no traditional well-known security response mechanism in place to remedy these vulnerable contracts.
6. How did exchanges react to this vulnerability?
By suspending the withdrawal and trading.

  1. An automated system designed to scan the EOS ecosystem for unusually large coin transfers
  2. The BatchOverflow Bug
  3. The function batchTransfer is vulnerable (or any similar function with the same functionality)
  4. The functionality is quite common and exploits a previously unknown security flaw so it’s reasonable more than a few contracts were vulnerable.
  5. “Code is Law” states all executions and transactions on the blockchain are final and immutable, but a third party software team needs to be able to censor and update code in order to fix security features.
  6. OKEx suspended all trading of BeautyChain coin, but not all exchanges behaved this way, so vulnerabilities were present still at the time of the articles writing.
  1. How was the bug discovered?
    An scanner sent out an alert due to a suspicious transaction
  2. What is this vulnerability called?
    batchOverflow
  3. Which function is vulnerable?
    batchTransfer()
  4. Why was the vulnerability present in several ERC20 tokens?
    ERC20 it’s a contract standard for token creation and many time users copy others implementation
  5. Why is “code is law” mentality problematic when it comes to fixing bugs?
    There is no traditional well-known security response mechanism in place to remedy these vulnerable contracts.
  6. How did exchanges react to this vulnerability?
    Suspending the withdrawal and trading of the token

Read the Medium article by PeckShield describing the vulnerability and the exploit. https://medium.com/@peckshield/alert-new-batchoverflow-bug-in-multiple-erc20-smart-contracts-cve-2018-10299-511067db6536

Answer the questions below (try your best!) :

  1. How was the bug discovered?
    On 4/22/2018, 03:28:52 a.m. UTC, our system (PeckShield) raised an alarm which is related to an unusual BEC token transaction. In this particular transaction, someone transferred an extremely large amount of BEC token — 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000

  2. What is this vulnerability called?
    batchOverflow

  3. Which function is vulnerable?
    batchTransfer

  4. Why was the vulnerability present in several ERC20 tokens?
    Cause they use the same base code for ERC20 tokens (standard)

  5. Why is “code is law” mentality problematic when it comes to fixing bugs?
    Because when the code is deployed if you don’t have put in place some mechanism to change your code, the code is immutable and unstoppable.

  6. How did exchanges react to this vulnerability?
    Suspending the trading

1. How was the bug discovered?
Bug was discovered by alarm that was triggered by suspicious transaction
2. What is this vulnerability called?
batchOverflow
3. Which function is vulnerable?
batchTransfer
4. Why was the vulnerability present in several ERC20 tokens?
Because all of them used same flavour for creating it
5. Why is “code is law” mentality problematic when it comes to fixing bugs?
Because it’s not easy to fix those bugs in traditional well known way.
6. How did exchanges react to this vulnerability?
Some of them stopped trading.

1. How was the bug discovered?
the guys at peckshield Inc had deployed an automated system to detect any ERC-20 suspicious transactions
2. What is this vulnerability called?
batchOverflow
3. Which function is vulnerable?
batchTransfer()
4. Why was the vulnerability present in several ERC20 tokens?
I don’t know really, I guess that it’s because all the ERC20 tokens have the same principle or standard, so they must share some common functions, or are built in similar ways
5. Why is “code is law” mentality problematic when it comes to fixing bugs?
Because by “code is law” I understand that laws cannot be broken, thus you normally would not want to change the code (thus breaking the law) even if it is to fix some big issue or bug, like the one in the example.
6. How did exchanges react to this vulnerability?
OKEx made an announcement to suspend the withdrawal and trading of BeautyChain ( BEC ), a batchOverflow-affected token. However, other exchanges also need to be coordinated and there still exist other tradable tokens vulnerable to batchOverflow! The presence of non-centralized exchanges with offline trading services might pose additional challenges as they cannot even stop attackers from laundering their tokens. Thus DeFi is also a risk when these kind of smart contracts exist.

This made me think… can I intentionally introduce new ERC20 token with this vulnerability build inside and then transfer to myself insane amounts of my new token and then exchange it using uniswap for ETH or BTC???

Answers to questions, for the reading assignment.

  1. How was the bug discovered?
    PeckShield Inc, had built an automated system to scan and analyze Ethereum-based (ERC-20) token transfers.

  2. What is this vulnerability called?
    BatchOverflow

  3. Which function is vulnerable?
    batchTransfer

  4. Why was the vulnerability present in several ERC20 tokens?
    They all used the same base code library.

  5. Why is “code is law” mentality problematic when it comes to fixing bugs?
    There is no traditional well-known security response mechanism in place to remedy vulnerable contracts.

  6. How did exchanges react to this vulnerability?
    They suspended the withdrawal and trading of affected tokens.

1 Like
  1. How was the bug discovered?
    PeckShield automated system that scans and analyses ERC-20 transfers raised an alarm.
  2. What is this vulnerability called?
    batchOverflow
  3. Which function is vulnerable?
    batchTransfer()
  4. Why was the vulnerability present in several ERC20 tokens?
    Many tokens used the same vulnerable code as a base template
  5. Why is “code is law” mentality problematic when it comes to fixing bugs?
    There was no precedence for this type of issue and therefore no process in place to remedy the situation.
  6. How did exchanges react to this vulnerability?
    Exchanged suspend the withdrawal and trading of the effected tokens
2 Likes
  1. How was the bug discovered?

by an automated tool that analyzes the blockchain for suspicious transaction

  1. What is this vulnerability called?

batchOverflow

  1. Which function is vulnerable?

batchTransfer

  1. Why was the vulnerability present in several ERC20 tokens?

other contracts were vulnerable to the batchOverflow issue

  1. Why is “code is law” mentality problematic when it comes to fixing bugs?

there was no established security response in these situations

  1. How did exchanges react to this vulnerability?

they halted trading & withdrawals

1 Like

1. How was the bug discovered?

By PeckShield company with a help of their suspicious transactions analyser.

2. What is this vulnerability called?

batchOverflow.

3. Which function is vulnerable?

batchTransfer .

4. Why was the vulnerability present in several ERC20 tokens?

Because those particular tokens inherited their code from a vulnerable contract.

5. Why is “code is law” mentality problematic when it comes to fixing bugs?

It goes against the decentralised nature of smart contracts.

6. How did exchanges react to this vulnerability?

Some suspended deposits and withdraws for BEC.

1 Like

1. How was the bug discovered?
Using an automated tool that analyze Ethereum-based (ERC-20) token transfers, that alerts if a unusual behavior is detected.

2. What is this vulnerability called?
batchOverflow

3. Which function is vulnerable?
batchTransfer()

4. Why was the vulnerability present in several ERC20 tokens?
Most tokens reuse the code as standard

5. Why is “code is law” mentality problematic when it comes to fixing bugs?
Once a code is deployed in network is consider as immutable. Since in some cases bugs are not take in consideration during development stage,therefore no safe mechanism are created which might lead to unpredictable problems.

6. How did exchanges react to this vulnerability?
They suspend withdraws and trades

  1. The blockchain security firm PeckShield did routine monitoring for unusually large transactions and found one with BEC on 4/22/2018.

  2. This type of vulnerability is called batchOverflow.

  3. The batchTransfer() functions was affected.

  4. Because of code duplication.

  5. Code deployed on the blockchain is considered immutable. There is no traditional well-known security response mechanism in place to remedy vulnerable contracts.

  6. Centralized exchanges gradually suspended trades of pairs that included BEC, but DEXes are not managed by anyone and therefore continued to be a venue for the hackers to launder the captured tokens.