BlockSec: Rückblick auf DeFi-Protokollsicherheit 2023

Obwohl vieles von 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. In der Zwischenzeit sind neue Trends bei DeFi-Sicherheitsvorfällen aufgetreten, wie z. B. Schwachstellen, die durch Compiler verursacht werden, und Inkompatibilitäten zwischen weit verbreiteten Standards. Um diesen Bedrohungen entgegenzuwirken, hat die Community mehrere Lösungen vorgeschlagen, darunter Überwachung und Bedrohungsaufklärung. Obwohl sich einige dieser Maßnahmen als wirksam erwiesen haben, sind wir der Meinung, dass diese Bemühungen ad hoc sind. Der Community fehlt weiterhin ein systematischer Ansatz und Anleitung, um DeFi-Protokolle zu schützen.

In diesem Blog werden wir zunächst repräsentative Fälle verwenden, um neue Trends in der DeFi-Protokollsicherheit darzustellen, und dann die aktuellen Lösungen und ihre Grenzen aufzeigen. Abschließend werden wir die Perspektive von BlockSec auf die Sicherung von DeFi-Protokollen darlegen.

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 Aktualisierungen eingeführt wurden, die nach der ursprünglichen Einführung der Protokolle erfolgten. Daher sind die in der Tabelle angegebenen Dauern ungefähre Angaben und sollen einen allgemeinen Eindruck von dem Zeitraum vermitteln.

Neben den oben genannten Protokollen wurde Aave V2 im November nach Erhalt eines Schwachstellenberichts von der Community Notfall pausiert. Obwohl das Protokoll nicht angegriffen wurde, löste es dennoch Sicherheitsbedenken hinsichtlich renommierter Protokolle aus.

Diese Protokolle wurden mehreren Audits unterzogen, 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 notwendigerweise denen, die die spezifischen Smart Contracts geprüft haben, die anfällig waren. Der Zweck dieser Tabelle ist es zu zeigen, dass die Protokolle erhebliche Ressourcen in die Sicherheit investiert haben.

Glücklicherweise wurden die Opfer durch Pläne, die von den jeweiligen Protokollen implementiert wurden, für ihre Verluste entschädigt. Zum Beispiel kündigte Kyber Network an, dass es beabsichtigt, betroffene Nutzer über die KyberSwap Treasury zu entschädigen. Ebenso stimmte die Curve-Community einem Vorschlag zu, LPs für ihre finanziellen Verluste zu erstatten. Diese Maßnahmen sind Schritte zur Wiederherstellung des Vertrauens der DeFi-Community, wenn auch zu erheblichen Kosten.

Trend-II: Neue Angriffvektoren sind aufgetreten

Angriffsvektoren, die Compiler-Bugs und inkompatible Drittanbieterbibliotheken betreffen, sind im DeFi-Bereich aufgetreten. Beispielsweise wurden als Ursache für den Curve-Sicherheitsvorfall Fehler in bestimmten Versionen der Vyper-Compiler identifiziert. Darüber hinaus litten einige Protokolle unter Angriffen, die aus der Inkompatibilität zwischen zwei weit verbreiteten Standards resultierten: ERC2771 und Multicall, als diese in beliebten Drittentwicklungsbibliotheken wie thirdweb implementiert wurden. Diese komplexen technischen Herausforderungen unterstreichen die Bedeutung gründlicher Sicherheitspraktiken und die kontinuierliche Weiterentwicklung von Sicherheitsmaßnahmen, um vor neuen und unvorhergesehenen Schwachstellen zu schützen.

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. Echte Fälle von bösartigen Compilern in der Praxis sind jedoch selten (abgesehen von den bekannten XcodeGhost-Sicherheitsvorfällen.) Selbst wenn wir das Sicherheitsmodell von bösartigen Compilern auf gutartige, aber unerwartete Compilerverhalten lockern, sind öffentliche Fälle, die ernsthafte finanzielle Verluste verursachen, 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 US-Dollar führte (einige davon wurden zurückgegeben, und die tatsächlichen Verluste liegen bei etwa 23 Millionen US-Dollar). Die Vyper-Compiler-Versionen 0.2.15, 0.2.16 und 0.3.0 weisen Fehler auf, die den Reentrancy-Schutz unwirksam machen. Das bedeutet, dass der Angreifer die Reentrancy ausnutzen kann, um den Hack durchzuführen, was nicht passieren sollte, wenn der Compiler den korrekten Bytecode generiert – da der Entwickler den Code zur Verhinderung von Reentrancy hinzugefügt hat.

Angriffs-Tx: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c

Inkompatibilität gängiger Standards

