#1: Cosechando Bots MEV Mediante la Explotación de Vulnerabilidades en Flashbots Relay

En abril de 2023, un atacante aprovechó la vulnerabilidad existente en el relay de Flashbots para atacar múltiples bots MEV y obtuvo ganancias de alrededor de 20 millones de USD. La causa raíz de este ataque es que una transacción privada podía filtrarse al pool público bajo ciertas condiciones, y el atacante podía ejecutar una operación posterior a la transacción filtrada para obtener ganancias. También observamos un par de técnicas sofisticadas utilizadas en el ataque, por ejemplo, el uso de transacciones honeypot para atacar a las víctimas y un mecanismo de autoprotección en el contrato de ataque.

Antecedentes

Flashbots

Flashbots, como se indica en su sitio web, es "una organización de investigación y desarrollo formada para mitigar las externalidades negativas que plantea el Valor Máximo Extraíble (MEV) en las blockchains con estado, comenzando con Ethereum." Hay un par de entidades diferentes involucradas en Flashbots, incluyendo buscadores, constructores y relays. La siguiente imagen muestra su relación.

La imagen es del documento de Flashbots

El protocolo PBS (separación proponente-constructor) es un protocolo que permite al proponente de bloques vender su espacio de bloque (ya que son seleccionados para construir un bloque) a múltiples constructores, con el fin de maximizar las ganancias. Específicamente, múltiples buscadores escuchan las transacciones dentro del mempool y generan bundles, que se enviarán a los constructores. El constructor agrega bundles de los buscadores, crea el bloque más valioso y luego lo envía al relay. El relay enviará el bloque al proponente del bloque, el validador que ha sido seleccionado para construir un bloque para un slot de época.

En esta arquitectura, el relay es una parte de confianza tanto para los constructores como para los proponentes, quienes no confían entre sí. Garantiza que el proponente no pueda obtener el contenido del bloque antes de firmar el encabezado del bloque. También garantiza que la cantidad de comisiones sea pagada al proponente.

Remito a los lectores interesados en la arquitectura detallada al documento de Flashbots. Solo necesitamos recordar la garantía de seguridad que debe proporcionar el relay, es decir, el relay no puede revelar el contenido del bloque al proponente si el bloque NO está en la cadena. De lo contrario, el proponente malicioso puede usar el contenido del bloque filtrado para obtener ganancias (como se muestra en el ataque).

Ataque Sándwich

Un ataque sándwich ocurre cuando un atacante coloca un swap entre dos transacciones para obtener ganancias. Me gustaría usar un ejemplo para ilustrarlo.

Supongamos que tenemos un pool DEX con dos tokens, WETH y USDC. Un usuario envía una solicitud de swap para intercambiar WETH por USDC. Esta transacción de swap estará en el mempool y será obtenida por el bot MEV (digamos un buscador). Luego, el bot realizará dos transacciones, una antes y otra después de la transacción de swap del usuario.

Específicamente, la primera transacción del bot consiste en usar WETH para hacer swap a USDC, lo que aumentará el precio del USDC. Luego, la transacción de swap del usuario se ejecutará (con menos USDC ya que el precio del USDC es más alto debido a la primera transacción). Después de eso, la segunda transacción del bot intercambiará USDC por WETH, lo que puede obtener más WETH que en el primer swap del bot.

La imagen es del artículo de Liyi Zhou et al. High-Frequency Trading on Decentralized On-Chain Exchanges.

Backrunning

El backrunning es una estrategia para ejecutar una transacción inmediatamente después de una operación grande. El backrunning básicamente aprovecha las oportunidades de arbitraje debido al impacto en el precio del token de la operación de gran valor. Por ejemplo, si un usuario realiza una operación grande en un pool DEX para intercambiar WETH por USDC, esto puede hacer que el precio del USDC sea más alto que en otros exchanges. Un bot de backrunning puede capturar inmediatamente esta oportunidad de arbitraje para intercambiar USDC por WETH a un precio más bajo para recibir más WETH y luego vender WETH en los pools DEX de otros exchanges para obtener ganancias.

La Vulnerabilidad

Como se muestra en el análisis post-mortem, la vulnerabilidad existía en el código del relay. Revelaba el contenido del bloque del constructor a un proponente (malicioso) incluso si el encabezado del bloque firmado era inválido (la firma en sí era válida). En este caso, el encabezado de bloque inválido y el contenido del bloque enviados a la beacon chain serán rechazados, y el proponente puede ganar la carrera para enviar su propio bloque y aprovechar el contenido del bloque filtrado para obtener ganancias.

