Abschöpfen von MEV-Bots durch Ausnutzung von Schwachstellen im Flashbots-Relay

Im April 2023 nutzte ein Angreifer eine Schwachstelle im Flashbots-Relay aus, um mehrere MEV-Bots anzugreifen und etwa 20 Millionen USD zu erbeuten. Die Ursache für diesen Angriff war, dass eine private Transaktion unter bestimmten Bedingungen in den öffentlichen Pool gelangen konnte, wodurch der Angreifer die durchgesickerte Transaktion „backrunnen“ (direkt nach ihr ausführen) konnte, um Profite zu erzielen. Wir haben zudem einige ausgeklügelte Techniken bei diesem Angriff beobachtet, wie zum Beispiel die Verwendung von Honeypot-Transaktionen, um die Opfer gezielt anzugreifen, sowie einen Selbstschutzmechanismus im Angriffsvertrag.

Hintergrund

Flashbots

Flashbots ist, wie auf der Website beschrieben, „eine Forschungs- und Entwicklungsorganisation, die gegründet wurde, um die negativen Externalitäten des Maximal Extractable Value (MEV) auf zustandsbehafteten Blockchains zu mindern, beginnend mit Ethereum.“ Es gibt verschiedene Akteure bei Flashbots, darunter Searcher (Suchende), Builder (Ersteller) und Relays. Das folgende Bild zeigt ihre Beziehung zueinander.

Das Bild stammt aus der Flashbots-Dokumentation.

Das PBS (Proposer-Builder Separation) Protokoll ist ein Protokoll, das es dem Block-Proposer (Vorschlagenden) ermöglicht, seinen Block-Platz an mehrere Builder zu verkaufen – da sie für die Erstellung eines Blocks ausgewählt wurden –, um die Gewinne zu maximieren. Konkret überwachen mehrere Searcher die Transaktionen im Mempool und generieren „Bundles“ (Bündel), die den Buildern übermittelt werden. Der Builder aggregiert diese Bündel, erstellt den wertvollsten Block und reicht ihn an das Relay weiter. Das Relay übermittelt den Block schließlich an den Block-Proposer, den Validator, der für ein Epochen-Slot zur Blockbildung ausgewählt wurde.

In dieser Architektur ist das Relay eine vertrauenswürdige Partei für Builder und Proposer gleichermaßen, die sich gegenseitig nicht vertrauen. Es stellt sicher, dass der Proposer den Blockinhalt nicht vor dem Signieren des Block-Headers einsehen kann. Zudem gewährleistet es, dass die Gebühren an den Proposer gezahlt werden.

Für Leser, die an einer detaillierten Architektur interessiert sind, verweise ich auf die Flashbots-Dokumentation. Wir müssen uns lediglich die Sicherheitsgarantie merken, die das Relay bieten muss: Das Relay darf dem Proposer den Inhalt des Blocks nicht offenlegen, wenn der Block NICHT in der Chain enthalten ist. Andernfalls kann ein böswilliger Proposer den durchgesickerten Blockinhalt nutzen, um Profite zu erzielen (wie beim Angriff geschehen).

Sandwich-Angriff

Bei einem Sandwich-Angriff platziert ein Angreifer einen Tausch zwischen zwei Transaktionen, um Profit zu machen. Ich möchte dies anhand eines Beispiels verdeutlichen.

Angenommen, wir haben einen DEX-Pool mit zwei Token, WETH und USDC. Ein Nutzer sendet eine Anfrage zum Tausch von WETH in USDC. Diese Transaktion landet im Mempool und wird vom MEV-Bot (einem Searcher) erfasst. Der Bot führt dann zwei Transaktionen aus: eine vor und eine nach der Tausch-Transaktion des Nutzers.

Konkret nutzt der Bot die erste Transaktion, um WETH gegen USDC zu tauschen, was den Preis für USDC erhöht. Danach wird die Tausch-Transaktion des Nutzers ausgeführt (mit weniger USDC, da der Preis aufgrund der ersten Transaktion höher ist). Im Anschluss tauscht die zweite Transaktion des Bots die USDC wieder gegen WETH, was zu mehr WETH führt, als beim ersten Tausch des Bots eingesetzt wurden.

Das Bild stammt aus dem Paper „High-Frequency Trading on Decentralized On-Chain Exchanges“ von Liyi Zhou et al.

Backrunning

Backrunning ist eine Strategie, bei der eine Transaktion unmittelbar nach einem großen Handel ausgeführt wird. Im Grunde nutzt Backrunning Arbitrage-Möglichkeiten aus, die durch den Einfluss eines großvolumigen Handels auf den Token-Preis entstehen. Wenn ein Nutzer beispielsweise einen großen Handel in einem DEX-Pool tätigt, um WETH in USDC zu tauschen, kann dies den USDC-Preis gegenüber anderen Börsen erhöhen. Ein Backrunning-Bot kann diese Arbitrage-Gelegenheit sofort nutzen, um USDC zu einem niedrigeren Preis gegen WETH zu tauschen, mehr WETH zu erhalten und dann wiederum in den DEX-Pools anderer Börsen WETH mit Gewinn zu verkaufen.

Die Schwachstelle

