Review and Reflection on the Project Vulnerability Rescue Action

On January 18, 2022, our abnormal trading monitoring system detected an attack on a certain cross-chain project. Due to a function in the project's contract that did not properly implement a verification mechanism, the tokens authorized by users to the project could be extracted by attackers.

Despite the project's attempts to remind affected users in various ways, many users failed to respond in a timely manner, allowing attackers to continue their attacks and profit. In light of the ongoing attacks, and to protect potential victims, we have decided to take emergency response measures. This rescue operation targets the affected accounts on Ethereum, and we will transfer the funds of the relevant accounts to a specially established multi-signature white hat account. To ensure the transparency of the action, we will make the document hashes of the relevant plans public to the community, which distinguishes our actions from those of the attackers without disclosing details. The rescue operation started on January 21, 2022, and ended on March 11.

Emergency rescue faces many technical and non-technical challenges. After the operation, we reviewed the entire process and hope to share relevant experiences to assist the community and the DeFi ecosystem's safety.

Overview of Rescue Situation

During the time frame we observed from January 18 to March 20, 2022, the overall attack and rescue situation is as follows:

• 9 rescue accounts protected 483.027693 ETH, paid Flashbots fees of 295.970554 ETH( accounted for 61.27%)

• 21 attacking accounts profited 1433.092224 ETH, paid Flashbots fees 148.903707 ETH( accounted for 10.39%)

It is worth noting that due to some complex situations, such as certain attackers later reaching agreements with the project party to return part of their profits, the above statistics are only rough estimates.

Trend of Flashbots Fee Changes

White hats compete with attackers to send Flashbots transactions for rescue, and the Flashbots fees paid reflect the intensity of the competition. We calculated the proportion of Flashbots fees for attack and rescue transactions based on transaction blocks.

In the early stages of the attack, the Flashbots fee for the transactions was 0, indicating that the attacker had not yet used Flashbots. Subsequently, the proportion of Flashbots fees rose rapidly, reaching as high as 80%-91% in certain blocks. This reflects the arms race in fees caused by the power struggle over on-chain rights with Flashbots.

Implementation and Challenges of Rescue Operations

The basic idea of the rescue is to monitor potential victim accounts. When WETH is transferred in, use the contract vulnerability to transfer it out to the white hat multi-signature wallet. The key is to meet the following requirements:

1. Effectively locate the transaction that transferred funds to the victim.
2. Correctly construct rescue transactions
3. Successful front-running attacker transaction

The first two items do not pose a barrier for us, but the third remains challenging. Although Flashbots can be used for front-running, the success rate depends on the level of fees due to the fee bidding model, and strategy settings require additional consideration. Additionally, the position and order of transactions when sending regular transactions in the mempool are also key factors. We are also competing with other "white hats," some of whose actions are rather suspicious.

Overall, we attempted to protect 171 potential victim accounts. Among them, 10 promptly revoked authorization for self-protection, and among the remaining 161, due to various competitions, we only successfully rescued 14.

Lessons Learned

( Flashbots fee settings

Our fee strategy is relatively conservative, tending to set lower fees to protect the interests of victims. However, this strategy has not been very successful, as attackers and some white hats often adopt more aggressive strategies. For example:

• An attacker set the fee ratio to 70%
• A certain white hat set the fee ratio at 79%-81%.
• Another attacker raised the fee ratio to 86%

This seems to become a zero-sum game, requiring modeling to explore the behavior patterns of all parties, seeking a balance between reducing costs and winning competition.

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

) Mempool transaction sorting

Due to intense competition among multiple parties, Flashbots is not always effective. Sending regular transactions through the mempool can also achieve the goal if placed in the right position. An attacker used this strategy to successfully profit 312 ETH without having to pay Flashbots fees.

The attack transactions are cleverly arranged in adjacent positions to the victim's transfer transactions. This strategy is both practical and enlightening, warranting attention.

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

Other Thoughts

) Definition of White Hats and Attackers

Identifying white hats is not always straightforward. For example, a certain address was initially marked as an attacker but later changed to a white hat. This stems from negotiations between the project party and the attacker, where the attacker agreed to keep a portion of the profits as a reward and return the rest. This phenomenon has sparked discussions in the community about the fairness of incentives.

White Hat Competition

It is necessary for the community to establish a coordination mechanism to reduce competition among white hats. This competition can waste rescue resources and increase rescue costs. For example, we, along with three other white hat organizations, attempted to protect 54 victims simultaneously, involving a loss of 450 ETH.

( Improve rescue operations

1. White hats can publicly declare their actions to the community without disclosing sensitive information, in order to gain the trust of the community.

2. All parties in the community can work together to make rescue faster and more effective:

   • Flashbots/miners provide a green channel to trusted white hats
   • The project party bears the Flashbots fees
   • The project party adopts a more convenient user alert mechanism.
   • The project party takes necessary emergency measures in the code.

By summarizing the lessons learned, we hope that future rescue operations can be more efficient and maximize the protection of user interests.

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