BlockSec-Retrospektive zur Sicherheit von DeFi-Protokollen im Jahr 2023

Obwohl 2023 für DeFi-Protokolle weitgehend ein Bärenmarkt war, leidet das Ökosystem aufgrund von Protokollschwachstellen weiterhin unter schweren Hacks. Ein besonders bemerkenswerter Vorfall war der Verlust von fast 200 Millionen US-Dollar beim Euler Finance-Hack. Gleichzeitig sind neue Trends bei DeFi-Sicherheitsvorfällen aufgetaucht, wie etwa Schwachstellen, die durch Compiler und Inkompatibilitäten zwischen weit verbreiteten Standards verursacht werden. Um diesen Bedrohungen zu begegnen, hat die Community mehrere Lösungen vorgeschlagen, darunter Überwachung und Threat Intelligence. Obwohl sich einige dieser Maßnahmen als wirksam erwiesen haben, glauben wir, dass es sich dabei größtenteils um Ad-hoc-Lösungen handelt. Der Community fehlt es nach wie vor an einem systematischen Ansatz und einer Anleitung zum Schutz von DeFi-Protokollen.

In diesem Blog werden wir zunächst anhand repräsentativer Fälle die neuen Trends in der Sicherheit von DeFi-Protokollen vorstellen und dann die aktuellen Lösungen sowie deren Grenzen aufzeigen. Abschließend werden wir BlockSecs Sichtweise zur Sicherung von DeFi-Protokollen darlegen.

0x0. Neue Trends in der Sicherheit von DeFi-Protokollen

Trend I: Renommierte Protokolle wurden angegriffen

Im Jahr 2023 wurden einige etablierte und angesehene Protokolle kompromittiert, darunter Curve, Balancer und KyberSwap. Die folgende Tabelle zeigt die Startdaten dieser renommierten Protokolle und den Zeitpunkt ihres Angriffs. Es ist wichtig anzumerken, dass die ausgenutzten Schwachstellen möglicherweise durch Updates eingeführt wurden, die nach dem ursprünglichen Start der Protokolle erfolgten. Daher sind die in der Tabelle angegebenen Zeiträume ungefähre Werte und sollen nur einen allgemeinen Überblick verschaffen.

Neben den oben genannten wurde Aave V2 im November notfallmäßig pausiert, nachdem ein Schwachstellenbericht aus der Community eingegangen war. Obwohl das Protokoll nicht angegriffen wurde, warf dies dennoch Sicherheitsbedenken bei angesehenen Protokollen auf.

Diese Protokolle haben mehrere Audits durchlaufen und intern verschiedene Sicherheitsmaßnahmen implementiert. 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 zwangsläufig denjenigen, 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.

Glücklicherweise wurden die Verluste der Opfer durch Programme der jeweiligen Protokolle kompensiert. Beispielsweise kündigte das Kyber Network an, betroffene Nutzer über die KyberSwap Treasury zu entschädigen. Ähnlich stimmte die Curve-Community für einen Vorschlag, den Liquidity Providern (LPs) ihre finanziellen Verluste zu erstatten. Diese Maßnahmen sind Schritte zur Wiederherstellung des Vertrauens in die DeFi-Community, wenn auch mit erheblichen Kosten verbunden.

Trend II: Neue Arten von Angriffsvektoren sind entstanden

Angriffsvektoren, die Compiler-Fehler und inkompatible Bibliotheken Dritter beinhalten, sind im DeFi-Bereich tatsächlich aufgetaucht. Die Grundursache für den Sicherheitsvorfall bei Curve wurde beispielsweise als Fehler in bestimmten Versionen der Vyper-Compiler identifiziert. Zusätzlich erlitten einige Protokolle Angriffe, die auf der Inkompatibilität zwischen zwei weit verbreiteten Standards basierten: ERC2771 und Multicall, wenn diese in populären 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-Fehler

Im Jahr 1983 hielt Ken Thompson in seiner Turing-Award-Vorlesung eine Rede mit dem Titel „Reflections on Trusting Trust“ (Reflektionen über das Vertrauen in Vertrauen). Darin beschrieb er die Schritte, um einen C-Compiler so zu modifizieren, dass er eine Hintertür in ein Programm einfügt, was zu unerwarteten Ergebnissen führen kann. Die Idee stieß in der Community auf großes Interesse. Reale Fälle bösartiger Compiler sind jedoch selten (abgesehen von den bekannten XcodeGhost-Sicherheitsvorfällen). Selbst wenn man das Sicherheitsmodell von böswilligen Compilern auf gutartiges, aber unerwartetes Compiler-Verhalten erweitert, sind öffentliche Fälle, die ernsthafte finanzielle Verluste verursachen, nach wie vor selten.

