Shulou(Shulou.com)05/31 Report--

In this issue, Xiaobian will bring you a review and analysis of how to carry out EDU and BAI arbitrary transfer account Token events. The article is rich in content and analyzes and narrates from a professional perspective. After reading this article, I hope you can gain something.

event background

On the evening of May 23, 2018, EDU (EduCoin) was exposed to contract vulnerabilities and billions of tokens were stolen. EduCoin is a decentralized education platform for online education content sharing and services based on blockchain and smart contract technology, while EDU is a project token issued based on the Ethereum ERC-20 protocol, totaling 15 billion.

Before the contract vulnerability was exposed, EDU's trading K line had already seen a lot of selling. Starting at midnight on May 20, 2018, a large number of EDUs were sold, and the continued sell-off brought further panic to the market. The price of EDU continued to fall until the trading pair of EDU was forced to close, during which more than 2 billion EDUs were sold.

The reason why hackers are very easy to steal tokens is precisely because EDU's smart contract has a very large security vulnerability.

Vulnerability Overview

For EDU&BAI smart contract problems, BUGX team did some simple analysis, for reference only:

In transferFrom function,`allowed[_from][msg.sender] >= _value` is not checked and `allowed[_from][msg.sender] -= _value` is not used in function; SafeMath is not used, resulting in failure to throw exception and rollback transaction. There has been a lot of looting, attackers do not need a private key to transfer all the EDUs in your account, and because the contract does not have a Pause design, it cannot stop losses.

This vulnerability is currently found in EDU and BAI contracts.

Contract Transfer Status:

EDU:

< https://etherscan.io/token/0xa0872ee815b8dd0f6937386fd77134720d953581>

BAI：

< https://etherscan.io/token/0x14d9779b6585f3a7d4f768383b3cb030705dad2e>

vulnerability theory

The vulnerability code in the contract is as follows:

//Maximum approved transfer (maximum approved target can transfer on my behalf) function approve(address _spender, uint256 _value) public returns (bool success) { allowed[msg.sender][_spender] = _value; Approval(msg.sender, _spender, _value); return true; } //Transfer process on my behalf function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) { /// same as above require(_to != 0x0); //detects non-empty address of transfer object require(balances[_from] >= _value); //detects that the balance of the transferred person is greater than_value require(balances[_to] + _value > balances[_to]); uint previousBalances = balances[_from] + balances[_to]; balances[_from] -= _value; balances[_to] += _value; //Reduce the allowable transfer amount from the transferee to the initiator of this transaction, but do not do abnormal detection, resulting in error and continue to execute allowed[_from][msg.sender] -= _value; Transfer(_from, _to, _value); assert(balances[_from] + balances[_to] == previousBalances); return true; }

It can be seen that this process does not make allowed[ _from][msg.sender] and_value judgments, for example, the function should start by judging:

require(allowed[ _from][msg.sender] >= _value);

If allowed[ _from][msg.sender] does not exist, then the value is 0, and the judgment is missing, which means that the previous approve function is useless. And then there's an interesting spillover:

allowed[ _from][msg.sender] -= _value;

When allowed[ _from][msg.sender] does not exist, then the value is 0, and subtracting_value (greater than 0) overflows (overflow does not cause an interrupt rollback). This is why it works fine if SafeMath is used, because SafeMath throws an error and interrupts the rollback transferFrom function.

Looking at it as a whole, the core problem of the transferFrom coin theft event of EDU and BAI contracts is the permission problem, and the overflow is just a small episode.

local recurrence

It can be easily reproduced using Remix.

1 Deployment contract

EDU：

< https://etherscan.io/address/0xa0872ee815b8dd0f6937386fd77134720d953581#code>

BAI：

< https://etherscan.io/address/0x14d9779b6585f3a7d4f768383b3cb030705dad2e#code>

2 Execution of attacks

Transferred to (just use the contract creator's address): 0xca35b7d915458ef540ade6068dfe2f44e8fa733c

Attacker: 0x14723 a09acff6d2a60dcdf7aa4aff308fddc160c

transferFrom input content and execute: "0xca35b7d915458ef540ade6068dfe2f44e8fa733c","0x14723 a09acff6d2a60dcdf7aa4aff308fddc160c","3"

You can see that the attacker balance has increased to 3.

The above is how to carry out EDU and BAI arbitrary transfer account Token event review analysis shared by Xiaobian for everyone. If there are similar doubts, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.