Back to Blog

BlockSec: Rückblick auf DeFi-Protokollsicherheit 2023

January 21, 2024
9 min read

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.

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.

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.

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.

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.