Der Sicherheitsvorfall bei Curve, der durch den Fehler im Vyper-Compiler verursacht wurde, ist ein öffentlich bekannter Fall, der Verluste von etwa 70 Millionen verursachte (einige davon wurden zurückgegeben, die tatsächlichen Verluste liegen bei etwa 23 Millionen). Die Vyper-Compiler-Versionen 0.2.15, 0.2.16 und 0.3.0 enthalten Fehler, die den „Reentrancy Guard“ unwirksam machen. Dies bedeutet, dass der Angreifer die Wiedereintrittsmöglichkeit (Reentrancy) für den Hack ausnutzen konnte, was nicht hätte passieren dürfen, wenn der Compiler den korrekten Bytecode generiert hätte – da die Entwickler den Code zur Verhinderung von Wiedereintritten bereits hinzugefügt hatten.

Angriffs-Tx: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c

Inkompatibilität gängiger Standards

Die Kombinierbarkeit (Composability) von DeFi ermöglicht es, verschiedene Smart Contracts und Standards zu verbinden, um leistungsstarke Anwendungen zu erstellen. Dies führt jedoch zu potenziellen Kompatibilitätsproblemen. Beispielsweise kann die Kombination populärer Standards neue Sicherheitslücken einführen, auch wenn jeder einzelne Smart Contract für sich genommen einwandfrei funktioniert.

Ein Beispiel für ein solches Inkompatibilitätsproblem betrifft die Standards ERC-2771 und Multicall. ERC-2771 definiert eine Schnittstelle für den Empfang von Meta-Transaktionen über einen vertrauenswürdigen Forwarder, während Multicall ein Mechanismus zur Batch-Verarbeitung mehrerer Funktionsaufrufe innerhalb einer einzigen Transaktion ist. Das Problem entsteht, wenn ein Aufruf, der von einem vertrauenswürdigen Forwarder weitergeleitet wurde, die tatsächliche Aufrufadresse aus den Calldata abruft, was von einem Angreifer manipuliert werden kann. Obwohl jeder Standard isoliert einwandfrei funktioniert, kann ihre kombinierte Verwendung bestimmte Annahmen stören und zu unvorhergesehenen Problemen führen. Für weitere Details lesen Sie den Blogbeitrag von OpenZeppelin.

Beachten Sie, dass sowohl der ERC-2771- als auch der Multicall-Standard in bekannten Entwicklungsbibliotheken wie OpenZeppelin und thirdweb implementiert sind. Entwickler vertrauen oft auf diese bekannten Codebasen und schließen sie möglicherweise von der Code-Überprüfung aus. Diese Praxis kann neue Sicherheitslücken einführen, selbst wenn die Protokolle selbst nicht von Natur aus anfällig sind.

Trend III: Alte Schwachstellen haben neue Sicherheitsauswirkungen

Präzisionsverlust bezieht sich auf die Verringerung der Genauigkeit bei Berechnungen, die normalerweise dadurch entsteht, dass ein Ergebnis weniger Dezimalstellen hat als erwartet. Während statische Analysetools Präzisionsverlustprobleme leicht erkennen können, deutet ihr bloßes Vorhandensein nicht unbedingt auf eine Sicherheitslücke hin. Erst wenn der Präzisionsverlust zu schwerwiegenden Konsequenzen führen kann, wird er als Sicherheitslücke betrachtet. Die Bewertung der Auswirkungen eines Präzisionsverlusts ist jedoch oft schwierig, da sie ein tiefes Verständnis der Semantik des Protokolls 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, welche anfällig für bekannte Präzisionsprobleme sein können. Insbesondere die Vorfälle bei Hundred Finance und Channels Finance – beides Forks von Compound v2 – ergaben sich aus unsachgemäß initialisierten Märkten sowie Problemen im Zusammenhang mit Präzisionsverlusten. Diese Probleme ermöglichten es Angreifern, Sicherheiten aufgrund von Rundungsfehlern mit einer reduzierten Anzahl von Token einzulösen.

Angriffs-Tx: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d

0x1. Aktuelle Lösungen

Es stimmt, dass renommierte DeFi-Protokolle erheblich in Sicherheitsmaßnahmen investiert und mehrere Runden von Sicherheitsaudits durchlaufen haben. Angesichts der enormen Mengen an Nutzervermögenswerten, die diese Protokolle verwalten, ist es dennoch vollkommen gerechtfertigt, die kritische Bedeutung der Protokollsicherheit zu betonen. Über die Code-Überprü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-Auditierung

Code-Auditierung, wie sie hier definiert wird, ist in der Tat ein kritischer Prozess bei der Sicherheitsbewertung von DeFi-Protokollen, der normalerweise durchgeführt wird, bevor ein Protokoll live geht. Er umfasst eine Reihe von Techniken, darunter manuelle Code-Überprüfung, statische Analyse, dynamische Fuzz-Tests und formale Verifizierung. Zudem kann dieser Prozess bei einer (oder wenigen) Audit-Firmen oder durch einen Community-gesteuerten Ansatz durchgeführt werden. Es gibt jedoch Grenzen der Code-Auditierung, die anerkannt werden müssen.

