Einleitung
In den letzten drei Jahren haben wir mehrere Sicherheitsvorfälle im DeFi-Ökosystem beobachtet. Um den Bedrohungen zu begegnen, werden von der Community Code-zentrierte Methoden wie statische Code-Audits, Smart-Contract-Scanning-Tools oder dynamisches Fuzzing angewendet. Obwohl diese sich als wirksam erwiesen haben, argumentieren wir, dass der Code-zentrierte Ansatz allein die Sicherheitsprobleme und die Vermögenswerte der Projektbenutzer nicht lösen kann. Beispielsweise gibt es mehrere Fälle, in denen anfällige Verträge von mehreren renommierten Code-Auditing-Unternehmen geprüft wurden.
Wir sind der Meinung, dass es zusätzlich zu den bestehenden Code-zentrierten Ansätzen eine proaktivere Lösung zur Bedrohungsprävention geben sollte, um sich vor den Bedrohungen zu schützen. 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ögenswerte im Wert von über 5 Millionen US-Dollar, einschließlich des Falls, bei dem der Angriff auf Saddle Finance im April 2022 verhindert und 3,8 Millionen US-Dollar gerettet wurden.
In diesem Blog werden wir die Systemarchitektur von IronDome und seine Erfolgsgeschichten ausführlich erläutern. Wir werden auch die Grenzen unseres Systems und unsere Erkenntnisse über die zukünftige Richtung der Bedrohungsprävention diskutieren.
Systemarchitektur auf hoher Ebene
Die Grundidee von IronDome ist es, den ausstehenden Pool von Ethereum zu überwachen, die Angriffstransaktion über unser System zur Transaktionsvorab-Ausführung 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 Angriffstransaktion durch FlashBot im Frontrunning zu überholen. 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 prompt und so viele Transaktionen wie möglich überwachen muss.
Angriffserkennung
Jede ausstehende Transaktion wird an das Angrifferkennungsmodul übergeben. 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 Angriffstransaktionen (bösartigen Transaktionen) basierend auf den Laufzeitzuständen und Ergebnissen der Transaktion zu erkennen.
Rettungstransaktionssynthese
Für die Angriffstransaktion synthetisiert IronDome automatisch eine Rettungstransaktion und ihre Hilfsverträge. Die Rettungstransaktion folgt einer ähnlichen Methode wie die Angriffstransaktion, um den anfälligen Vertrag zu "exploiten", aber die Gewinne auf unser sicheres Konto (ein Multi-Sig-Konto) anstelle des vom Angreifer kontrollierten Kontos zu übertragen. Zum Beispiel können wir Hilfsverträge ähnlich wie die Angriffskontrakte automatisch bereitstellen, aber die Token-Überweisungsadresse auf unser sicheres Konto ändern. Natürlich müssen für einige Angriffstransaktionen kompliziertere Ansätze verwendet werden.
Für die Rettungstransaktion müssen wir sicherstellen, dass sie vor der Angriffstransaktion auf der Kette erscheint. Im aktuellen System nutzen wir dafür FlashBot. Erstens müssen wir sicherstellen, dass niemand sonst unsere Rettungstransaktion abhören kann. Zweitens können wir Strategien anwenden, um unsere Rettungstransaktion an den Anfang 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 für Saddle Finance gerettet hat. Insbesondere hat unser System den gesamten Prozess zur Erkennung der Angriffstransaktion 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 Hack-Transaktion und unsere Rettungstransaktion sind im Folgenden aufgeführt.
- Ursprüngliche Hack-Transaktion: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- Unsere Rettungstransaktion: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
Ethische Überlegungen
Wir nehmen die Sicherheitsethik in unserem System ernst. Obwohl unser System den anfälligen Vertrag "exploitet" , um Benutzervermögenswerte zu retten, glauben wir, dass dieses Handeln kein ethisches Problem darstellt.
- Erstens exploitet unser System den anfälligen Vertrag nicht aktiv. Es reagiert nur, wenn es eine ausstehende Angriffstransaktion erkennt und synthetisiert automatisch eine ähnliche (um die Angriffstransaktion zu blockieren). Es erstellt die Angriffstransaktion niemals selbst.
- Zweitens kommunizieren wir aktiv mit dem betroffenen Protokoll und geben die geretteten Gelder zurück.
Einschränkungen
Obwohl IronDome seine Effektivität gezeigt hat, weist das System noch einige Einschränkungen auf. 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 nutzt, z. B. FlashBot, wird die Angriffstransaktion nicht im Mempool vorhanden sein und somit nicht erkannt. Um dieses Problem zu lösen, fordern wir eine Zusammenarbeit mit dem Anbieter des privaten Transaktionsdienstes, um die Angriffstransaktion zu erkennen und zu blockieren (ähnlich wie bei der Erkennung der bösartigen Transaktion durch unser System). Außerdem kann unser System, auch wenn es die Angriffstransaktion nicht im ausstehenden Pool blockieren kann, die Angriffstransaktion auf der Kette erkennen und eine Rettungstransaktion 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 Messlatte für die Synthese der Rettungstransaktion höher legen. Sie können beispielsweise 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 beheben.
- Drittens ist die Frage, wie die Rettungstransaktion vor der Angriffstransaktion auf der Kette erscheint, immer noch offen. Obwohl einige Gebotsstrategien 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)
[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/
