Review of the Multichain Vulnerability Incident and Summary of the White Hat Rescue Operation

On January 18, 2022, the abnormal trading monitoring system detected an attack targeting the Multichain project. Due to the improper implementation of the verification mechanism in the anySwapOutUnderlyingWithPermit() function, the tokens authorized by users to the project could be withdrawn by the attacker.

Despite the project team trying various methods to alert affected users, many users still failed to respond in a timely manner, allowing the attackers to continue their attacks and profit.

To protect potential victims, the BlockSec team has decided to take emergency response measures. This rescue operation targets affected accounts on Ethereum, transferring the relevant account funds to a specially established multi-signature white hat account. To ensure transparency of the operation, the document hash of the related plan has been made public to the community. The rescue operation started on January 21, 2022, and ended on March 11, 2022.

Emergency rescue faces many technical and non-technical challenges. This article reviews the entire process, shares relevant insights and experiences, and hopes to contribute to the security of the DeFi ecosystem.

Brief Summary

• There has been intense competition over the use of Flashbots between the two groups of white hats and attackers, and even within each group, the fees paid have also rapidly increased.

• Flashbots are not always effective. Some attackers resort to using the mempool and successfully carry out attacks through clever strategies.

• Some attackers reached an agreement with the project party to return part of the proceeds and keep part as a reward, successfully "whitening" their actions. This phenomenon has sparked controversy in the community regarding the fairness of incentives.

• White hats can publicly declare their actions to the community without disclosing sensitive information, gaining the trust of the community.

• The collaboration of various community forces can make rescue operations faster and more effective.

Overview of Attack and Rescue Situations

Overall Result

The overall situation within the observation range from January 18, 2022 to March 20, 2022, is as follows: (.

• 9 rescue accounts protected 483.027693 ETH, paid Flashbots fees of 295.970554 ETH) accounting for 61.27%(
• 21 attack accounts profit 1433.092224 ETH, paid Flashbots fees 148.903707 ETH) accounting for 10.39%(

![])https://img-cdn.gateio.im/webp-social/moments-30d2c3346816e15ab7c89a6a25d0ad83.webp(

) Flashbots fee change trend

The initial attack transaction Flashbots fee was 0, indicating that the attacker had not yet used Flashbots. Subsequently, the fee percentage rose rapidly, reaching as high as 80%-91% at certain block heights, reflecting intense competition for on-chain rights.

![]###https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp(

Implementation of Rescue Operations and Challenges Faced

) The basic idea of the rescue operation

1. Monitor potential victim accounts
2. When discovering WETH being transferred in, exploit the contract vulnerability to transfer it out to the white hat multi-signature wallet.

Key Requirements:

• Effectively identifying the transaction that transferred funds to the victim.
• Correctly construct rescue transactions
• Successfully front-run the attacker's transaction

The main challenge lies in the front-running attacks on transactions. Although Flashbots can be used, it is necessary to consider the fee setting strategy. At the same time, due to competition, Flashbots are not always the best choice.

Competition Situation

Attempt to protect 171 potential victim accounts, including:

• 10 Self-Protection Tips
• 14 successful rescues
• 147 rescue failures

The reason for the failure involves competition between 3 rescue accounts and 16 attack accounts.

![]###https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp(

Lessons Learned

) Flashbots fee settings

The conservative strategy has not been effective, and competitors often adopt more aggressive strategies:

• An attacker set the ratio to 70%-86%
• A certain white hat set the ratio to 79%-81%

This seems to be a zero-sum game that requires finding a balance between reducing costs and winning competition.

![]###https://img-cdn.gateio.im/webp-social/moments-cb547989448abc96498684cb89da8860.webp(

) Mempool transaction sorting strategy

Due to intense competition, Flashbots are not always effective. Sending normal transactions through the mempool and arranging them in the right place may also achieve the goal.

An attacker successfully profited 312 ETH using this strategy without paying Flashbots fees. The key is to arrange the attack transaction after the transfer transaction and as close as possible.

![]###https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp(

Other Thoughts

) Distinction between White Hats and Attackers

It is not always easy to distinguish. An account was initially marked as an attacker, later negotiated with the project party to return part of the profits, and retained 50 ETH as a reward, eventually being reclassified as a white hat. This phenomenon has sparked controversy over the fairness of incentives.

Competition in the White Hat Community

It is necessary to establish a coordination mechanism to reduce/avoid competition among white hats, to prevent resource waste and cost increases.

Suggestions for Improving Rescue Operations

• The white hat publicly announces actions to the community without disclosing sensitive information.
• Flashbots/miners provide a green channel for trusted white hats.
• The project party bears the Flashbots fees.
• The project party adopts a more convenient user alert mechanism.
• The project team has taken necessary emergency measures in the code.

![]###https://img-cdn.gateio.im/webp-social/moments-f6e97c80d0049ad9d2cc45cbbaf91c5a.webp(