• Erstens findet die Code-Auditierung primär vor der Bereitstellung des Protokolls statt. Sobald das Protokoll live ist, ist der Audit-Prozess in der Regel abgeschlossen, und die laufende Sicherheit kann nicht kontinuierlich durch das ursprüngliche Audit bewertet werden. Dies bedeutet, dass Schwachstellen oder Probleme, die nach dem Start auftreten, durch das ursprüngliche Audit möglicherweise nicht erkannt werden.

• Zweitens tut sich die Code-Auditierung oft schwer damit, subtile Schwachstellen zu identifizieren, die komplexe Interaktionen und spezifische Zustände erfordern, um ausgenutzt zu werden. Die Kombinierbarkeit von DeFi-Protokollen, obwohl ein Merkmal, das Flexibilität und Integration fördert, erweitert den Programmraum erheblich und stellt menschliche Prüfer sowie statische Analysetools vor große Herausforderungen, welche Schwierigkeiten haben, den vollständigen Bereich der Programmzustände zu erforschen. Auch wenn dynamische Fuzz-Tests hilfreich sein können, sind sie durch Transaktions- und Zustandsabhängigkeiten begrenzt. Das Fehlen von DeFi-Protokoll-bewussten Fuzzing-Orakeln, die Fehler erkennen können, ist eine bedeutende Lücke in diesem Bereich, die sowohl in der Industrie als auch in der Wissenschaft eine offene Forschungsfrage bleibt.

• Drittens gibt es einen Mangel an qualifizierten Code-Prüfern, der aufgrund des begrenzten Talentpools nicht schnell behoben werden kann. Code-Auditierung ist eine interdisziplinäre Aufgabe, die Wissen in den Bereichen Cybersicherheit, Finanzen und Mathematik erfordert. Nur eine begrenzte Anzahl von Universitäten bietet derzeit eine Ausbildung in diesem spezialisierten Feld an, was zu hohen Kosten für Qualitätsaudits und langen Wartezeiten führt. Infolgedessen gehen Protokolle möglicherweise ohne Audit live, um ihre geschäftlichen Zeitpläne einzuhalten.

• Viertens ist die Bewertung der Qualität eines Audits für Nutzer schwierig. Während Nutzer am meisten in die Sicherheit des Protokolls investieren, da sie dort ihre Vermögenswerte platzieren, mangelt es den meisten an der Fähigkeit, die Gründlichkeit eines Audits zu bewerten. Dies kann zu Audits führen, die nur aus Gründen des Scheins durchgeführt werden, was letztendlich die Sicherheit sowohl des Protokolls als auch der Nutzervermögenswerte gefährden kann.

Zusammenfassend lässt sich sagen, dass Code-Auditierung zwar ein wertvolles Werkzeug zur Sicherung von Protokollen ist, ihre inhärenten Grenzen jedoch bedeuten, dass sie nicht die einzige Sicherheitslösung sein kann.

Bedrohungsüberwachung (Threat Monitoring)

Die Grundidee der Bedrohungsüberwachung besteht darin, verdächtige Transaktionen zu überwachen und zu erkennen. Dies verbessert die Sicherheit tatsächlich, muss jedoch die folgenden Bedenken ausräumen, um effektiv zu sein.

• Erstens ist die Genauigkeit von Systemen zur Bedrohungsüberwachung entscheidend. Sie müssen ein Gleichgewicht finden, indem sie sowohl falsch-positive als auch falsch-negative Ergebnisse minimieren. Eine hohe Rate an falsch-positiven Ergebnissen kann zu Fehlalarmen führen, wobei Nutzer oder Sicherheitsteams gegenüber Warnungen abstumpfen und potenzielle echte Bedrohungen übersehen.

• Zweitens erfordern aktuelle Bedrohungsüberwachungssysteme oft eine manuelle Bestätigung, um auf die Erkennung verdächtiger Transaktionen zu reagieren. Dies liegt weitgehend an dem oben erwähnten Problem der hohen Falsch-Positiv-Raten. Die reaktive Natur manueller Eingriffe ist problematisch, da Angriffe im schnelllebigen Umfeld von Blockchain und DeFi-Protokollen Ressourcen oft schnell abziehen können, bevor manuell reagiert werden kann. Daher wird der Wert eines Überwachungssystems erheblich reduziert, wenn es keine rechtzeitigen automatischen Maßnahmen zur Verhinderung oder Abmilderung von Angriffen bieten kann.

• Darüber hinaus sollte die Bedrohungsüberwachung permanent sein und in der Lage sein, sich an neue Bedrohungen anzupassen, sobald diese entstehen.

