Das Rennen gegen Zeit und Strategie: Über die AnySwap-Rettung und was wir gelernt haben

Am 18. Januar erkannte unser Überwachungssystem einen Angriff auf das AnySwap-Projekt (auch bekannt als Multichain). Die Schwachstelle liegt in der fehlerhaften Funktion anySwapOutUnderlyingWithPermit(), deren Verifizierungsmechanismus umgangen werden kann, um genehmigte Token abzuziehen.

Obwohl das Projekt verschiedene Ansätze (z. B. das Senden von Transaktionen an die Benutzer, wie in Abbildung 1 gezeigt) verfolgte, um betroffene Benutzer zu benachrichtigen, versäumten es einige von ihnen, rechtzeitig Maßnahmen zu ergreifen (d. h. die Genehmigungen zu widerrufen), um ihre Gelder zu schützen. Infolgedessen konnten Angreifer den Angriff kontinuierlich starten, um die Gelder der Opfer zu erlangen.

Um potenzielle Opfer zu schützen, beschloss unser Team nach reiflicher Überlegung, eine Notfallrettung für den AnySwap-Schwachstellenvertrag (0x6b7a87899490EcE95443e979cA9485CBE7E71522) auf Ethereum durchzuführen. Insbesondere konnten wir die Gelder des kompromittierten Kontos auf unsere White-Hat-Wallet, eine Multisig-Wallet (0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47) auf Ethereum, übertragen.

Um unsere White-Hat-Rettung transparent zu gestalten, dokumentierten wir unsere Absicht in einer PDF-Datei und teilten den Datei-Hash mit der Community. Dies kann unsere Notfallrettung vom Angriff unterscheiden, während gleichzeitig keine Details preisgegeben werden (da die Schwachstelle weiterhin ausgenutzt werden kann). Wir starteten die Notfallrettung vom 21. Januar 2022 bis zum 11. März 2022, und die entsprechenden Nachrichten wurden öffentlich veröffentlicht, wie folgt:

Die Notfallrettung ist keine triviale Aufgabe. Tatsächlich gibt es mehrere Herausforderungen, sowohl technische als auch nicht-technische, um eine erfolgreiche Rettung durchzuführen. Da die Notfallrettung bereits beendet ist, können wir den gesamten Prozess umfassend überprüfen und die gewonnenen Erkenntnisse teilen. Wir glauben, dass diese Erfahrung Licht auf die Sicherung des DeFi-Ökosystems werfen kann.

Wichtige Erkenntnisse (TL;DR)

• Es gibt Wettbewerbe zwischen verschiedenen Teilnehmern, einschließlich Whitehats und Angreifern. Die Zahlungspauschale für Flashbots stieg im Laufe der Zeit rapide an.
• Flashbots funktionierte nicht immer. Stattdessen nutzten einige Angreifer den normalen Mempool, um einen erfolgreichen Angriff zu starten, indem sie ausgeklügelte Strategien anwendeten.
• Einige Angreifer wurden "weißgewaschen", indem sie einen Teil der gestohlenen Gelder zurückgaben, während der Rest als Kopfgeldbelohnung behalten wurde. Dieses Phänomen, obwohl nicht zum ersten Mal aufgetreten, ist in der Community umstritten, da ein solcher Anreiz für die tatsächlichen Whitehats möglicherweise nicht fair ist.
• Um die Community zu überzeugen, ist es eine gute Praxis für Whitehats, die Aktion im Voraus öffentlich bekannt zu machen, ohne sensible Details preiszugeben.
• Die Community kann zusammenarbeiten, um die Rettung effektiver und effizienter durchzuführen. Zum Beispiel durch den Aufbau eines Koordinationsmechanismus zur Reduzierung/Vermeidung von Whitehat-Wettbewerben.

