Einleitung
In den letzten drei Jahren haben wir mehrere Sicherheitsvorfälle im DeFi-Ökosystem beobachtet. Zur Abwehr der Bedrohungen werden von der Community codezentrierte Methoden wie statische Code-Audits, Smart-Contract-Scanning-Tools oder dynamisches Fuzzing eingesetzt. Obwohl diese sich als wirksam erwiesen haben, argumentieren wir, dass der codezentrierte Ansatz allein keine Lösung für Sicherheitsprobleme und die Vermögenswerte von Projektbenutzern darstellen 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 neben 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 Benutzervermögen im Wert von über 5 Millionen US-Dollar, einschließlich des Falls, der im April 2022 den Exploit von Saddle Finance verhinderte und 3,8 Millionen US-Dollar rettete.
In diesem Blog werden wir die Systemarchitektur von IronDome und seine Erfolgsgeschichten detailliert erläutern. Wir werden auch die Grenzen unseres Systems und Einblicke in die zukünftige Richtung der Bedrohungsprävention diskutieren.
High-Level-Systemarchitektur
Die Grundidee von IronDome ist es, den Pending-Pool von Ethereum zu überwachen, die Angriffstransaktion über unser Transaktionsvorab-Ausführungssystem Mopsus zu erkennen und den Angriff durch automatisches Synthetisieren einer Rettungstransaktion zu blockieren, die anfällige Vermögenswerte in unser sicheres Konto verschiebt, und die Angriffstransaktion über FlashBot vorab auszuführen. Die folgende Abbildung zeigt die Architektur.
Mempool-Überwachung
IronDome überwacht die ausstehenden Transaktionen im Memory Pool über unseren benutzerdefinierten Geth-Client. Entscheidend ist, dass unser System die Transaktionen umgehend und so viele wie möglich überwachen muss.
Angreiferkennung
Jede ausstehende Transaktion wird dem Angreiferkennungsmodul zugeführt. Da diese Transaktionen noch nicht auf der Kette sind, werden wir unsere Transaktionsvorab-Ausführungs-Engine Mopsus nutzen, um diese Transaktionen vorab auszuführen und die Angriffs- (bösartigen) Transaktionen basierend auf den Laufzeitzuständen und Ergebnissen der Transaktion zu erkennen.
Rettungs-Tx-Synthese
Für die Angriffstransaktion synthetisiert IronDome automatisch eine Rettungstransaktion und ihre Hilfskontrakte. Die Rettungstransaktion wird nach einer ähnlichen Methode wie die Angriffstransaktion vorgehen, um den anfälligen Vertrag zu "exploitieren", aber den Gewinn an unser sicheres Konto (ein Multi-Sig-Konto) anstatt an das vom Angreifer kontrollierte Konto zu übertragen. Wir können beispielsweise automatisch Hilfskontrakte bereitstellen, die den Angriffskontrakten ähneln, aber die Token-Überweisungsadresse durch unser sicheres Konto ersetzen. Bei einigen Angriffstransaktionen sind natürlich kompliziertere Ansätze erforderlich.
Für die Rettungstransaktion müssen wir sie vor der Angriffstransaktion auf der Kette haben. Im aktuellen System nutzen wir FlashBot dafür. Erstens müssen wir sicherstellen, dass niemand anderes unsere Rettungs-Tx abhören kann. 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 Erfolgsfälle zusammen.
Die folgende Zeitleiste zeigt, wie unser System Ende April 2022 3,8 Millionen US-Dollar rettete für Saddle Finance. Insbesondere hat unser System den gesamten Prozess der Erkennung der Angriffstransaktion abgeschlossen und die Rettungs-Tx in weniger als einer Sekunde automatisch synthetisiert. Wir haben alle geretteten Gelder an Saddle Finance zurückgegeben. Klicken Sie auf den Link für die ursprüngliche Hack-Tx und unsere Rettungs-Tx sind im Folgenden aufgeführt.
- Ursprüngliche Hack-Tx: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- Unsere Rettungs-Tx: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
Ethische Betrachtung
Wir nehmen Sicherheits-Ethik in unserem System ernst. Obwohl unser System den anfälligen Vertrag "exploitert", um Benutzervermögen 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 Angriffstransaktion erkennt, und synthetisiert automatisch eine ähnliche (um die Angriffstransaktion zu blockieren). Es erstellt die Angriffstransaktion nie von Grund auf.
- 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 immer noch einige Einschränkungen. Im Folgenden werden wir diese Einschränkungen erläutern und weitere Richtungen bei der proaktiven Bedrohungsprävention diskutieren.
- Erstens überwacht unser System die ausstehenden Tx im Mempool. Wenn der Angreifer einen privaten Transaktionsdienst wie FlashBot nutzt, wird die Angriffstransaktion nicht im Mempool sein und daher nicht erkannt werden. Um dieses Problem zu lösen, fordern wir die Zusammenarbeit mit dem Anbieter des privaten Transaktionsdienstes, um die Angriffstransaktion zu erkennen und zu blockieren (ähnlich wie bei der Erkennung von bösartigen Transaktionen wie unser System). Außerdem kann unser System, selbst wenn es die Angriffstransaktion im Pending-Tool nicht blockieren kann, die Angriffstransaktion auf der Kette erkennen und eine Rettungs-Tx senden, um weitere Angriffstransaktionen zu verhindern. Beachten Sie, dass in vielen Fällen mehr als eine Angriffstransaktion vorhanden ist.
- Zweitens ist Sicherheit ein Wettrüsten. Wir haben Fälle gesehen, in denen Angreifer die Hürde für die Synthese der Rettungstransaktion erhöhen. Zum Beispiel können sie eine Angriffstransaktion 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 Angriffs-Tx auf der Kette platziert werden kann, noch offen. Obwohl einige Bietstrategien die Chance erhöhen können, dass unsere Rettungs-Tx 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)
[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/
