Multichain was attacked, and a white hat operation saved 483 ETH.

On January 18, 2022, the abnormal trading monitoring system detected an attack against the AnySwap project (Multichain). Due to the related functions failing to correctly implement the verification mechanism, the tokens authorized by users for this project could be withdrawn.

Despite the project team's attempts to remind affected users through various methods, many users still failed to respond in a timely manner, allowing the attackers to continue their attacks and profit.

Due to the ongoing attacks, the BlockSec team has decided to take emergency response measures to protect potential victims. This rescue operation targets the affected accounts on Ethereum, and we will transfer the relevant account funds to a specially established multi-signature white hat account. To ensure the transparency of the operation, we will explain the relevant plans in a document and immediately make the document hash public to the community. The rescue operation began on January 21, 2022, and ended on March 11, 2022.

Emergency rescue is not easy, as there are various technical and non-technical challenges to overcome. After the operation, we review the entire process and share our insights with the community. We hope that such sharing will be helpful to the community and the security of the DeFi ecosystem.

Brief Summary:

• Different participants have generated intense competition for the widespread use of Flashbots, and the fees have also rapidly increased over time.

• Flashbots are not always effective. Some attackers switch to mempool and successfully carry out attacks.

• Some attackers reached an agreement with the project team to return part of the stolen funds, keeping some as a reward, thus being able to launder their gains. This phenomenon has sparked controversy in the community.

• White hats can publicly announce their actions to the community without disclosing sensitive information, and this practice is commendable.

• The various forces in the community can work together to make rescue efforts faster and more effective. For example, cooperation among white hats can reduce ineffective competition.

The following will be elaborated from four aspects: first, a general review of the event; then, an introduction to the methods of implementing the rescue and the challenges faced; next, a discussion of the insights and experiences during the action; and finally, some thoughts and suggestions.

Overview of Attack and Rescue Situations

Overall result

During the observation period from January 18 to March 20, 2022, the overall attack and rescue situation is as follows: 9 rescue accounts protected 483.027693 ETH, with Flashbots fees of 295.970554 ETH accounting for 61.27%; 21 attack accounts profited 1433.092224 ETH, with Flashbots fees of 148.903707 ETH accounting for 10.39%.

Flashbots Fee Change Trends

White hats need to compete with attackers to send Flashbots transactions for rescue, and the fee changes reflect the intensity of the competition. Initially, some attack transactions had Flashbots fees of 0, indicating that attackers had not yet used Flashbots. Subsequently, the fee ratio quickly rose, reaching 91% in a certain block. This indicates that it has become an arms race in fees due to the on-chain power struggle of Flashbots.

The implemented rescue operations and the challenges faced.

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

R1: Effective tracking of transactions transferred to the victim R2: Properly Constructing Rescue Transactions R3: Successful front-running attacker transaction

R1 and R2 do not pose an obstacle for us. R3 remains a challenge; although it is theoretically possible to win the front-running with Flashbots, it is not easy in practice. We also use the mempool to send regular transactions, where the position and order of the transactions are key factors.

The competition we are involved in

Overall, we attempted to protect 171 potential victim accounts. Among them, 10 were self-protected, and we only successfully rescued 14 out of the remaining 161. The failures involved 3 rescue accounts and 16 attack accounts.

Lessons learned

How to determine Flashbots fees?

We adopt a more conservative strategy for setting fees, but the results are not very successful. Attackers and some white hats usually adopt aggressive strategies, with the fee ratio quickly rising from 70% to 86%. This seems to be a zero-sum game that requires a trade-off between lowering costs and finding the optimal strategy.

How to correctly arrange transaction positions in the mempool?

Flashbots are not always effective. Sending regular transactions through the mempool and positioning them appropriately can also achieve the goal. An attacker successfully profited 312 ETH using this strategy without paying Flashbots fees.

Some other thoughts

How to distinguish between white hats and attackers?

Identifying white hats is not always straightforward. One example is when a certain address marked as an attacker becomes a white hat because the attacker agrees to retain a portion of the profits as a reward and return the rest. This phenomenon has sparked controversy in the community regarding the fairness of incentives.

Competition among white hats

It is necessary for the community to establish a communication and coordination mechanism to reduce/avoid competition among white hats. This competition not only wastes rescue resources but also increases rescue costs.

How to better carry out rescue operations?

White hats can publicly announce their actions to the community without disclosing sensitive information, and this practice performs well. The collaborative efforts of all parties in the community can make rescue operations faster and more effective, such as Flashbots/miners providing a green channel for trusted white hats, and project parties bearing the costs.