Obwohl ein Großteil des Jahres 2023 ein Bärenmarkt für DeFi-Protokolle war, leidet das Ökosystem weiterhin unter schwerwiegenden Hacks aufgrund von Protokollschwachstellen. Insbesondere gab es einen erheblichen Verlust von fast 200 Millionen US-Dollar beim Euler Finance Hack. Gleichzeitig sind neue Trends bei DeFi-Sicherheitsvorfällen aufgetreten, wie z. B. Schwachstellen, die durch Compiler und Inkompatibilitäten zwischen weit verbreiteten Standards verursacht werden. Um diesen Bedrohungen entgegenzuwirken, hat die Community mehrere Lösungen vorgeschlagen, darunter Überwachung und Threat Intelligence. Während sich einige dieser Maßnahmen als wirksam erwiesen haben, sind wir der Meinung, dass diese Bemühungen ad hoc sind. Der Community fehlt es noch an einem systematischen Ansatz und Leitlinien, um DeFi-Protokolle zu schützen.
In diesem Blog werden wir zunächst anhand repräsentativer Fälle neue Trends in der DeFi-Protokollsicherheit vorstellen, dann die aktuellen Lösungen und ihre Grenzen aufzeigen. Abschließend werden wir die Perspektive von BlockSec darlegen, wie DeFi-Protokolle gesichert werden können.
0x0. Neue Trends in der DeFi-Protokollsicherheit
Trend-I: Renommierte Protokolle wurden angegriffen
Im Jahr 2023 wurden einige etablierte und renommierte Protokolle kompromittiert, darunter Curve, Balancer und KyberSwap. Die folgende Tabelle zeigt die Startdaten dieser renommierten Protokolle und wann sie angegriffen wurden. Es ist wichtig zu beachten, dass die ausgenutzten Schwachstellen möglicherweise in Updates eingeführt wurden, die nach der ursprünglichen Einführung der Protokolle erfolgten. Daher sind die in der Tabelle angegebenen Zeiträume ungefähre Angaben und dienen dazu, eine allgemeine Vorstellung von dem betroffenen Zeitrahmen zu vermitteln.
| Protokoll | Startzeit | Zeitpunkt des Sicherheitsvorfalls | Dauer |
|---|---|---|---|
| kyberSwap | 2017 | Nov, 2023 | ~ 6 Jahre |
| Curve | 2020 | Juli, 2023 | ~ 3 Jahre |
| Balancer | 2020 | August, 2023 | ~ 3 Jahre |
Neben den oben genannten Protokollen wurde Aave V2 nach Erhalt eines Schwachstellenberichts aus der Community im November notfallmäßig pausiert. Obwohl das Protokoll nicht angegriffen wurde, löste es dennoch Sicherheitsbedenken hinsichtlich renommierter Protokolle aus.
Diese Protokolle haben mehrere Audits durchlaufen, wobei intern verschiedene Sicherheitsmaßnahmen implementiert wurden. Die folgenden Tabellen listen die Prüfer für jedes Protokoll auf. Es ist zu beachten, dass ein Prüfer möglicherweise nur einige der Smart Contracts innerhalb der Protokolle geprüft hat. Die in der Tabelle genannten Prüfer entsprechen nicht unbedingt denen, die die spezifischen, anfälligen Smart Contracts geprüft haben. Der Zweck dieser Tabelle ist es zu zeigen, dass die Protokolle erhebliche Ressourcen in die Sicherheit investiert haben.
| Protokoll | Prüfer | Link |
|---|---|---|
| kyberSwap | ChainSecurity, Sherlock, Hacken | Audits - KyberSwap Docs |
| Curve | TrailOfBits, MixBytes, Quantstamp, ChainSecurity | Audits - Curve Docs |
| Balancer | OpenZeppelin, TrailOfBits, Certora, ABDK | Security | Balancer |
Glücklicherweise wurden die Opfer durch von den jeweiligen Protokollen implementierte Pläne für ihre Verluste entschädigt. So kündigte beispielsweise Kyber Network an, dass es beabsichtigt, betroffene Nutzer über die KyberSwap Treasury zu entschädigen. Ebenso stimmte die Curve-Community für einen Vorschlag zur Erstattung der finanziellen Verluste von LPs. Diese Maßnahmen sind Schritte zur Wiederherstellung des Vertrauens der DeFi-Community, wenn auch zu erheblichen Kosten.
Trend-II: Neue Arten von Angriffen sind aufgetreten
Angriffsvektoren, die Compiler-Bugs und inkompatible Bibliotheken von Drittanbietern beinhalten, sind tatsächlich im DeFi-Bereich aufgetreten. Beispielsweise wurden als Ursache für den Curve-Sicherheitsvorfall Bugs in bestimmten Versionen von Vyper-Compilern identifiziert. Darüber hinaus wurden einige Protokolle von Angriffen getroffen, die aus der Inkompatibilität zwischen zwei weit verbreiteten Standards resultierten: ERC2771 und Multicall, als diese in beliebten Entwicklungsbibliotheken von Drittanbietern wie thirdweb implementiert wurden. Diese komplexen technischen Herausforderungen unterstreichen die Bedeutung gründlicher Sicherheitspraktiken und die kontinuierliche Weiterentwicklung von Sicherheitsmaßnahmen zum Schutz vor neuen und unvorhergesehenen Schwachstellen.
Compiler-Bugs
1983 hielt Ken Thompson in seiner Turing-Award-Vorlesung mit dem Titel „Reflections on Trusting Trust“ eine Rede. In dieser Rede beschrieb er die Schritte zur Modifizierung eines C-Compilers, um eine Hintertür in ein Programm einzufügen, was zu unerwarteten Ergebnissen führen kann. Die in der Rede vermittelte Idee wurde von der Community gut aufgenommen. Tatsächliche Fälle von bösartigen Compilern in der Praxis sind jedoch selten (mit Ausnahme der bekannten XcodeGhost-Sicherheitsvorfälle). Selbst wenn wir das Sicherheitsmodell von bösartigen Compilern auf gutartige, aber unerwartete Compiler-Verhalten lockern, sind öffentlich bekannte Fälle, die zu schweren finanziellen Verlusten führen, immer noch selten.
Der Curve-Sicherheitsvorfall, der durch einen Vyper-Compiler-Bug verursacht wurde, ist ein öffentlich bekannter Fall, der zu Verlusten von etwa 70 Millionen führte (einige davon wurden zurückgegeben, und die tatsächlichen Verluste betragen etwa 23 Millionen). Die Vyper-Compiler-Versionen 0.2.15, 0.2.16 und 0.3.0 enthalten Bugs, die die Reentrancy-Guard unwirksam machen. Das bedeutet, dass der Angreifer die Reentrancy nutzen kann, um den Hack durchzuführen, was nicht passieren sollte, wenn der Compiler den korrekten Bytecode erzeugt – da der Entwickler den Code hinzugefügt hat, um die Reentrancy zu verhindern.
Attack Tx: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c
Inkompatibilität gängiger Standards
Die Komponierbarkeit von DeFi ermöglicht es verschiedenen Smart Contracts und Standards, sich zu verbinden und leistungsstarke Anwendungen zu erstellen. Dies birgt jedoch potenzielle Kompatibilitätsprobleme. Beispielsweise kann die Kombination beliebter Standards neue Sicherheitslücken einführen, wenn jeder Smart Contract für sich reibungslos funktioniert.
Ein Beispiel für ein solches Inkompatibilitätsproblem betrifft die Standards ERC-2771 und Multicall. ERC-2771 definiert eine Schnittstelle zum Empfang von Meta-Transaktionen über einen vertrauenswürdigen Forwarder, während Multicall ein Mechanismus zum Stapeln mehrerer Funktionsaufrufe innerhalb einer einzigen Transaktion ist. Das Problem entsteht, wenn ein von einem vertrauenswürdigen Forwarder weitergeleiteter Aufruf die eigentliche Aufrufadresse aus den Calldata abruft, was von einem Angreifer manipuliert werden kann. Obwohl jeder Standard isoliert perfekt funktioniert, kann seine kombinierte Verwendung bestimmte Annahmen stören und zu unvorhergesehenen Problemen führen. Weitere Details finden Sie im Blogbeitrag von OpenZeppelin.
Beachten Sie, dass sowohl die Standards ERC-2771 als auch Multicall in beliebten Entwicklungsbibliotheken wie OpenZeppelin und thirdweb implementiert sind. Entwickler vertrauen oft auf diese bekannten Codebasen und schließen sie möglicherweise von der Codeprüfung aus. Diese Praxis kann neue Sicherheitslücken einführen, auch wenn die Protokolle selbst nicht anfällig sind.
Trend-III: Alte Schwachstellen haben neue sicherheitstechnische Auswirkungen
Präzisionsverlust bezieht sich auf die Verringerung der Präzision und Genauigkeit während der Berechnungen, die typischerweise dadurch verursacht wird, dass ein Ergebnis weniger Dezimalstellen aufweist als erwartet. Während statische Analysetools Präzisionsverlustprobleme leicht erkennen können, deutet ihre bloße Existenz nicht unbedingt auf eine Sicherheitslücke hin. Sie gilt nur dann als Schwachstelle, wenn der Präzisionsverlust schwerwiegende Folgen haben könnte. Die Bewertung der Auswirkungen von Präzisionsverlusten ist jedoch oft schwierig, da sie ein tiefes Verständnis der Protokollsemantik und des spezifischen Kontexts des Codes erfordert.
Mehrere Angriffe zielten auf Protokolle ab, die Forks anderer führender Protokolle sind, wie Compound v2 und Aave v2, die anfällig für bekannte Präzisionsprobleme sein können. Insbesondere die Vorfälle mit Hundred Finance und Channels Finance—die Forks von Compound v2 sind—entstanden aus falsch initialisierten Märkten sowie Problemen mit dem Präzisionsverlust. Diese Probleme ermöglichten es Angreifern, Sicherheiten mit einer reduzierten Anzahl von Tokens aufgrund von Rundungsfehlern zurückzulösen.
Attack Tx: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d
0x1. Aktuelle Lösungen
Es stimmt, dass renommierte DeFi-Protokolle erheblich in Sicherheitsmaßnahmen investiert haben und mehrere Runden von Sicherheitsaudits durchlaufen haben. Nichtsdestotrotz ist es angesichts der riesigen Mengen an Nutzervermögen, die diese Protokolle verwalten, absolut gerechtfertigt, die kritische Natur der Protokollsicherheit zu betonen. Über die Code-Prüfung hinaus gibt es weitere vorgeschlagene Lösungen wie die Bedrohungsüberwachung. Lassen Sie uns den aktuellen Stand dieser Lösungen und ihre Grenzen untersuchen.
Code-Prüfung
Die Code-Prüfung, wie hier definiert, ist in der Tat ein kritischer Prozess bei der Sicherheitsbewertung von DeFi-Protokollen, der typischerweise vor der Live-Schaltung eines Protokolls durchgeführt wird. Sie umfasst eine Reihe von Techniken, darunter manuelle Code-Überprüfung, statische Analyse, dynamisches Fuzz-Testing und formale Verifizierung. Außerdem kann dieser Prozess bei einem (oder wenigen) Prüfungsunternehmen oder über eine Community-gesteuerte Methode durchgeführt werden. Es gibt jedoch Einschränkungen bei der Code-Prüfung, die anerkannt werden müssen.
-
Erstens erfolgt die Code-Prüfung hauptsächlich vor der Bereitstellung des Protokolls. Sobald das Protokoll live ist, ist der Prüfprozess in der Regel abgeschlossen, und die laufende Sicherheit kann durch die anfängliche Code-Prüfung nicht kontinuierlich bewertet werden. Das bedeutet, dass alle nach der Veröffentlichung auftretenden Schwachstellen oder Probleme möglicherweise nicht durch die anfängliche Code-Prüfung erkannt werden.
-
Zweitens hat die Code-Prüfung oft Schwierigkeiten, subtile Schwachstellen zu identifizieren, die komplexe Interaktionen und spezifische Zustände erfordern, um ausgenutzt zu werden. Die Komponierbarkeit von DeFi-Protokollen, obwohl sie ein Merkmal ist, das Flexibilität und Integration fördert, erweitert den Programmraum erheblich und stellt schwere Herausforderungen für menschliche Prüfer und statische Analysetools dar, die Schwierigkeiten haben, den gesamten Bereich der Programmzustände zu erkunden. Auch wenn dynamisches Fuzz-Testing von Vorteil sein kann, ist es durch Transaktions- und Zustandsabhängigkeiten eingeschränkt. Das Fehlen von DeFi-Protokoll-bewussten Fuzzing-Orakeln, die Fehler erkennen können, ist eine erhebliche Lücke in diesem Bereich, die eine offene Forschungsfrage sowohl in der Industrie als auch in der akademischen Welt bleibt.
-
Drittens gibt es einen Mangel an qualifizierten Code-Prüfern, der aufgrund des begrenzten Talentpools nicht schnell behoben werden kann. Die Code-Prüfung ist eine interdisziplinäre Aufgabe, die Kenntnisse in Cybersicherheit, Finanzen und Mathematik erfordert. Nur eine ausgewählte Anzahl von Universitäten bietet derzeit eine Ausbildung in diesem Spezialgebiet an, was zu hohen Kosten für qualitativ hochwertige Code-Prüfungen und langen Wartezeiten für Dienstleistungen führt. Infolgedessen können Protokolle live gehen, ohne eine Code-Prüfung durchgeführt zu haben, um ihre Geschäftsfristen einzuhalten.
-
Viertens ist die Beurteilung der Qualität einer Code-Prüfung für die Nutzer schwierig. Obwohl die Nutzer am stärksten an der Sicherheit des Protokolls interessiert sind, da sie ihre Vermögenswerte darin anlegen, fehlt den meisten die Fähigkeit, die Gründlichkeit einer Code-Prüfung zu beurteilen. Dies kann dazu führen, dass Prüfungen nur zum Schein durchgeführt werden, was letztendlich die Sicherheit des Protokolls und der Nutzervermögen gefährden kann.
Zusammenfassend lässt sich sagen, dass die Code-Prüfung zwar ein wertvolles Werkzeug zur Sicherung von Protokollen ist, ihre inhärenten Einschränkungen jedoch bedeuten, dass sie nicht die einzige Sicherheitslösung sein kann.
Bedrohungsüberwachung
Die Grundidee der Bedrohungsüberwachung ist die Überwachung und Erkennung von verdächtigen Dingen. Dies verbessert zwar die Sicherheit, muss aber die folgenden Bedenken berücksichtigen, um wirksam zu sein.
-
Erstens ist die Genauigkeit von Bedrohungsüberwachungssystemen entscheidend. Sie müssen ein Gleichgewicht finden, indem sie sowohl Fehlalarme als auch Falsch-Negativ-Fehler minimieren. Eine hohe Rate an Fehlalarmen kann zu falschen Warnungen führen, bei denen Benutzer oder Sicherheitsteams gegenüber Warnungen desensibilisiert werden und echte Bedrohungen möglicherweise übersehen.
-
Zweitens erfordert der aktuelle Stand der Bedrohungsüberwachungssysteme oft eine manuelle Bestätigung, um auf die Erkennung verdächtiger Transaktionen zu reagieren. Dies liegt größtenteils an der oben genannten Problematik hoher Fehlalarmraten. Die reaktive Natur manueller Eingriffe ist problematisch, da in der schnelllebigen Umgebung von Blockchain- und DeFi-Protokollen Angriffe Ressourcen schnell aufbrauchen können, oft bevor manuelle Reaktionen implementiert werden können. Daher wird der Wert eines Bedrohungsüberwachungssystems erheblich reduziert, wenn es keine rechtzeitigen automatischen Maßnahmen zur Verhinderung oder Eindämmung von Angriffen bieten kann.
-
Darüber hinaus sollte die Bedrohungsüberwachung persistent sein und in der Lage sein, sich an neue Bedrohungen anzupassen, sobald diese auftreten.
0x2. BlockSecs Perspektive
Wir glauben, dass die Sicherheit von Protokollen mehrere Abwehrmechanismen in verschiedenen Phasen des Lebenszyklus eines Protokolls erfordert, darunter hochwertige Code-Prüfung, Sicherheitstests vor der Veröffentlichung, Angriffsdetektion und -blockierung sowie die Reaktion auf Sicherheitsvorfälle nach der Veröffentlichung. Wir möchten auch einige Perspektiven hervorheben, die in der Community vernachlässigt wurden.
-
Erstens glauben wir, dass für jede kleine Code- oder Konfigurationsaktualisierung eine gründliche Sicherheitstests erforderlich sind. Solche Tests sollten an den tatsächlichen Zuständen des Protokolls und nicht an gefälschten Zuständen von Benutzerdaten durchgeführt werden. Wie bereits erörtert, sind Protokollzustände entscheidend für die Lokalisierung von Schwachstellen in komplexen Protokollen.
-
Zweitens ist ein automatisches Reaktionssystem auf Angriffe, anstelle von manueller Intervention, erforderlich. Dies erfordert ein genaues und promptes Angriffsdetektionssystem mit sehr wenigen Fehlalarmen und nahezu null Falsch-Negativ-Fehlern. Beispielsweise könnten Millionen von Nutzervermögen gerettet werden, wenn eine automatische Reaktion implementiert wird.
-
Drittens sollten geeignete Verfahren zur Reaktion auf Sicherheitsvorfälle etabliert werden, und es werden Sicherheitspartner benötigt, die umfassende Sicherheitsdienste anbieten können. Wenn beispielsweise ein Exploit auftritt, kann der Partner bei der Einrichtung eines Kriegszimmers helfen, Maßnahmen empfehlen, bei der Überprüfung und Prüfung von Sicherheitspatches unterstützen, den Geldfluss verfolgen usw. Der Yearn Finance-Artikel ist eine gute Ressource zur Handhabung von Exploits.
Full-Stack-Sicherheitsdienst von BlockSec
Basierend auf den gewonnenen Erkenntnissen bietet BlockSec Full-Stack-Sicherheitsdienste für Protokolle an.
- Hochwertige Code-Prüfungsdienste. BlockSec bietet sorgfältige Code-Prüfungsdienste für DeFi-Protokolle an. Durch die Nutzung des statischen Analysetools, dynamischer Fuzz-Tests und des differentiellen Testframeworks, die auf kreativer akademischer Forschung basieren, decken unsere Code-Audits sowohl Protokolle als auch die zugrunde liegende EVM-Ausführungsmaschine ab. Außerdem wurde das statische Analysetool HookScan von Uniswap Lab unterstützt, um die Schwachstellen in Uniswap V4-Hooks zu erkennen.
- Phalcon: System zur Angriffsdetektion und -blockierung. Mit kampferprobten Techniken zur Blockierung von mehr als 20 Angriffen und zur Rettung von rund 14 Millionen US-Dollar kann BlockSec Phalcon dem Protokoll helfen, aktiv Angriffskontrakte und Transaktionen zu überwachen (auch bevor der Hack die Angriffstransaktionen startet). Mit einer nahezu 99,99% präzisen Angriffsdetektionsmaschine plus benutzerdefinierten Richtlinien gleicht BlockSec Phalcon Fehlalarme und Falsch-Negativ-Fehler aus und ermöglicht so den automatischen Abwehrmechanismus.
- Sicherheitsvorfallreaktion. BlockSec ist stets der schnellste (wenn nicht gar der erste) Sicherheitsanbieter, der die Grundursachen von Angriffen und Schwachstellen bei DeFi-Hacks identifizieren kann. Wir können Protokolle bei der Überprüfung von Sicherheitspatches unterstützen (Telcoin), die Wiederherstellung von weißen Geldern anbieten [z. B. AnySwap, TransitSwap, Paraspace, Loot], den Geldfluss von Hacks verfolgen und die Identität des Hopeland-Angreifers ermitteln.
0x3. Fazit
Im Jahr 2023 stellten wir fest, dass es neue Trends in der Sicherheit von DeFi-Protokollen gab und viele renommierte Protokolle angegriffen wurden. Wir wissen, dass die technische Sicherung von Protokollen eine komplexe, fortlaufende Herausforderung ist. Einfach nur Code-Prüfungen oder Überwachungssysteme zu übernehmen, reicht nicht mehr aus. Wir brauchen eine Full-Stack-Lösung, die diese Elemente kombiniert und den gesamten Lebenszyklus eines Protokolls begleitet.
Zusammenfassend lässt sich sagen, dass BlockSecs ganzheitlicher Ansatz zur Sicherheit von DeFi-Protokollen, der modernste Prüftechniken, automatische Angriffsschutzwerkzeuge und ein reaktionsschnelles Vorfallmanagement kombiniert, das Unternehmen als führenden Partner für Protokolle positioniert, die ihre Sicherheitsmaßnahmen stärken und Nutzervermögen angesichts der sich entwickelnden Bedrohungen im DeFi-Bereich im Jahr 2024 schützen wollen.