Im Folgenden geben wir zunächst einen Überblick über die Rettungsaktionen im fraglichen Zeitraum. Dann erläutern wir unsere Vorgehensweise bei der Rettung und die zu lösenden Herausforderungen. Danach diskutieren wir einige Lehren, die wir aus der Rettung gezogen haben. Schließlich geben wir einige Gedanken/Vorschläge, die für die Sicherung des Ökosystems von Bedeutung sein könnten.

0x1 Rettungen und Angriffe

0x1.1 Gesamtergebnis

Die in diesem Bericht beobachteten und untersuchten Angriffe und Rettungsaktionen dauerten Monate, von Block 14028474 (18. Januar 2022) bis Block 14421215 (20. März 2022).

Die für Rettungen und Angriffe verantwortlichen Konten sind in der folgenden Tabelle zusammengefasst. Vereinfachung halber werden nur die ersten vier Bits der Adresse zur Darstellung eines EOA verwendet. Ein Konto ist entweder ein Rettungskonto oder ein Angriffskonto. Es ist anzumerken, dass der Typ eines Kontos entweder anhand der von Etherscan.io markierten Labels oder anhand der beobachteten Zieladressen für Überweisungen bestimmt wird.

Insgesamt gibt es 9 Rettungskonten, die 483,027693 ETH gerettet haben (mit einer Gebühr von 295,970554 ETH, d. h. 61,27 % des Gesamtbetrags) und 21 Angriffskonten, die 1433,092224 ETH eingestrichen haben (mit einer Gebühr von 148,903707 ETH, d. h. 10,39 % des Gesamtbetrags). Es ist anzumerken, dass der Verlust eine grobe Schätzung ist, aufgrund einiger komplizierter Interaktionen. Zum Beispiel könnte ein Angriffskonto nach Verhandlungen mit AnySwap zu einem Rettungskonto werden, und wir werden ein solches Phänomen später diskutieren. Die letzte Spalte der Tabelle gibt die an den Miner gesendeten Gebühren an, die zur Gewinnung des Flashbots-Wettbewerbs verwendet wurden.

0x1.2 Der Trend der Gebühr zur Ersteigerung von Flashbots

Wie bereits erwähnt, müssen Whitehats mit Angreifern konkurrieren, um Transaktionen zu senden. Folglich kann der Prozentsatz der Gebühr für den Miner (in Flashbots-Transaktionen) den Grad des Wettbewerbs widerspiegeln. Um dies quantitativ zu messen, untersuchen wir den Gebührenprozentsatz (einschließlich Angriffs- und Rettungstransaktionen) für jeden Block.

Abbildung 4 zeigt den bisher beobachteten Trend (von Block 14028474 bis Block 14369199). Die ersten Angriffstransaktionen beinhalten keine Gebühr, was bedeutet, dass zu diesem Zeitpunkt nur wenige (wenn überhaupt) Wettbewerbe stattfanden. Dies ist sinnvoll, da diese frühen Angriffe möglicherweise nicht gut bekannt waren.

Tatsächlich ereignete sich der erste Angriff mit Gebühr (10 %) in Block 14029765. Seitdem stieg der Gebührenprozentsatz rapide an, da mehr Teilnehmer beteiligt waren. Zum Beispiel erreichte der Prozentsatz in Block 14072385 80 % und bald darauf 91 % in Block 14129449.

Kurz gesagt, der Trend deutet darauf hin, dass es sich eindeutig um ein Wettrüsten handelt, um den Wettbewerb durch Erhöhung der Gebühr für den Miner zu gewinnen.

0x2 Unsere Rettung und die Herausforderungen

0x2.1 Der Weg zur Durchführung der Rettung

Die grundlegende Idee zur Durchführung der Rettung ist recht einfach. Insbesondere müssen wir die Konten überwachen, die WETH für den kompromittierten Vertrag autorisiert haben. Wenn WETH auf das Konto übertragen wird, können wir es durch Ausnutzung des kompromittierten AnySwap-Vertrags direkt auf unsere Multisig-Wallet übertragen. Die wichtigsten Anforderungen sind:

• R1: Effiziente Lokalisierung der Transaktionen, die Token an die Opferkonten übertragen. Wir bezeichnen diese Transaktionen im Folgenden als übertragene TXs.
• R2: Korrektes Erstellen der Transaktionen zur Durchführung der Rettung. Wir bezeichnen diese Transaktionen im Folgenden als Rettungs-TXs.
• R3: Erfolgreiches Frontrunning der von den Angreifern (und anderen Dritten) gesendeten Transaktionen. Wir bezeichnen diese Transaktionen im Folgenden als Angriffs-TXs.

R1 und R2 sind für uns keine Hindernisse. Insbesondere haben wir ein internes System zur Überwachung des Mempools aufgebaut, das es uns ermöglicht, Überweisungstransaktionen rechtzeitig zu lokalisieren. Gleichzeitig haben wir auch ein Werkzeug zur automatischen Erstellung von Transaktionen entwickelt.

R3 bleibt jedoch eine Herausforderung. Man könnte erwarten, dass Flashbots genutzt werden kann, um den Wettbewerb zu gewinnen. Das Ziel zu erreichen ist jedoch nicht so einfach. Erstens können die Angreifer auch Flashbots nutzen. Als gebotsbasiertes System kann die Erfolgsquote von der für den Miner angegebenen Gebühr abhängen. Die Strategie zur Festlegung der Gebühr muss ermittelt werden. Zweitens ist die Verwendung von Flashbots aufgrund des intensiven Wettbewerbs möglicherweise keine gute Wahl. Daher senden wir auch normale Transaktionen über den Mempool. Um den Erfolg zu garantieren, muss die Strategie zur Platzierung der Transaktion an der richtigen Stelle berücksichtigt werden. Schließlich kämpfen wir auch mit anderen Whitehats, deren Verhalten in einigen Fällen verdächtig erscheint.

0x2.2 An unseren Wettbewerben beteiligte

Insgesamt haben wir versucht, 171 verschiedene potenzielle Opfer zu schützen, wobei 10 von ihnen sich selbst schützten, indem sie die Genehmigungen unmittelbar vor unserem Rettungsversuch widerriefen. Bei den verbleibenden 161 gültigen Opfern konnten wir aufgrund der Wettbewerbe nur 14 retten. Die fehlgeschlagenen Fälle sind in der folgenden Tabelle zusammengefasst und umfassen 3 Rettungskonten und 16 Angriffskonten.

Daher gibt es durchaus einige Lektionen, die wir der Community mitteilen möchten.

0x3 Einige Lehren, die wir gezogen haben

0x3.1 Wie bestimmt man die Höhe der Gebühr für den Flashbots-Miner?

Zusammenfassend lässt sich sagen, dass wir von 12 Konkurrenten geschlagen wurden, darunter 2 Rettungskonten und 10 Angriffskonten, die Flashbots nutzten.

Unsere Strategie zur Festlegung der Miner-Gebühr war eher konservativ. Insbesondere zielten wir darauf ab, die Opfer zu schützen, indem wir möglichst wenig Gebühren zahlten. Daher haben wir die Gebühr erst dann aktiv erhöht, wenn bereits erfolgreiche Angriffstransaktionen eine Gebühr festgelegt hatten. Wenn beispielsweise ein Angreifer die Gebühr auf 10 % des Fonds festlegt, würden wir für die nächste Rettung möglicherweise 11 % verwenden, um mit diesem Angreifer zu konkurrieren. Das Ergebnis deutet jedoch darauf hin, dass diese Strategie nicht funktionierte, da die Angreifer (und sogar einige Whitehats) die Gebühr oft (wenn nicht immer) aggressiv erhöhten, um andere zu übertreffen, wie folgt:

• Abbildung 5 zeigt, dass der Angreifer 0x5738** in Block 14071986 die Gebühr auf 70 % festlegte.
• Abbildung 6 zeigt, dass der Whitehat 0x14ca** in Block 14072255 die Gebühr auf 79 % festlegte.
• Abbildung 7 zeigt, dass der Whitehat 0x14ca** in Block 14072385 die Gebühr auf 80 % festlegte.
• Abbildung 8 zeigt, dass der Whitehat 0x9117** in Block 14072417 die Gebühr auf 81 % festlegte.
• Abbildung 9 zeigt, dass der Angreifer 0x5738** in Block 14073395 die Gebühr auf 86 % festlegte.

