Einleitung
In den letzten drei Jahren haben wir mehrere Sicherheitsvorfälle im DeFi-Ökosystem beobachtet. Um die Bedrohungen abzuwehren, werden von der Community codezentrierte Methoden wie statische Code-Audits, Smart-Contract-Scanning-Tools oder dynamisches Fuzzing eingesetzt. Obwohl diese Methoden wirksam waren, argumentieren wir, dass der codezentrierte Ansatz die Sicherheitsprobleme und die Vermögenswerte der Projektbenutzer nicht allein lösen kann. Beispielsweise gibt es mehrere Fälle, in denen anfällige Verträge von mehreren angesehenen Code-Audit-Unternehmen geprüft wurden.
Wir glauben, dass es zusätzlich zu den bestehenden codezentrierten Ansätzen eine proaktivere Lösung zur Bedrohungsprävention geben sollte, um sich gegen die Bedrohungen zu verteidigen. Wir haben diese Idee Ende 2021 intern diskutiert und Anfang 2022 ein System namens IronDome entwickelt. Seitdem haben wir das System intern bei BlockSec implementiert. Im Jahr 2022 blockierte IronDome erfolgreich mehrere Angriffe und rettete Vermögenswerte von Nutzern im Wert von über 5 Millionen US-Dollar, darunter den Fall, bei dem der Angriff auf Saddle Finance im April 2022 verhindert wurde und 3,8 Millionen US-Dollar gerettet wurden.
In diesem Blogbeitrag werden wir die Systemarchitektur von IronDome und seine Erfolgsgeschichten detailliert erläutern. Wir werden auch die Einschränkungen unseres Systems und unsere Erkenntnisse über die zukünftige Richtung der Bedrohungsprävention diskutieren.
High-Level-Systemarchitektur
Die Grundidee von IronDome besteht darin, den ausstehenden Pool von Ethereum zu überwachen, die Angreifertransaktion über unser Transaktions-Vorab-Ausführungssystem Mopsus zu erkennen und den Angriff zu blockieren, indem automatisch eine Rettungstransaktion synthetisiert wird, die anfällige Vermögenswerte auf unser sicheres Konto verschiebt, und die Angreifertransaktion über FlashBot zu front-runnen. Die folgende Abbildung zeigt die Architektur.
Mempool-Überwachung
IronDome überwacht die ausstehenden Transaktionen im Speicherpool über unseren angepassten Geth-Client. Der entscheidende Punkt ist, dass unser System die Transaktion umgehend und so viele Transaktionen wie möglich überwachen muss.
Angriffserkennung
Jede ausstehende Transaktion wird an das Angrifferkennungsmodul weitergeleitet. Da diese Transaktionen noch nicht auf der Kette sind, werden wir unsere Transaktions-Vorab-Ausführungsmaschine Mopsus nutzen, um diese Transaktionen vorab auszuführen und die Angreifer- (bösartigen) Transaktionen basierend auf den Laufzeitzuständen und Ergebnissen der Transaktion zu erkennen.
Rettungstransaktion-Synthese
Für die Angreifertransaktion synthetisiert IronDome automatisch eine Rettungstransaktion und ihre Hilfsverträge. Die Rettungstransaktion folgt einer ähnlichen Methode wie die Angreifertransaktion, um den anfälligen Vertrag zu "ausnutzen", aber der Gewinn wird auf unser sicheres Konto (ein Multi-Sig-Konto) und nicht auf das vom Angreifer kontrollierte Konto übertragen. Wir können beispielsweise automatisch Hilfsverträge bereitstellen, die den Angriffskontrakten ähneln, aber die Token-Überweisungsadresse auf unser sicheres Konto umleiten. Natürlich müssen für einige Angreifertransaktionen kompliziertere Ansätze verwendet werden.
Für die Rettungstransaktion müssen wir sie vor der Angreifertransaktion auf der Kette haben. Im aktuellen System nutzen wir FlashBot zu diesem Zweck. Erstens müssen wir sicherstellen, dass andere unsere Rettungstransaktion nicht abhören können. Zweitens können wir einige Strategien anwenden, um unsere Rettungstransaktion an die Spitze des Blocks zu setzen.
Repräsentative Erfolgsgeschichten
Wir haben IronDome Anfang 2022 implementiert. Das System hat erfolgreich mehrere Angriffe erkannt und blockiert. Diese Tabelle fasst einige der erfolgreichen Fälle zusammen.
Die folgende Zeitleiste zeigt, wie unser System Ende April 2022 3,8 Millionen US-Dollar für Saddle Finance gerettet hat. Insbesondere hat unser System den gesamten Prozess der Erkennung der Angreifertransaktion abgeschlossen und die Rettungstransaktion automatisch in weniger als einer Sekunde synthetisiert. Wir haben alle geretteten Gelder an Saddle Finance zurückgegeben. Klicken Sie auf den Link für die ursprüngliche Hacker-Transaktion und unsere Rettungstransaktion, die im Folgenden aufgeführt sind.
- Ursprüngliche Hacker-Transaktion: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- Unsere Rettungstransaktion: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
Ethische Betrachtung
Wir nehmen Sicherheitsethik in unserem System ernst. Obwohl unser System den anfälligen Vertrag "ausnutzt", um Vermögenswerte von Nutzern zu retten, glauben wir, dass diese Handlung kein ethisches Problem darstellt.
- Erstens nutzt unser System den anfälligen Vertrag nicht aktiv aus. Es reagiert nur, wenn es eine ausstehende Angreifertransaktion erkennt und synthetisiert automatisch eine ähnliche (um die Angreifertransaktion zu blockieren). Es erstellt die Angreifertransaktion nie selbst.
- Zweitens kommunizieren wir aktiv mit dem betroffenen Protokoll und geben die geretteten Gelder zurück.
Einschränkungen
Obwohl IronDome seine Wirksamkeit gezeigt hat, hat das System noch einige Einschränkungen. Im Folgenden werden wir diese Einschränkungen erläutern und weitere Richtungen in der proaktiven Bedrohungsprävention diskutieren.
- Erstens überwacht unser System die ausstehenden Transaktionen im Mempool. Wenn der Angreifer einen privaten Transaktionsdienst wie FlashBot nutzt, wird die Angreifertransaktion nicht im Mempool sein und somit nicht erkannt werden. Um dieses Problem zu lösen, rufen wir zur Zusammenarbeit mit dem Anbieter von privaten Transaktionsdiensten auf, um die Angreifertransaktion zu erkennen und zu blockieren (auf ähnliche Weise wie unser System bösartige Transaktionen erkennt). Außerdem kann unser System, selbst wenn es die Angreifertransaktion nicht im ausstehenden Pool blockieren kann, die Angreifertransaktion auf der Kette erkennen und eine Rettungstransaktion senden, um weitere Angreifertransaktionen zu verhindern. Beachten Sie, dass in vielen Fällen mehr als eine Angreifertransaktion vorhanden ist.
- Zweitens ist Sicherheit ein Wettrüsten. Wir haben Fälle gesehen, in denen Angreifer die Messlatte für die Synthese der Rettungstransaktion höher legen. Zum Beispiel können sie eine Angreifertransaktion in mehrere aufteilen und die Gewinnadresse verschleiern. Obwohl diese Probleme gelöst werden können, glauben wir, dass das Wettrüsten nicht aufhören wird. Wir arbeiten an Lösungen, um diese Probleme zu lösen.
- Drittens ist die Frage, wie die Rettungstransaktion vor der Angreifertransaktion auf der Kette platziert werden kann, immer noch offen. Obwohl einige Bietstrategien die Chance erhöhen können, dass unsere Rettungstransaktion in den Block aufgenommen wird, können wir keine 100%ige Garantie geben.
Referenzen und Weiterführende Lektüre
[1] How to Make the BlockChain Attack “Blockable” | by BlockSec [2] The Block: Stablecoin DEX Saddle Finance hacked for $10 million [3] Lend Exploit Post-Mortem — HomeCoin (mirror.xyz) [4] Equalizer Finance on Twitter: “We have recovered the funds from the vaults on Ethereum and BSC. Now the team is working on recovering the funds from the Polygon and Optimism chains. A big thank you to @BlockSecTeam who managed to block the attackers, protect and return the assets!” / Twitter [5] FSWAP on Twitter: “The details of the attack on FSWAP liquidity progress” / Twitter [6] https://forta.org/blog/blocksec-and-forta-work-to-secure-web3-beyond-audits/ [7] https://forta.org/blog/the-future-of-threat-prevention-in-web3/