Die Zusammensetzbarkeit von DeFi ermöglicht die Verbindung verschiedener Smart Contracts und Standards, um leistungsstarke Anwendungen zu erstellen. Dies birgt jedoch potenzielle Kompatibilitätsprobleme. Beispielsweise kann die Kombination beliebter Standards zu neuen Sicherheitslücken fü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 für den Empfang von Metatransaktionen über einen vertrauenswürdigen Forwarder, während Multicall ein Mechanismus zum Stapeln mehrerer Funktionsaufrufe innerhalb einer einzigen Transaktion ist. Das Problem tritt auf, wenn ein von einem vertrauenswürdigen Forwarder weitergeleiteter Aufruf die tatsächliche Aufrufadresse aus den Calldata abruft, die von einem Angreifer manipuliert werden kann. Obwohl jeder Standard isoliert einwandfrei funktioniert, kann ihre gemeinsame Nutzung bestimmte Annahmen stören und zu unvorhergesehenen Problemen führen. Weitere Einzelheiten finden Sie in dem Blogbeitrag von OpenZeppelin.

Beachten Sie, dass sowohl der ERC-2771- als auch der Multicall-Standard in beliebten Entwicklungsbibliotheken wie OpenZeppelin und thirdweb implementiert sind. Entwickler verlassen sich 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 Sicherheitseinflüsse

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 Analysatoren Präzisionsverlustprobleme leicht erkennen können, bedeutet ihre bloße Existenz nicht unbedingt eine Sicherheitslücke. Sie gilt nur dann als Schwachstelle, wenn der Präzisionsverlust zu schwerwiegenden Folgen führen könnte. Die Bewertung der Auswirkungen von Präzisionsverlusten ist jedoch oft schwierig, da sie ein tiefes Verständnis der Semantik des Protokolls und des spezifischen Kontexts des Codes erfordert.

Mehrere Angriffe richteten sich gegen Protokolle, 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 Präzisionsverlust. Diese Probleme ermöglichten es Angreifern, Sicherheiten gegen eine reduzierte Anzahl von Token aufgrund von Rundungsfehlern einzulösen.

Angriffs-Tx: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d

0x1. Aktuelle Lösungen

Es stimmt, dass renommierte DeFi-Protokolle erheblich in Sicherheitsmaßnahmen investiert und mehrere Prüfungsrunden durchlaufen haben. Angesichts der riesigen Mengen an Nutzervermögen, die diese Protokolle verwalten, ist es jedoch absolut gerechtfertigt, die kritische Natur der Protokollsicherheit zu betonen. Neben der Codeprüfung 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 tatsächlich ein kritischer Prozess bei der Sicherheitsbewertung von DeFi-Protokollen, der typischerweise vor der Inbetriebnahme eines Protokolls durchgeführt wird. Sie umfasst eine Reihe von Techniken, darunter manuelle Codeüberprüfung, statische Analyse, dynamisches Fuzz-Testing und formale Verifizierung. Dieser Prozess kann auch bei einem (oder wenigen) Prüfungsunternehmen oder durch eine Community-gesteuerte Methode durchgeführt werden. Es gibt jedoch Einschränkungen bei der Code-Prüfung, die anerkannt werden müssen.

• Erstens findet die Code-Prüfung hauptsächlich vor der Bereitstellung des Protokolls statt. Sobald das Protokoll live ist, endet der Prüfprozess in der Regel, und die laufende Sicherheit kann durch die ursprüngliche Code-Prüfung nicht kontinuierlich bewertet werden. Dies bedeutet, dass Schwachstellen oder Probleme, die nach der Einführung auftreten, möglicherweise nicht durch die ursprü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 zum Ausnutzen erfordern. Die Zusammensetzbarkeit von DeFi-Protokollen erweitert zwar den Programmraum erheblich, was ein Merkmal ist, das Flexibilität und Integration fördert, und stellt eine große Herausforderung für menschliche Prüfer und statische Analysatoren 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-protokollbewussten Fuzzing-Orakeln, die Fehler erkennen können, ist eine erhebliche Lücke auf diesem Gebiet, die eine offene Forschungsfrage sowohl in der Industrie als auch in der Wissenschaft 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 wenige Universitäten bieten derzeit Ausbildung in diesem spezialisierten Bereich an, was zu hohen Kosten für qualitativ hochwertige Code-Prüfungen und langen Wartezeiten für Dienstleistungen führt. Infolgedessen können Protokolle, um ihre Geschäftsfristen einzuhalten, ohne Code-Prüfung live gehen.