Kurz gesagt, es scheint ein Nullsummenspiel zu sein, das die Modellierung des Verhaltens verschiedener Teilnehmer erfordert, um den Wettbewerb zu gewinnen.

In der Praxis ist es jedoch schwierig, bessere/optimale Strategien zu finden und gleichzeitig die Kosten so weit wie möglich zu senken.

0x3.2 Wie platziert man die richtige Position im Mempool?

Es scheint nun, dass die Rettung auf dem Wettrüsten des Gebührenwettbewerbs beruht, um Flashbots zu ersteigern. Wir haben jedoch festgestellt, dass die Verwendung von Flashbots aufgrund des intensiven Wettbewerbs anderer Teilnehmer, die nichts mit der Rettung und dem Angriff zu tun hatten, kein Allheilmittel war. In einem solchen Fall kann selbst die höchste von einer Angriffstransaktion angebotene Gebühr nicht garantieren, dass die Chance zur Nutzung von Flashbots erhalten wird.

Alternativ kann eine normale Transaktion mit der richtigen Position im Mempool die Möglichkeit haben, das Ziel zu erreichen. Die richtige Position bedeutet hier, dass die Rettungs-/Angriffstransaktion hinter der übertragenen Transaktion platziert werden sollte und die Position sehr nahe an der übertragenen Transaktion sein sollte (je näher, desto besser). Beachten Sie, dass der Angreifer 0x48e9** mit dieser Strategie 312,014657 ETH erbeutete, ohne Gebühren an Flashbots-Miner zu zahlen.

Die folgenden vier Abbildungen zeigen die beiden größten Gewinne des Angreifers:

• Abbildung 10 zeigt, dass ein Opfer 50 ETH an Position 65 von Block 14051020 hinterlegt hat, und Abbildung 11 zeigt, dass der Angreifer die 50 ETH an Position 66 desselben Blocks erbeutet hat.
• Abbildung 12 zeigt, dass ein Opfer 200 ETH an Position 161 von Block 14052155 hinterlegt hat, und Abbildung 13 zeigt, dass der Angreifer die 200 ETH an Position 164 desselben Blocks erbeutet hat.

Offensichtlich ist diese ausgeklügelte Strategie sehr nützlich und aufschlussreich und verdient mehr Aufmerksamkeit und Anstrengungen, um daraus etwas zu lernen.

0x4 Einige weitere Gedanken

0x4.1 Whitehat-Hack oder Angriff?

Wenn es um die Anerkennung von Whitehat-Hacks geht, sind diese möglicherweise nicht so einfach, wie man erwarten würde.

Zum Beispiel wurde die Adresse 0xfa27 von Etherscan.io als Multichain Exploiter 4 (Whitehat) eingestuft. Tatsächlich wurde sie anfangs als Multichain Exploiter 4 eingestuft. Nach mehreren Verhandlungsrunden zwischen dem Angreifer und dem AnySwap-Projekt wurde der Angreifer überzeugt, einen Teil der gestohlenen Gelder zurückzugeben.

• In TX 0x3c3d** kontaktierte AnySwap den Angreifer:

Zuallererst vielen Dank, dass Sie das WETH erhalten haben. Ich war mir des Hacks nicht bewusst und erkannte die Situation erst, weil das WETH nach der Cowswap-Transaktion nie in meiner Wallet ankam. Angesichts des Betrags, der auf dem Spiel steht, würden Sie 50 ETH als faire Belohnung akzeptieren? Hier ist meine Transaktion: 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7

• In TX 0xd360** antwortete der Angreifer:

Bitte verifizieren Sie, indem Sie mir eine Transaktion zurücksenden. Ich werde Ihnen die restlichen 258 ETH senden. 39 ETH gingen an die Miner, weil es andere Angreifer gab, also musste ich diesen Tipp bezahlen, um das Geld zu retten.

• In TX 0x354f** bestätigte AnySwap dankend nach Erhalt der Gelder:

Gut erhalten, vielen Dank für Ihre Ehrlichkeit.

Offensichtlich wurde dieser Angreifer "weißgewaschen" und hat auch Gewinne aus dem Angriff erzielt. Ähnliche Fälle sind in der Vergangenheit mehrfach aufgetreten und sind in der Community weiterhin umstritten, da ein solcher Anreiz möglicherweise nicht fair ist.

0x4.2 Wettbewerb zwischen Whitehat-Hacks?

Es ist notwendig, einen Koordinationsmechanismus aufzubauen, um Wettbewerbe zwischen Whitehats zu reduzieren/vermeiden. Ein solcher Wettbewerb führt unweigerlich zu einer Verschwendung von Rettungskräften. Bei dieser Rettung gab es 54 Opfer (mit 450 ETH Geldern), die von drei anderen Whitehats geschützt wurden, während wir ebenfalls versuchten, die Rettung durchzuführen.

Der Wettbewerb zwischen Whitehats verschwendete nicht nur die Rettungskräfte, sondern erhöhte auch die Kosten für die Durchführung der Rettung. Wie in Abbildung 7 und Abbildung 8 gezeigt, betrug die von den beiden Rettungs-TXs mit verschiedenen Whitehats ausgegebene Gebühr 80 % bzw. 81 %.

Leider werden sich die Whitehats nicht zurückziehen, es sei denn, es existiert ein Mechanismus zur gegenseitigen Koordination. Andernfalls ist es unmöglich, den Wettbewerb zu beseitigen.

0x4.3 Wie kann eine bessere Rettung durchgeführt werden?

Einerseits ist es für die Überzeugung der Community eine gute Praxis für Whitehats, die Aktion im Voraus öffentlich bekannt zu machen, ohne detaillierte sensible Informationen preiszugeben. Dafür gibt es genügend Zeit, da die Rettung in der Regel ein Hin und Her mit mehreren Versuchen ist, was sich von einmaligen Anstrengungen wie der Abwehr eines bestimmten Angriffs unterscheidet. Selbstverständlich sollten die detaillierten Informationen zu den Schwachstellen nicht offengelegt werden.

Um dies zu erreichen, werden die detaillierten Informationen nicht zu Beginn offengelegt und erst nach Abschluss der Rettung der Community offengelegt, so wie wir es für die AnySwap-Rettung getan haben. Der Hash des Dokuments mit der Absicht des Whitehats kann jedoch mit der Community geteilt werden.

Andererseits kann die Community mehr tun, um die Rettung effektiver und effizienter durchzuführen, einschließlich, aber nicht beschränkt auf:

• Flashbots/Miner können einen grünen Kanal für zertifizierte Whitehats bereitstellen. Der grüne Kanal kann eine hohe Priorität bieten, um die TXs der Angreifer zu frontrunnen und Wettbewerbe zwischen Whitehats zu vermeiden.
• Die angegriffenen Projekte decken die Kosten für Flashbots/Miner.
• Die Projekte können praktische und schnelle Benachrichtigungsmechanismen für Benutzer anbieten.
• Das Projekt kann den Notfallmechanismus im Code anwenden.

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen hat sich zum Ziel gesetzt, die Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt zu verbessern, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits von Smart Contracts und EVM-Ketten an, die Phalcon-Plattform für die proaktive Entwicklung und Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, die effizient im Krypto-Bereich navigieren.

Bisher hat das Unternehmen über 300 namhafte Kunden bedient, darunter MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap, und in zwei Finanzierungsrunden von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital Millionen von US-Dollar erhalten.

Offizielle Website: https://blocksec.com/

Offizieller Twitter-Account: https://twitter.com/BlockSecTeam