#1: Harvesting MEV Bots by Exploiting Vulnerabilities in Flashbots Relay

In April 2023, an attacker leveraged the vulnerability existing in Flashbots relay to attack multiple MEV bots and profited around 20M USD. The root cause of this attack is that a private transaction could be leaked into the public pool under certain conditions, and the attacker could backrun the leaked transaction to get profits. We also noticed a couple of sophisticated techniques used in the attack, e.g., using honeypot transactions to attack the victims and a self-protection mechanism in the attack contract.

Background

Flashbots

Flashbots, as shown on its website, is “a research and development organization formed to mitigate the negative externalities posed by Maximal Extractable Value (MEV) to stateful blockchains, starting with Ethereum.” There are a couple of different entities involved in Flashbots, including searchers, builders, and relays. The following image shows their relationship.

The picture is from Flashbots document

PBS (proposer-builder separation) protocol is one protocol that allows the block proposer to sell their block space (as they are selected to build a block) to multiple builders – to maximize profits. Specifically, multiple searchers listen to transactions inside the mempool and generate bundles, which will be submitted to builders. The builder aggregates bundles from searchers, creates the most valuable block, and then submits it to the relay. The relay will submit the block to the block proposer, the validator who has been selected to build a block for an epoch slot.

In this architecture, the relay is a trusted party by both builders and proposers, who do not trust each other. It ensures that the proposer cannot get block content before signing the block header. It also ensures that the amount of fees is paid to the proposer.

I refer readers who are interested in the detailed architecture to the Flashbots document. We only need to remember the security guarantee that needs to be provided by the relay, i.e., the relay cannot reveal the block content to the proposer if the block is NOT on the chain. Otherwise, the malicious proposer can use the leaked block content to make profits (as shown in the attack).

Sandwich Attack

A sandwich attack is when an attacker puts a swap between two transactions to make a profit. I would like to use an example to illustrate it.

Suppose we have a DEX pool with two tokens, WETH and USDC. One user submits a swap request to swap WETH for USDC. This swap transaction will be in the mempool and obtained by the MEV bot (let’s say a searcher). Then the bot will make two transactions, one before and one after the user’s swap transaction.

Specifically, the bot's first transaction is to use WETH to swap USDC, which will increase the price of USDC. Then, the user’s swap transaction will be executed (with less USDC since USDC’s price is higher due to the first transaction). After that, the bot’s second transaction will swap USDC for WETH, which can get more WETH than in the bot’s first swap.

The picture is from Liyi Zhou et al.’s paper High-Frequency Trading on Decentralized On-Chain Exchanges.

Backrunning

Backrunning is a strategy to execute a transaction immediately after a large trade. Backrunning basically takes advantage of arbitrage opportunities due to the impact on the token price of the large-value trade. For instance, if a user makes a large trade in a DEX pool to swap WETH for USDC, this can make the USDC’s price higher than other exchanges. A backrunning bot can immediately capture this arbitrage opportunity to swap USDC for WETH at a lower price to receive more WETH and then sell WETH in other exchanges’ DEX pools for profits.

The Vulnerability

As shown in the post-mortem analysis, the vulnerability existed in the relay’s code. It will reveal the builder’s block content to a (malicious) proposer even if the signed block header is invalid (the signature itself is valid). In this case, the invalid block header and block content submitted to the beacon chain will be rejected, and the proposer can win the race to submit its own block and leverage the leaked block content to make profits.

The Attack Process

The attacker is the malicious proposer, and the victims are the MEV bots who intend to perform the sandwich transactions.

Let’s use a real attack transaction as an example.

Block 16964664
Position 0	Victim transaction: 0xd2edf726fd3a7f179c \| Phalcon Explorer (blocksec.com)	MEV bot used 2454.1 WETH to swap 4.5 STG
Position 1	Attack transaction: 0x4b2a2d03b3dc136ef9 \| Phalcon Explorer (blocksec.com)	The attacker used 158 STG to swap 2454.1 WETH

The victim and attack transactions are in position 0 and 1 in block 16964664, respectively. Basically, the victim (MEV bot) performed a large trade, using 2454.1 WETH to swap 4.5 STG in the uniswap WETH-STG pool. This creates a large arbitrage opportunity, and the attacker used 158 STG to drain all the WETH in the pool.

The question is, why was the victim (the MEV bot) willing to use 2,454 WETH (worth around 5M USD) to swap 4.5 STG tokens (worth around 3 USD) in the pool? Note that when the victim performed this swap, the liquidity in the pool was really low (0.005 WETH and 4.5 STG).

Our analysis shows there are two reasons that make the MEV bot perform such a ridiculous swap.

First, the attacker used a honeypot transaction to lure the victim to send this swap to perform the sandwich attack. The hash of this honeypot transaction is 0xd534c46ba5a444e886 | Phalcon Explorer (blocksec.com). Specifically, the attacker broadcasted a transaction to swap WETH for STG (before block 16964664). Since the liquidity in the pool is really low, this creates an opportunity for the MEV bot to make a sandwich attack. As shown in the following picture, the MEV bot could create a sandwich attack bundle that contains three transactions (Sandwich attack bundle).

Second, the MEV bot used a greedy sandwich strategy and leveraged Flashbots to send this transaction. To maximize profit, the first transaction inside the bundle tries to drain nearly all the STG tokens (with 2,454 WETH). This is a really greedy strategy, using 5M USD (2,454 WETH) to gain a profit of around 700 USD (0.35 WETH) – 7,000:1. The bot made an assumption that this swap will NOT be revealed to the public unless it’s committed on the chain. However, this assumption has been broken due to the vulnerability of the relay. Taking advantage of this, the attacker created a new bundle incorporating the bot's initial sandwich attack transaction and added a backrunning transaction to acquire 2,454 WETH.

The figure in BlockSec’s Twitter shows the whole attack process.

The Self-Protection Mechanism

We know that the attacker sent a honeypot transaction to lure the victim by swapping WETH for STG. However, what happens if there are no sandwich transactions available to exploit the honeypot transaction? In such cases, the attacker monitored the status of the pool and executed a reverse swap to protect its 0.35 Ether, a smart move. Below is the decompiled code of the smart contract (0xe73f1576af5573714404a2e3181f7336d3d978f9) that executed the honeypot transaction.

To verify our finding, we simulated the honeypot transaction in Phalcon Fork, but in position 0 of block 16964664.

Summary

This is the first attack that leveraged the vulnerability in the Flashbots relay with sophisticated attack strategies.

First, this attack exploited a zero-day vulnerability in the Flashbots relay.
Second, it exploited the greedy sandwich strategy and used honeypot transactions to lure the MEV bot (the victim).
Third, it included a self-protection mechanism to save the cost (0.35 WETH) of the honeypot transaction in case the attack did not succeed.