El Proceso del Ataque

El atacante es el proponente malicioso, y las víctimas son los bots MEV que intentan realizar las transacciones sándwich.

Usemos una transacción de ataque real como ejemplo.

Bloque 16964664
Posición 0	Transacción víctima: 0xd2edf726fd3a7f179c \| Phalcon Explorer (blocksec.com)	El bot MEV usó 2454.1 WETH para intercambiar 4.5 STG
Posición 1	Transacción de ataque: 0x4b2a2d03b3dc136ef9 \| Phalcon Explorer (blocksec.com)	El atacante usó 158 STG para intercambiar 2454.1 WETH

Las transacciones de la víctima y del ataque están en las posiciones 0 y 1 del bloque 16964664, respectivamente. Básicamente, la víctima (bot MEV) realizó una operación grande, usando 2454.1 WETH para intercambiar 4.5 STG en el pool WETH-STG de Uniswap. Esto crea una gran oportunidad de arbitraje, y el atacante usó 158 STG para drenar todo el WETH del pool.

La pregunta es: ¿por qué la víctima (el bot MEV) estaba dispuesta a usar 2,454 WETH (con un valor de alrededor de 5 millones de USD) para intercambiar 4.5 tokens STG (con un valor de alrededor de 3 USD) en el pool? Hay que notar que cuando la víctima realizó este swap, la liquidez en el pool era realmente baja (0.005 WETH y 4.5 STG).

Nuestro análisis muestra que hay dos razones que llevaron al bot MEV a realizar un swap tan ridículo.

Primero, el atacante usó una transacción honeypot para atraer a la víctima a enviar este swap para realizar el ataque sándwich. El hash de esta transacción honeypot es 0xd534c46ba5a444e886 | Phalcon Explorer (blocksec.com). Específicamente, el atacante difundió una transacción para intercambiar WETH por STG (antes del bloque 16964664). Dado que la liquidez en el pool es realmente baja, esto crea una oportunidad para que el bot MEV realice un ataque sándwich. Como se muestra en la siguiente imagen, el bot MEV podría crear un bundle de ataque sándwich que contenga tres transacciones (Bundle de ataque sándwich).

Segundo, el bot MEV utilizó una estrategia de sándwich codiciosa y aprovechó Flashbots para enviar esta transacción. Para maximizar las ganancias, la primera transacción dentro del bundle intenta drenar casi todos los tokens STG (con 2,454 WETH). Esta es una estrategia realmente codiciosa, usando 5 millones de USD (2,454 WETH) para obtener una ganancia de alrededor de 700 USD (0.35 WETH) – 7,000:1. El bot asumió que este swap NO sería revelado al público a menos que estuviera confirmado en la cadena. Sin embargo, esta suposición fue rota debido a la vulnerabilidad del relay. Aprovechando esto, el atacante creó un nuevo bundle que incorporaba la transacción inicial de ataque sándwich del bot y añadió una transacción de backrunning para adquirir 2,454 WETH.

La figura en el Twitter de BlockSec muestra todo el proceso del ataque.

El Mecanismo de Autoprotección

Sabemos que el atacante envió una transacción honeypot para atraer a la víctima intercambiando WETH por STG. Sin embargo, ¿qué sucede si no hay transacciones sándwich disponibles para explotar la transacción honeypot? En tales casos, el atacante monitoreó el estado del pool y ejecutó un swap inverso para proteger sus 0.35 Ether, una jugada inteligente. A continuación se muestra el código descompilado del contrato inteligente (0xe73f1576af5573714404a2e3181f7336d3d978f9) que ejecutó la transacción honeypot.

Para verificar nuestro hallazgo, simulamos la transacción honeypot en Phalcon Fork, pero en la posición 0 del bloque 16964664.

Resumen

Este es el primer ataque que aprovechó la vulnerabilidad en el relay de Flashbots con estrategias de ataque sofisticadas.

Primero, este ataque explotó una vulnerabilidad de día cero en el relay de Flashbots.
Segundo, explotó la estrategia de sándwich codiciosa y usó transacciones honeypot para atraer al bot MEV (la víctima).
Tercero, incluyó un mecanismo de autoprotección para ahorrar el costo (0.35 WETH) de la transacción honeypot en caso de que el ataque no tuviera éxito.