• Viertens ist die Bewertung der Qualität einer Code-Prüfung für Nutzer schwierig. Obwohl Nutzer am meisten an der Sicherheit des Protokolls interessiert sind, da sie ihre Vermögenswerte darin hinterlegen, fehlt den meisten die Fähigkeit, die Gründlichkeit einer Code-Prüfung zu bewerten. Dies kann dazu führen, dass Prüfungen nur zum Schein durchgeführt werden, was letztendlich die Sicherheit des Protokolls und der Nutzervermögen beeinträchtigen 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 verdächtiger Aktivitäten. 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 eine Balance finden, indem sie sowohl Fehlalarme als auch falsch negative Ergebnisse minimieren. Eine hohe Rate von 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 dem oben genannten Problem hoher Fehlalarmraten. Die reaktive Natur manueller Interventionen ist problematisch, da in der schnelllebigen Umgebung von Blockchain- und DeFi-Protokollen Angriffe Ressourcen schnell abziehen können, oft bevor manuelle Reaktionen umgesetzt werden können. Daher wird der Wert eines Bedrohungsüberwachungssystems erheblich reduziert, wenn es keine zeitnahen automatischen Aktionen zur Verhinderung oder Minderung von Angriffen bereitstellen kann.

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

0x2. BlockSecs Perspektive

Wir sind der Meinung, dass die Sicherheit von Protokollen mehrere Verteidigungsmechanismen in verschiedenen Phasen des Lebenszyklus eines Protokolls erfordert, darunter qualitativ hochwertige Code-Prüfung, Sicherheitstests vor der Einführung, Angriffserkennung und -blockierung sowie die Reaktion auf Sicherheitsvorfälle nach der Einführung. Wir möchten auch einige Perspektiven hervorheben, die in der Community vernachlässigt wurden.

• Erstens sind wir der Meinung, dass für jede kleine Code- oder Konfigurationsaktualisierung gründliche Sicherheitstests erforderlich sind. Solche Tests sollten auf den tatsächlichen Zuständen des Protokolls und nicht auf den 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 manueller Intervention, erforderlich. Dies erfordert ein genaues und schnelles Angriffserkennungssystem mit sehr wenigen Fehlalarmen und nahezu null falsch negativen Ergebnissen. Zum Beispiel können Millionen von Nutzervermögen gerettet werden, wenn eine automatische Reaktion implementiert wird.

• Drittens sollte ein ordnungsgemäßes 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 Erstellung eines War Rooms unterstützen, Maßnahmen empfehlen, bei der Überprüfung und Prüfung von Sicherheitspatches helfen, Geldbewegungen verfolgen usw. Der Artikel von Yearn Finance ist eine gute Ressource 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.

• Hochwertige Code-Prüfungsdienste. BlockSec bietet sorgfältige Code-Prüfungsdienste für DeFi-Protokolle an. Durch die Nutzung des statischen Analysewerkzeugs, des dynamischen Fuzz-Testings und des Differential-Testing-Frameworks, die auf kreativer akademischer Forschung basieren, umfassen unsere Code-Prüfungen sowohl Protokolle als auch die zugrunde liegende EVM-Ausführungs-Engine. Darüber hinaus wurde das statische Analysewerkzeug HookScan von Uniswap Lab unterstützt, um die Schwachstellen in Uniswap V4 Hooks zu erkennen.

• Phalcon: System zur Angriffserkennung und -blockierung. Mit kampferprobten Techniken zur Blockierung von über 20 Angriffen und zur Rettung von rund 14 Millionen US-Dollar kann BlockSec Phalcon dem Protokoll helfen, aktiv Angriffskontrakte und Transaktionen zu überwachen (noch bevor der Hack Transaktionen startet). Mit einer Präzisionsrate von fast 99,99% für die Angriffserkennung plus benutzerdefinierte Richtlinien gleicht BlockSec Phalcon Fehlalarme und falsch negative Ergebnisse aus und ermöglicht den automatischen Abwehrmechanismus.

• Reaktion auf Sicherheitsvorfälle. BlockSec ist immer der schnellste (wenn nicht der erste) Sicherheitsanbieter, der die Ursachen von Angriffen und Schwachstellen bei DeFi-Hacks identifizieren kann. Wir können Protokollen helfen, Sicherheitspatches zu überprüfen (Telcoin-Sicherheitsvorfall: Tiefenanalyse), White-Fund-Rettungsaktionen durchführen z.B. AnySwap, TransitSwap, Paraspace, Loot), Geldbewegungen von Hackern verfolgen und die Identität des Hopeland-Angreifers ermitteln.

0x3. Fazit

Im Jahr 2023 stellten wir fest, dass es neue Trends in der DeFi-Protokollsicherheit gab und viele renommierte Protokolle angegriffen wurden. Wir wissen, dass die Sicherung der Protokollsicherheit auf technischer Ebene eine komplexe, andauernde Herausforderung ist. Einfach Code-Prüfungen oder Überwachungssysteme zu übernehmen, reicht nicht mehr aus. Wir brauchen 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 für die Sicherheit von DeFi-Protokollen, der modernste Prüftechniken, automatische Angriffsschutz-Tools und ein reaktionsschnelles Vorfallmanagement kombiniert, BlockSec 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.