Wie in der Post-Mortem-Analyse dargelegt, existierte die Schwachstelle im Code des Relays. Dieser legte den Blockinhalt gegenüber einem (böswilligen) Proposer offen, selbst wenn der signierte Block-Header ungültig war (wobei die Signatur selbst gültig war). In diesem Fall wurden der ungültige Block-Header und der Blockinhalt, die an die Beacon-Chain gesendet wurden, abgelehnt, und der Proposer konnte das Rennen gewinnen, seinen eigenen Block zu senden und den durchgesickerten Blockinhalt zu nutzen, um Gewinne zu erzielen.

Der Angriffsprozess

Der Angreifer ist der böswillige Proposer, die Opfer sind die MEV-Bots, die beabsichtigten, Sandwich-Transaktionen durchzuführen.

Nehmen wir einen echten Angriff als Beispiel.

Block 16964664
Position 0	Opfer-Transaktion: 0xd2edf726fd3a7f179c \| Phalcon Explorer (blocksec.com)	MEV-Bot nutzte 2454,1 WETH für den Tausch von 4,5 STG
Position 1	Angriffs-Transaktion: 0x4b2a2d03b3dc136ef9 \| Phalcon Explorer (blocksec.com)	Der Angreifer nutzte 158 STG für den Tausch von 2454,1 WETH

Die Opfer- und Angriffs-Transaktionen befanden sich in Block 16964664 an Position 0 bzw. 1. Im Wesentlichen führte das Opfer (der MEV-Bot) einen großen Handel durch, bei dem 2454,1 WETH gegen 4,5 STG im Uniswap WETH-STG-Pool getauscht wurden. Dies schuf eine große Arbitrage-Möglichkeit, und der Angreifer nutzte 158 STG, um das gesamte WETH aus dem Pool abzuziehen.

Die Frage ist: Warum war das Opfer (der MEV-Bot) bereit, 2.454 WETH (etwa 5 Mio. USD wert) zu verwenden, um 4,5 STG-Token (etwa 3 USD wert) im Pool zu tauschen? Beachten Sie, dass die Liquidität im Pool zum Zeitpunkt des Tausches sehr gering war (0,005 WETH und 4,5 STG).

Unsere Analyse zeigt, dass es zwei Gründe dafür gab, dass der MEV-Bot einen solch absurden Tausch durchführte.

Erstens nutzte der Angreifer eine Honeypot-Transaktion, um das Opfer zu ködern, diesen Tausch für einen Sandwich-Angriff durchzuführen. Der Hash dieser Honeypot-Transaktion lautet 0xd534c46ba5a444e886 | Phalcon Explorer (blocksec.com). Speziell sendete der Angreifer eine Transaktion zum Tausch von WETH in STG (vor Block 16964664). Da die Liquidität im Pool sehr niedrig war, schuf dies eine Gelegenheit für den MEV-Bot, einen Sandwich-Angriff zu starten. Wie im folgenden Bild gezeigt, konnte der MEV-Bot ein Sandwich-Angriffs-Bündel erstellen, das drei Transaktionen enthielt (Sandwich-Angriffs-Bündel).

Zweitens verwendete der MEV-Bot eine „gierige“ Sandwich-Strategie und nutzte Flashbots für den Versand der Transaktion. Um den Profit zu maximieren, versuchte die erste Transaktion innerhalb des Bündels, fast alle STG-Token aufzusaugen (mit 2.454 WETH). Dies ist eine extrem gierige Strategie: 5 Mio. USD (2.454 WETH) einzusetzen, um einen Gewinn von etwa 700 USD (0,35 WETH) zu erzielen – ein Verhältnis von 7.000:1. Der Bot nahm an, dass dieser Tausch NICHT öffentlich würde, solange er nicht in der Chain festgeschrieben wäre. Diese Annahme wurde jedoch durch die Schwachstelle im Relay zunichtegemacht. Diese Chance nutzend, erstellte der Angreifer ein neues Bündel, das die ursprüngliche Sandwich-Angriffs-Transaktion des Bots enthielt, und fügte eine Backrunning-Transaktion hinzu, um sich die 2.454 WETH anzueignen.

Die Grafik auf dem Twitter-Account von BlockSec zeigt den gesamten Angriffsprozess.

Der Selbstschutzmechanismus

Wir wissen, dass der Angreifer eine Honeypot-Transaktion sendete, um das Opfer durch Tausch von WETH in STG zu ködern. Was passiert aber, wenn keine Sandwich-Transaktionen zur Ausnutzung der Honeypot-Transaktion verfügbar sind? In solchen Fällen überwachte der Angreifer den Status des Pools und führte einen umgekehrten Tausch durch, um seine 0,35 Ether zu schützen – ein cleverer Schachzug. Unten sehen Sie den dekompilierten Code des Smart Contracts (0xe73f1576af5573714404a2e3181f7336d3d978f9), der die Honeypot-Transaktion ausführte.

Um unsere Erkenntnisse zu verifizieren, haben wir die Honeypot-Transaktion im Phalcon Fork simuliert, jedoch an Position 0 von Block 16964664.

Zusammenfassung

Dies ist der erste Angriff, der eine Schwachstelle im Flashbots-Relay mit ausgeklügelten Angriffsstrategien kombinierte.

Erstens nutzte dieser Angriff eine Zero-Day-Schwachstelle im Flashbots-Relay aus.
Zweitens nutzte er die gierige Sandwich-Strategie und setzte Honeypot-Transaktionen ein, um den MEV-Bot (das Opfer) zu ködern.
Drittens beinhaltete er einen Selbstschutzmechanismus, um die Kosten (0,35 WETH) der Honeypot-Transaktion zu minimieren, falls der Angriff nicht erfolgreich gewesen wäre.