#1: Colhendo Bots MEV Explorando Vulnerabilidades no Flashbots Relay

Em abril de 2023, um atacante explorou a vulnerabilidade existente no relay do Flashbots para atacar múltiplos bots de MEV e lucrou cerca de 20 milhões de dólares. A causa raiz desse ataque é que uma transação privada poderia vazar para o pool público sob certas condições, e o atacante poderia fazer backrun da transação vazada para obter lucros. Também observamos algumas técnicas sofisticadas usadas no ataque, como o uso de transações honeypot para atacar as vítimas e um mecanismo de autoproteção no contrato de ataque.

Contexto

Flashbots

O Flashbots, conforme mostrado em seu site, é "uma organização de pesquisa e desenvolvimento formada para mitigar as externalidades negativas impostas pelo Valor Máximo Extraível (MEV) a blockchains com estado, começando pelo Ethereum." Há algumas entidades diferentes envolvidas no Flashbots, incluindo searchers, builders e relays. A imagem a seguir mostra o relacionamento entre eles.

A imagem é do documento do Flashbots

O protocolo PBS (separação proposer-builder) é um protocolo que permite ao propositor de bloco vender seu espaço de bloco (quando selecionado para construir um bloco) para múltiplos builders — para maximizar os lucros. Especificamente, múltiplos searchers monitoram transações dentro do mempool e geram bundles, que serão enviados aos builders. O builder agrega bundles dos searchers, cria o bloco mais valioso e o submete ao relay. O relay submete o bloco ao propositor de bloco, o validador que foi selecionado para construir um bloco para um slot de época.

Nessa arquitetura, o relay é uma parte confiável tanto pelos builders quanto pelos propositores, que não confiam um no outro. Ele garante que o propositor não possa obter o conteúdo do bloco antes de assinar o cabeçalho do bloco. Também garante que o valor das taxas seja pago ao propositor.

Indico aos leitores interessados na arquitetura detalhada o documento do Flashbots. Precisamos apenas lembrar a garantia de segurança que deve ser fornecida pelo relay, ou seja, o relay não pode revelar o conteúdo do bloco ao propositor se o bloco NÃO estiver na chain. Caso contrário, o propositor malicioso pode usar o conteúdo do bloco vazado para obter lucros (conforme demonstrado no ataque).

Ataque Sanduíche

Um ataque sanduíche ocorre quando um atacante insere uma swap entre duas transações para obter lucro. Gostaria de usar um exemplo para ilustrá-lo.

Suponha que temos um pool DEX com dois tokens, WETH e USDC. Um usuário envia uma solicitação de swap para trocar WETH por USDC. Essa transação de swap estará no mempool e será obtida pelo bot de MEV (vamos chamá-lo de searcher). Em seguida, o bot criará duas transações, uma antes e outra depois da transação de swap do usuário.

Especificamente, a primeira transação do bot é usar WETH para comprar USDC, o que aumentará o preço do USDC. Em seguida, a transação de swap do usuário será executada (com menos USDC, pois o preço do USDC está mais alto devido à primeira transação). Depois disso, a segunda transação do bot trocará USDC por WETH, obtendo mais WETH do que na primeira swap do bot.

A imagem é do artigo de Liyi Zhou et al. High-Frequency Trading on Decentralized On-Chain Exchanges.

Backrunning

Backrunning é uma estratégia para executar uma transação imediatamente após uma grande negociação. O backrunning basicamente aproveita oportunidades de arbitragem devido ao impacto no preço do token causado por uma negociação de grande valor. Por exemplo, se um usuário faz uma grande negociação em um pool DEX para trocar WETH por USDC, isso pode fazer com que o preço do USDC fique mais alto do que em outras exchanges. Um bot de backrunning pode capturar imediatamente essa oportunidade de arbitragem para trocar USDC por WETH a um preço mais baixo, recebendo mais WETH, e então vender WETH nos pools DEX de outras exchanges para obter lucros.

A Vulnerabilidade

Conforme mostrado na análise post-mortem, a vulnerabilidade existia no código do relay. Ela revelaria o conteúdo do bloco do builder a um propositor (malicioso) mesmo que o cabeçalho do bloco assinado fosse inválido (a assinatura em si é válida). Nesse caso, o cabeçalho de bloco inválido e o conteúdo do bloco enviados à beacon chain serão rejeitados, e o propositor pode ganhar a corrida para enviar seu próprio bloco e aproveitar o conteúdo do bloco vazado para obter lucros.