0x2. BlockSecs Perspektive

Wir denken, dass Protokollsicherheit mehrere Verteidigungslinien in verschiedenen Stadien des Lebenszyklus eines Protokolls erfordert, einschließlich qualitativ hochwertiger Code-Audits, Sicherheitstests vor dem Start, Angriffserkennung und -blockierung sowie Reaktion auf Sicherheitsvorfälle nach dem Start. Wir möchten auch einige Perspektiven hervorheben, die in der Community vernachlässigt wurden.

• Erstens denken wir, dass gründliche Sicherheitstests für jedes noch so kleine Code- oder Konfigurations-Upgrade erforderlich sind. Ein solcher Test sollte auf den tatsächlichen Zuständen des Protokolls durchgeführt werden, anstatt auf fingierten Zuständen von Nutzerdaten. Wie bereits diskutiert, sind Protokollzustände entscheidend für die Lokalisierung von Schwachstellen in komplexen Systemen.

• Zweitens ist ein automatisches Reaktionssystem auf Angriffe, jenseits manueller Eingriffe, erforderlich. Dies erfordert ein präzises und sofortiges Angriffserkennungssystem mit sehr geringen Falsch-Positiv-Raten und nahezu null falsch-negativen Ergebnissen. Zum Beispiel können Millionen von Nutzervermögenswerten gerettet werden, wenn eine automatische Reaktion implementiert ist.

• Drittens sollte ein angemessenes 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 beim Aufbau eines „War Rooms“ helfen, Maßnahmen empfehlen, Sicherheits-Patches überprüfen und prüfen, Geldströme verfolgen usw. Der Artikel von Yearn Finance ist eine gute Quelle für den Umgang mit Exploits.

Full-Stack-Sicherheitsdienst von BlockSec

Basierend auf den gewonnenen Erkenntnissen bietet BlockSec Full-Stack-Sicherheitsdienste für Protokolle an.

• Qualitativ hochwertige Code-Audits. BlockSec bietet gewissenhafte Code-Audit-Services für DeFi-Protokolle an. Durch die Nutzung von statischen Analysetools, dynamischem Fuzzing und Frameworks für differenzielle Tests, unterstützt durch kreative akademische Forschung, decken unsere Audits sowohl die Protokolle als auch die zugrunde liegende EVM-Ausführungs-Engine ab. Zudem wurde das statische Analysetool HookScan von Uniswap Lab unterstützt, um Schwachstellen in Uniswap V4-Hooks zu erkennen.

• Phalcon: System zur Angriffserkennung und -blockierung. Mit bewährten Techniken, die mehr als 20 Angriffe blockiert und etwa 14 Millionen USD gerettet haben, kann BlockSec Phalcon dem Protokoll helfen, Angriffsverträge und Transaktionen aktiv zu überwachen (noch bevor der Hacker die Angriffstransaktionen startet). Mit einer zu nahezu 99,99 % präzisen Angriffserkennungs-Engine und benutzerdefinierten Richtlinien gleicht BlockSec Phalcon Falsch-Positiv- und Falsch-Negativ-Raten aus und ermöglicht den automatischen Abwehrmechanismus.

• Reaktion auf Sicherheitsvorfälle. BlockSec ist stets der schnellste (wenn nicht sogar der erste) Sicherheitsanbieter, der bei DeFi-Hacks die Grundursachen von Angriffen und Schwachstellen identifizieren kann. Wir können Protokollen helfen, Sicherheits-Patches zu überprüfen (Telcoin), White-Hat-Rettungsaktionen durchzuführen [z. B. AnySwap, TransitSwap, Paraspace, Loot], Geldströme von Hacks zu verfolgen und die Identität des Hopeland-Angreifers festzustellen.

0x3. Fazit

Im Jahr 2023 haben wir festgestellt, dass es neue Trends in der Sicherheit von DeFi-Protokollen gibt und viele angesehene Protokolle angegriffen wurden. Wir wissen, dass die Sicherstellung der Protokollsicherheit technisch eine komplexe und andauernde Herausforderung ist. Die einfache Einführung von Code-Audits oder Überwachungssystemen reicht nicht mehr aus. Wir benötigen eine Full-Stack-Lösung, die diese Elemente kombiniert und während des gesamten Lebenszyklus eines Protokolls funktioniert.

Zusammenfassend lässt sich sagen, dass der ganzheitliche Ansatz von BlockSec zur Sicherheit von DeFi-Protokollen – die Kombination modernster Prüfungstechniken, automatischer Abwehrwerkzeuge und reaktionsschnellem Vorfallmanagement – das Unternehmen als führenden Partner für Protokolle positioniert, die ihre Sicherheitsmaßnahmen stärken und Nutzervermögenswerte angesichts der sich entwickelnden Bedrohungen im DeFi-Bereich 2024 schützen möchten.