On January 18, 2022, our abnormal transaction monitoring system detected an attack on the AnySwap project (ie Multichain). Since the anySwapOutUnderlyingWithPermit() function fails to implement the relevant verification mechanism correctly, the token authorized by the user to the project can be taken out by the attacker. For details about the vulnerability and related disposal details, please refer to the official statement of the project party (https://medium. com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8).
Although the project party tried various methods to remind the affected users (such as sending transaction reminders, as shown in Figure 1), many users still failed to respond in time (withdrawing their authorization), and the attackers were able to continue to carry out attacks and make profits .
As the attack continued, the BlockSec team decided to implement emergency response measures in order to protect potential victims. This rescue is especially aimed at the affected account on Ethereum. The project contract address associated with it is 0x6b7a87899490EcE95443e979cA9485CBE7E71522. We will transfer the relevant account funds to our specially established multi-signature white hat account (0xd186540FbCc460f6a3A9e705DC6d240 6cBcc1C47).
In order to ensure the transparency of the action, we explained the relevant action plan in a pdf file, and immediately released the file hash (not the content) to the community. This ensures that our actions can be differentiated from the attackers' actions without revealing any details (since the attack is still ongoing).
Our rescue operation officially started on January 21, 2022, and will officially end on March 11, 2022. The relevant public statements are shown in Figure 2 and Figure 3 respectively.
Emergency rescue is not an easy task and there are various technical and non-technical challenges to overcome. Since the operation has ended, we were able to review the entire process and share relevant experiences and experiences with the community. We hope and believe that such sharing will be helpful to the community and the security of the DeFi ecosystem.
Brief summary (too long to read the version)
Participants from different camps have fiercely competed for the widespread use of Flashbots, including both groups of white hats and attackers, and even within their respective groups, and the fees paid to Flashbots have also increased rapidly over time.
Flashbots are not a panacea and don't always work. Some attackers turned to mempool, arranged attack transactions through clever strategies, and successfully carried out the attack.
Some attackers reached an agreement with the project party to return part of the attack proceeds and retain part of the attack proceeds as a reward, which was successfully laundered. This phenomenon is not the first time, and the fairness of its incentives has also caused great controversy and discussion within the community.
From the perspective of transparency, white hats can publicly announce their actions to the community without revealing sensitive information. This way of gaining the trust of the community works well in practice.
All parties in the community can work together to make relief operations more rapid and effective. For example, coordination among white hats can be carried out to reduce or avoid invalid competition.
first level title
secondary title
0x1.1 overall result
Within our observation range (from block height 14028474 on January 18, 2022 to block height 14421215 on March 20, 2022), the overall attack and rescue situation is shown in Table 1, according to the Ethereum involved in the attack or rescue Account address statistics (for the convenience of display, only the first 4 digits of the address are displayed). Specifically, an account address is either a rescue account or an attack account, and the type is determined based on the Etherscan.io tags and the funds transfer address. In addition, during the attack and rescue process, both the white hats and the attackers used Flashbots to send transactions in large quantities, so they need to pay additional fees to the miners, which we call Flashbots fees.
secondary title
0x1.2 Trend of Flashbots fees
As mentioned above, white hats need to compete with attackers to send Flashbots transactions to implement rescue, and the changing trend of fees paid to Flashbots can reflect the intensity of competition. In order to make a quantitative evaluation, we counted the proportion of Flashbots fees for attack and rescue transactions according to transaction blocks.
first level title
secondary title
0x2.1 How do we conduct rescue operations?
The basic idea of rescue is simple and straightforward. Specifically, we need to monitor a batch of potential victim accounts that have authorized WETH to be used by problematic project party contracts. When there is any WETH transfer into this account, we use the contract loophole to transfer it directly to our white hat multi-signature wallet. The key here is to meet the following three requirements:
R1: Effectively locate the transactions transferred to the victim's account. For the convenience of description, we will name these transactions as transferred transactions (transferred TXs) below.
R2: Correctly construct transactions to implement rescue. For the convenience of description, we will name these transactions as rescue transactions (rescue TXs) below.
R3: Successfully preempting the attacker's (or other third-party) transactions. For the convenience of description, we will name these transactions as attack transactions (attack TXs) below.
R1 and R2 are not a hindrance to us. Because we have built an internal system to monitor the mempool, we can locate transfer transactions in a timely manner; at the same time, we have also developed a set of tools to automatically construct rescue transactions.
secondary title
0x2.2 The competition we are involved in
Overall, we attempted to protect 171 unique potential victim accounts. Among them, 10 were self-protected by revoking authorization in time, and among the remaining 161 accounts, due to the existence of various competitions mentioned above, we only successfully rescued 14 accounts. We summarize the failures in the table below, involving 3 rescue accounts and 16 attack accounts.
first level title
secondary title
0x3.1 How to determine the Flashbots fee?
Throughout the rescue process, we were successively defeated by 12 competitors who also exploited Flashbots, including 2 rescue accounts and 10 attack accounts.
Our strategy for setting Flashbots fees is relatively conservative. Specifically, we always prefer to set Flashbots fees as low as possible in order to protect the interests of victims. Therefore, unless there have been successful attacks using Flashbots, we will not actively use Flashbots or increase Flashbots fees. For example, a successful attack transaction sets the Flashbots fee rate at 10%, and we may set it to 11% in the next rescue transaction. However, such tactics have not proven to be very successful, and attackers (even some white hats) often resort to more aggressive tactics to set fees to win the competition, such as:
Figure 5 shows an attack transaction at block height 14071986, and the attacker 0x5738** set the ratio to 70%.
Figure 6 shows an attack transaction at block height 14072255, and the white hat 0x14ca** set the proportion to 79%.
Figure 7 shows an attack transaction at block height 14072385, and the white hat 0x14ca** sets the ratio to 80%.
Figure 8 shows an attack transaction at block height 14072417, and the white hat 0x9117** sets the proportion to 81%.
Figure 9 shows an attack transaction at block height 14073395, and the attacker 0x5738** set the ratio to 86%.
first level title
0x3.2 How to correctly arrange transaction positions in mempool?
It currently appears that the success of the rescue depends on an arms race in the cost of Flashbots. However, we did find that Flashbots were not always effective due to the presence of intense competition from multiple parties, from other transaction senders unrelated to the attack/rescue, such as arbitrage, etc. In this case, even the highest (compared to other attack and rescue transactions) Flashbots fee set by an attack exchange is not guaranteed to win the Flashbots competition.
Another possible approach is to use sending normal transactions through the mempool, it is also possible to achieve the goal if the transaction is arranged in the right place. The appropriate location here means that the attack/rescue transaction is located after the transfer transaction and very close to the transfer transaction (the closer the better, ideally if it happens to be in the next position of the transfer transaction). In fact, the attacker 0x48e9** used this strategy to successfully harvest 312.014657 ETH without paying any Flashbots fees. The following four graphs show the attacker's two most profitable attacks:
Figure 10 and Figure 11 respectively show that at block height 14051020, the victim 0x3acb**’s transfer transaction (transfer 50 ETH) is located at 65, while the attack transaction (profit 50 ETH) is located at 66.
Figure 12 and Figure 13 respectively show that at block height 14052155, the victim 0xbea9**’s transfer transaction (transfer 200 ETH) is located at 161, while the attack transaction (profit 200 ETH) is located at 164.
first level title
secondary title
0x4.1 How to distinguish between white hats and attackers?
Identifying white hats and their actions may not be as straightforward as one might think. For example, the account address 0xfa27 was flagged by Etherscan.io as a white hat: Multichain Exploiter 4 (Whitehat). However in the beginning, this address was flagged as an attacker: Multichain Exploiter 4. The change here comes from the interaction between the project party and the attacker. After several rounds of negotiations, the attacker agreed to keep the 50 ETH profit as a reward and return other profits (deducting Flashbots fees, etc.):
In the transaction 0x3c3d**, the project party contacted the attacker:
In transaction 0xd360**, the attacker replies:
In the transaction 0x354f**, the project party expressed its gratitude after receiving the returned funds:
secondary title
0x4.2 Competition between white hats
secondary title
0x4.3 How to better carry out rescue operations?
On the one hand, from the perspective of transparency, white hats can publicly announce their actions to the community without revealing sensitive information. This way of gaining the trust of the community works well in practice. Compared to a blocking mission for a particular attack, such a rescue operation is usually a tug-of-war, with white hats and attackers engaging multiple times over a period of time, so there will be plenty of time Make an announcement. Of course, at the beginning of the operation, the details of the vulnerability do not need to be disclosed, so as not to cause unnecessary harm (but the file hash that records the action intention can be shared with the community, just like what we did in this rescue) ; After the operation is over, this information should be fully disclosed to the community.
On the other hand, all forces in the community can work together to make rescue operations more rapid and effective, including but not limited to:
Flashbots/Miners provide a green channel to authenticated and credible white hats, which can be used to rush attack transactions and avoid competition among white hats.
The attacked project party is responsible for the cost of Flashbots fees.
The project party adopts a more convenient and faster mechanism to warn users in a timely manner.
The project party adopts some necessary emergency measures in the code.