O Processo do Ataque

O atacante é o propositor malicioso, e as vítimas são os bots de MEV que pretendem realizar transações sanduíche.

Vamos usar uma transação de ataque real como exemplo.

Bloco 16964664
Posição 0	Transação da vítima: 0xd2edf726fd3a7f179c \| Phalcon Explorer (blocksec.com)	O bot de MEV usou 2454,1 WETH para comprar 4,5 STG
Posição 1	Transação de ataque: 0x4b2a2d03b3dc136ef9 \| Phalcon Explorer (blocksec.com)	O atacante usou 158 STG para comprar 2454,1 WETH

As transações da vítima e do ataque estão nas posições 0 e 1 no bloco 16964664, respectivamente. Basicamente, a vítima (bot de MEV) realizou uma grande negociação, usando 2454,1 WETH para comprar 4,5 STG no pool WETH-STG da Uniswap. Isso cria uma grande oportunidade de arbitragem, e o atacante usou 158 STG para drenar todo o WETH do pool.

A questão é: por que a vítima (o bot de MEV) estaria disposta a usar 2.454 WETH (valendo cerca de 5 milhões de dólares) para comprar 4,5 tokens STG (valendo cerca de 3 dólares) no pool? Note que quando a vítima realizou esse swap, a liquidez no pool era muito baixa (0,005 WETH e 4,5 STG).

Nossa análise mostra que há dois motivos que levam o bot de MEV a realizar esse swap absurdo.

Primeiro, o atacante usou uma transação honeypot para atrair a vítima a enviar esse swap e realizar o ataque sanduíche. O hash dessa transação honeypot é 0xd534c46ba5a444e886 | Phalcon Explorer (blocksec.com). Especificamente, o atacante transmitiu uma transação para trocar WETH por STG (antes do bloco 16964664). Como a liquidez no pool é muito baixa, isso cria uma oportunidade para o bot de MEV realizar um ataque sanduíche. Conforme mostrado na figura a seguir, o bot de MEV poderia criar um bundle de ataque sanduíche contendo três transações (bundle de ataque sanduíche).

Segundo, o bot de MEV usou uma estratégia sanduíche gulosa e utilizou o Flashbots para enviar essa transação. Para maximizar o lucro, a primeira transação dentro do bundle tenta drenar quase todos os tokens STG (com 2.454 WETH). Essa é uma estratégia muito gananciosa, usando 5 milhões de dólares (2.454 WETH) para obter um lucro de cerca de 700 dólares (0,35 WETH) — 7.000:1. O bot assumiu que esse swap NÃO seria revelado ao público a menos que fosse confirmado na chain. No entanto, essa suposição foi invalidada devido à vulnerabilidade do relay. Aproveitando isso, o atacante criou um novo bundle incorporando a transação inicial de ataque sanduíche do bot e adicionou uma transação de backrunning para adquirir 2.454 WETH.

A figura no Twitter da BlockSec mostra todo o processo do ataque.

O Mecanismo de Autoproteção

Sabemos que o atacante enviou uma transação honeypot para atrair a vítima, trocando WETH por STG. No entanto, o que acontece se não houver transações sanduíche disponíveis para explorar a transação honeypot? Nesses casos, o atacante monitorou o status do pool e executou um swap reverso para proteger seus 0,35 Ether — uma jogada inteligente. Abaixo está o código decompilado do contrato inteligente (0xe73f1576af5573714404a2e3181f7336d3d978f9) que executou a transação honeypot.

Para verificar nossa descoberta, simulamos a transação honeypot no Phalcon Fork, mas na posição 0 do bloco 16964664.

Resumo

Este é o primeiro ataque que explorou a vulnerabilidade no relay do Flashbots com estratégias de ataque sofisticadas.

Primeiro, este ataque explorou uma vulnerabilidade zero-day no relay do Flashbots.
Segundo, ele explorou a estratégia sanduíche gulosa e usou transações honeypot para atrair o bot de MEV (a vítima).
Terceiro, incluiu um mecanismo de autoproteção para economizar o custo (0,35 WETH) da transação honeypot caso o ataque não tivesse sucesso.