Detailed explanation of the FundWin vulnerability system: Can the project party be suspicious of “doing evil”?

Recently, a fund project called “FairWin” was particularly eye-catching. As a result, the consumption of Ethereum network Gas continued to be highly saturated, and the utilization of Gas in a single DApp reached the Ethereum network. Nearly half of the total.

However, due to the exposure of smart contract security vulnerabilities, FairWin was pushed to the forefront, and for a time attracted the public's concerns about the fate of FairWin games and the stability of the overall Ethereum network.

Overview

On September 27, 2019, Beijing time, PeckShield security personnel found that the FairWin smart contract had some fatal flaws caused by management rights problems. The balance in the old contract can be arbitrarily operated and transferred by the user. There is a new problem with the upgraded new contract, allowing users to create fake bets to capture the remaining funds in the prize pool.

The origin of the FairWin contract problem

According to the latest monitoring data of PAppShield's DApp data service platform DAppTotal.com, since August 26, the daily consumption of the Ethereum network has been highly saturated, that is, the daily consumption of Gas accounts for the Ethereum network to carry Gas. More than 90% of the total, the overall network conditions are abnormally congested.

The reason for the continued congestion is that a fund project called FairWin has recently appeared, and its daily consumption of Gas accounts for nearly half of the total Ethereum network load (as shown below).

PeckShield security personnel found out that FairWin deployed a contract starting with 0x11f5 on June 17, analyzing its contract source code discovery, and the following call exists:

It is not difficult to find that the sendFeeToAdmin() method can be called by any user. Once called, the balance in the FairWin contract will be transferred to the specified admin address. The issue was discovered by ConsenSys security researcher Daniel Luca, who then fixed the new contract with 0x01ea on July 27th.

As shown in the figure below, by analyzing the code of the new contract, the sendFeeToAdmin() method has been set to private:

In this case, the above method can not be directly called from outside, the above problem is also solved, but PeckShield security personnel in-depth analysis found that the problem is not so simple: due to the irreversible characteristics of the blockchain, DApp upgraded from the old contract to the new contract, However, the user's previous bet record is still stored in the old contract, and the project side needs to find a way to migrate the user's bet record to the new contract.

To solve this problem, the FairWin team introduced the remedy() interface to import the user's assets directly into the new contract:

Analysis of the principle of new contract vulnerability

By analyzing the remedy() interface, the general process for implementing digital asset migration is as follows:

  • Ensure that remedy() is currently open;
  • The user's bet data is restored according to the parameters and saved to the database of the new contract.

By analyzing the data on the Ethereum chain, PeckShield security personnel found that remedy() was called 503 times after the new contract was launched, and a total of 500 investors completed the asset migration, and the calling method was initiated by the FairWin administrator.

However, whether this method can be called successfully depends on whether the actStu parameter is 0 or not. PeckShield security personnel analyzed FairWin's new contract code and found a new problem:

  • actStu defaults to 0, which means the remedy() method can be called;
  • The closeAct() method sets actStu to 1, which turns off the remedy() channel.

The key to the problem is this:

The closeAct() method adds the onlyOwner limit, while remedy() does not impose this restriction.

Due to the inconsistency of the above restrictions, if the contract Owner does not close actStu through closeAct(), any user can modify the bet data through the remedy() interface, thereby realizing a large amount of capital investment and passing through the 0 input. userWithDraw() takes the contract balance bonus out.

Fortunately, as of now, there are no known attacks, and the FairWin contract owner has closed actStu and the potential threats have been temporarily removed.

Vulnerability of the vulnerability

FairWin still maintains a large heat in the short term, and it also generates replicas such as EtherHonor and HyperFair. It does not rule out the possibility of such problems.

In addition, after the FairWin contract was exposed to security issues, there was a public opinion questioning that this might be “the front door reserved by the project side and the white wolf from the hollow glove”, but PeckShield security personnel found that by tracking the interaction between the old and new contracts, In addition to the project party's betting funds issue to the new contract, the project party also gave the original return for the wrong bet:

As follows, a call occurred on August 01:

  • The account (user) starting with 0xa584 bet 11ETH on the FairWin old contract in block height of 8263419.
  • The amount of the bet is transferred to the FairWin 0x854d administrator account by 0xcb10 at the block height of 8264604.
  • Then, when the block height is 8264613, the administrator account will transfer the 11ETH back to the 0xa584 account (user).
From the initial point of view of the chain behavior, the project side can open the suspicion of "doing evil." In response to the above vulnerability threats, PeckShield security personnel recommend that for sensitive operations of smart contracts, the corresponding access restrictions should be added. For the above remedy() operations, the onlyOwner restriction is required to avoid malicious use by others. In addition, the user's digital assets should be fully awe-inspiring. For developers, at the same time, it also exposes a problem. In the process of contract upgrade, it is likely to have various "new" problems. The project party should respond to the problem in the first time and seek third-party security. The company helped it conduct potential vulnerability investigations before going online.

For the user, even this does not mean that you can “sit back and relax” after participating in FairWin. After all, the fund is ultimately the fund, and when you are staring at the abyss, the abyss is staring at you.

(FairWin contract address balance changes, source: etherscan.io)

PeckShield security personnel analyzed the ETH's address balance curve (above) and found that the FairWin contract's balance has dropped significantly after being exposed to the vulnerability. It shows that the vulnerability has brought a certain trust crisis to the project side, and a large number of users. Start withdrawing funds. Taking into account the funding mechanism, the short-term balance continues to decline, may bury a "thunder" seed, PeckShield here to remind users should be cautiously involved in such fund disk projects, to avoid irreparable due to its potential instability Loss.