Reentrancy-Angriffe erklärt: Smart-Contract-Sicherheit und DeFi-Risiken
Ein Smart Contract kann technisch korrekt auf einer Blockchain ausgeführt werden und dennoch eine gravierende Sicherheitslücke besitzen. Reentrancy gehört zu den bekanntesten Fehlerklassen in Ethereum und DeFi. Hier erfährst Du, wie der Wiedereintritt entsteht, welche Verluste möglich sind, wie Entwickler vorbeugen und was Du als Nutzer prüfen kannst.
Reentrancy bei Smart Contracts: Was bedeutet das?
Reentrancy bezeichnet einen Wiedereintritt in einen Smart Contract, bevor ein vorheriger Aufruf seine Arbeit vollständig abgeschlossen hat. Ein Vertrag ruft einen anderen Vertrag auf und gibt damit vorübergehend die Kontrolle ab. Der aufgerufene Vertrag kann unter bestimmten Bedingungen wieder eine Funktion des ersten Vertrags auslösen. Das ist nicht automatisch ein Fehler. Gefährlich wird es, wenn der ursprüngliche Vertrag zwischenzeitlich mit einem unvollständigen Kontostand, einer nicht aktualisierten Schuld oder einem anderen inkonsistenten Zustand arbeitet. Dann kann eine eigentlich zulässige Operation mehrfach ausgeführt werden.
Das Thema betrifft vor allem programmierbare Blockchains wie Ethereum und kompatible EVM-Netzwerke. Es geht nicht darum, dass eine Blockchain selbst plötzlich mehrere widersprüchliche Transaktionen bestätigt. Der Fehler liegt in der Reihenfolge und den Annahmen des Anwendungscodes. Ein Nutzer kann eine Transaktion korrekt signieren und trotzdem Geld verlieren, wenn die von ihm verwendete Anwendung eine ausnutzbare Schwachstelle enthält. Die Unterscheidung zwischen Netzwerksicherheit und Anwendungssicherheit ist deshalb zentral.
Für Anlegerinnen und Anleger ist Reentrancy relevant, weil DeFi-Anwendungen häufig mehrere Verträge verbinden: Ein Tresor hält Einlagen, eine Strategie investiert Vermögenswerte, ein Token meldet Salden und ein Oracle liefert Preise. Jeder Übergang zwischen Verträgen kann neue Annahmen erzeugen. Ein Audit kann Risiken reduzieren, ersetzt aber weder sorgfältige Architektur noch laufende Überwachung. Eine Anwendung kann technisch erreichbar, liquide und populär sein und dennoch fehlerhaften Code enthalten.
Wie entsteht der Angriff technisch?
Stell Dir einen vereinfachten Tresor vor. Er führt für jede Adresse einen internen Guthabeneintrag. Wer Guthaben besitzt, darf es auszahlen lassen. Eine unsichere Auszahlungsfunktion prüft zuerst den Guthabenwert, sendet anschliessend Ether und setzt erst danach den internen Guthabeneintrag auf null. Bei einer gewöhnlichen Empfängeradresse mag das unauffällig funktionieren. Ist der Empfänger jedoch selbst ein Smart Contract, kann der Transfer Code auf dessen Seite ausführen. Dieser Code kann erneut die Auszahlungsfunktion des Tresors aufrufen, solange dessen ursprünglicher Guthabeneintrag noch unverändert ist.
Der kritische Zeitpunkt ist also nicht das Ende der Blockchain-Transaktion, sondern die Phase zwischen externer Interaktion und interner Zustandsänderung. Ethereum führt die Aufrufe innerhalb einer Transaktion geordnet aus. Ein externer Aufruf kann jedoch einen weiteren verschachtelten Aufruf starten. Das ursprüngliche Programm setzt erst fort, wenn dieser Aufruf zurückkehrt. Die offizielle Solidity-Dokumentation warnt ausdrücklich davor, bei solchen Aufrufen die Kontrolle über die Ausführungsreihenfolge zu unterschätzen.
Eine Reentrancy-Schwachstelle muss nicht mit einer Ether-Auszahlung beginnen. Externe Token-Callbacks, Hooks, Governance-Funktionen, Kreditoperationen oder Verträge, die andere Verträge abfragen, können ebenfalls betroffen sein. Entscheidend ist, ob eine geschützte Invariante während eines Zwischenzustands verletzt werden kann. Eine Invariante ist eine Eigenschaft, die immer gelten soll, beispielsweise dass alle auszahlbaren Guthaben zusammen nicht grösser als die verfügbaren Mittel sind.
Rechenbeispiel: Wie kann aus einer Auszahlung ein Verlust werden?
Angenommen, ein Tresor enthält insgesamt 50 ETH. Ein bestimmtes Konto hat intern ein legitimes Guthaben von 2 ETH. Eine fehlerhafte Funktion liest diesen Betrag, sendet 2 ETH und aktualisiert den Saldo erst nach der Überweisung. Wenn ein bösartiger Empfängervertrag die Funktion vor dieser Aktualisierung erneut aufruft, kann er unter den vereinfachten Annahmen nochmals 2 ETH anfordern. Bei vier erfolgreichen Auszahlungen würden 8 ETH abfliessen, obwohl das interne Guthaben ursprünglich nur 2 ETH betrug. Der überhöhte Abfluss beträgt dann 6 ETH.
Dieses Beispiel ist bewusst schematisch. In einer realen Implementierung beeinflussen verfügbare Liquidität, Gas, Zugriffskontrollen, Rückgabewerte, Schutzmechanismen und weitere Zustandsvariablen den Ablauf. Es ist weder eine Prognose über typische Schadenshöhen noch eine Anleitung zum Angriff. Es zeigt lediglich, warum die Reihenfolge von Lesen, Senden und Aktualisieren entscheidend ist. Der finanzielle Schaden kann andere Einleger treffen, deren Ansprüche weiterhin in der Buchhaltung stehen, während die verfügbaren Vermögenswerte bereits geschrumpft sind.
Bei einem Tresor mit 50 ETH und insgesamt 50 ETH berechtigten Einlagen würde ein ungedeckter Abfluss von 6 ETH die verbleibende Deckung rechnerisch auf 44 ETH reduzieren. Eine spätere Auszahlung kann dann scheitern, obwohl die Oberfläche weiterhin ein Guthaben anzeigt. Bei tokenisierten Tresoren kann der Schaden indirekt über einen sinkenden Gegenwert der Anteile auftreten. Deshalb ist ein angezeigter Tokenbestand kein Beweis dafür, dass die zugrunde liegenden Vermögenswerte vollständig vorhanden und jederzeit verfügbar sind.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.
Bitcoin mit Relai kaufen – Gutscheincode AUSWANDERNSCHWEIZ. Relai bietet Bitcoin an, nicht die im Fachartikel behandelten Altcoins.
Welche Varianten von Reentrancy gibt es?
Die klassische Variante betrifft einen wiederholten Aufruf derselben Funktion. Eine Auszahlung ruft den Empfänger auf, und der Empfänger springt in dieselbe Auszahlung zurück. Diese Form lässt sich relativ gut erklären und mit einer sorgfältig gesetzten Zustandsänderung oder einem passenden Wiedereintrittsschutz oft verhindern. Sie ist aber nur ein Teil des Problems. Entwickler müssen die gesamte Menge erreichbarer Funktionen und nicht bloss einen einzelnen Auszahlungsweg untersuchen.
Bei Cross-Function-Reentrancy wird während einer noch nicht abgeschlossenen Funktion eine andere Funktion desselben Vertrags aufgerufen. Ein einfaches Schloss nur auf der ersten Funktion kann unzureichend sein, wenn die zweite Funktion denselben unvollständigen Zustand ausnutzt. Cross-Contract-Reentrancy betrifft Systeme, deren Geschäftslogik auf mehrere Verträge verteilt ist. Ein Vertrag kann eine scheinbar harmlose Information aus einem anderen Modul lesen, obwohl dessen Daten gerade vorübergehend inkonsistent sind.
Auch Read-only-Reentrancy verdient Beachtung. Eine als lesend deklarierte Funktion verändert möglicherweise selbst keinen Zustand, kann aber während einer externen Interaktion einen vorübergehend falschen Preis oder Anteilwert zurückgeben. Wenn ein anderes Protokoll diese Information für Sicherheiten oder Kreditgrenzen verwendet, entsteht eine indirekte Gefährdung. Deshalb reicht es nicht aus, nur nach Funktionen zu suchen, die Ether versenden. Preisberechnung, Bilanzierung und gegenseitige Abhängigkeiten müssen ebenfalls berücksichtigt werden.
Warum sind DeFi-Protokolle besonders exponiert?
DeFi lebt von Zusammensetzbarkeit. Ein Nutzer kann Token in einen Liquiditätspool einzahlen, dafür Anteil-Token erhalten, diese als Sicherheit hinterlegen und über eine weitere Anwendung einen Kredit aufnehmen. Jede Schicht verlässt sich auf Annahmen über die andere. Werden Werte in einem Zwischenzustand gelesen, kann ein lokaler Fehler Auswirkungen auf mehrere Protokolle haben. Das bedeutet nicht, dass alle DeFi-Protokolle unsicher sind. Es bedeutet, dass ihre Sicherheitsgrenzen nicht immer mit der sichtbaren Benutzeroberfläche übereinstimmen.
Die blosse Existenz einer externen Schnittstelle ist noch keine Schwachstelle. Häufig werden externe Aufrufe absichtlich benötigt, etwa um Token zu übertragen oder Strategien auszuführen. Das Risiko entsteht durch unzureichend kontrollierte Zustandsübergänge, falsche Reihenfolgen oder fehlende Schutzmassnahmen. Ein gut dokumentiertes Protokoll kann nachvollziehbar machen, welche Verträge Vermögenswerte halten, wer Änderungen vornehmen darf und welche Sicherheitsannahmen zwischen Modulen gelten.
Bei der Bewertung eines Protokolls solltest Du daher nicht nur nach einer Audit-Plakette suchen. Interessanter sind konkrete Auditberichte mit Versionsnummern, behobenen Befunden, dokumentierten Rest-Risiken und einer klaren Zuordnung zum tatsächlich eingesetzten Code. Ein Audit von vor zwei Jahren sagt wenig über einen heute vollständig ausgetauschten Vertrag aus. Auch eine verifizierte Contract-Adresse garantiert nicht, dass die wirtschaftliche Konstruktion solide ist.
Checks-Effects-Interactions: Die grundlegende Schutzregel
Die offizielle Solidity-Dokumentation empfiehlt das Muster Checks-Effects-Interactions. Zuerst werden Voraussetzungen geprüft: Ist der Nutzer berechtigt, stimmt der Betrag und ist genügend Guthaben vorhanden? Danach wird der interne Zustand aktualisiert, etwa indem der auszuzahlende Betrag abgezogen wird. Erst zum Schluss erfolgen externe Aufrufe, beispielsweise die tatsächliche Überweisung. Bei einem erneuten Aufruf sieht der Vertrag dadurch bereits den aktualisierten Guthabenwert.
Diese Reihenfolge ist eine wichtige Verteidigung, aber kein universelles Gütesiegel. Komplexe Anwendungen können mehrere voneinander abhängige Zustände und externe Module besitzen. Wenn eine Funktion nur einen Teil der Daten aktualisiert und anschliessend einen fremden Vertrag aufruft, kann weiterhin ein problematischer Zwischenzustand existieren. Die Sicherheitsprüfung muss deshalb die Invarianten des Gesamtsystems erfassen. Besonders sorgfältig müssen Entwickler Funktionen betrachten, die dieselben Reserven, Schulden oder Anteile verwenden.
Die praktische Lehre für Nutzer lautet nicht, selbst jeden Solidity-Vertrag vollständig prüfen zu müssen. Vielmehr solltest Du erkennen, warum seriöse Projekte Sicherheitsdokumentation, unabhängige Reviews, transparente Änderungen und konservative Auszahlungsmechanismen benötigen. Sicherheitsarchitektur ist kein Marketingmerkmal, sondern eine überprüfbare Eigenschaft des eingesetzten Codes und seiner Betriebsprozesse.
ReentrancyGuard und zusätzliche Sicherheitsmechanismen
OpenZeppelin stellt mit ReentrancyGuard einen verbreiteten Baustein bereit. Ein geschützter Einstiegspunkt lässt während seiner Ausführung keinen erneuten Eintritt in andere mit demselben Schutzmechanismus versehene Funktionen zu. In der Dokumentation zu Contracts 5.x wird erläutert, dass entsprechend markierte Funktionen nicht ohne Weiteres gegenseitig aufgerufen werden können. Entwickler müssen ihre internen und externen Funktionsgrenzen daher bewusst gestalten.
Ein Schutzmechanismus allein ersetzt keine korrekte Buchhaltung. Wird der Guard nur auf einem Einstiegspunkt eingesetzt, während ein anderer verwundbarer Einstiegspunkt offenbleibt, ist das Problem nicht automatisch gelöst. Ebenso können Zugriffskontrollen, Pausenmechanismen, Limits, zeitverzögerte Änderungen und Monitoring helfen, die Auswirkungen eines Fehlers zu begrenzen. Solche Massnahmen besitzen jedoch eigene Risiken, beispielsweise zentralisierte Administratorrechte oder eine verzögerte Wiederaufnahme von Auszahlungen.
Für Nutzer sind besonders die Upgrade-Rechte relevant. Ein unveränderlicher Vertrag hat andere Risiken als ein Proxy, dessen Implementierung von einer kleinen Gruppe kurzfristig ersetzt werden kann. Upgrade-Fähigkeit erlaubt Fehlerkorrekturen, schafft aber auch eine zusätzliche Vertrauensannahme. Prüfe, ob es Timelocks, Multisignatur-Verfahren, öffentliche Änderungsankündigungen und eine nachvollziehbare Governance gibt. Keine dieser Massnahmen macht einen Vertrag unangreifbar.
Wie lässt sich das Risiko vor einer Einzahlung einschätzen?
Beginne bei der exakten Contract-Adresse. Der Name eines Protokolls kann kopiert werden, und mehrere Netzwerke können ähnlich bezeichnete Token besitzen. Nutze möglichst die offiziellen Dokumentationen und prüfe, welche Adresse die Anwendung tatsächlich verwendet. Eine offene Quellcodeanzeige im Explorer ist hilfreich, aber kein vollständiger Sicherheitsnachweis. Der veröffentlichte Code muss zur eingesetzten Implementierung passen; bei Proxy-Verträgen gehört die dahinterliegende Logik zur Prüfung.
Danach sind die wirtschaftlichen Abhängigkeiten wichtig. Wo liegen die Vermögenswerte? Werden sie in andere Strategien weitergeleitet? Gibt es Brücken zu anderen Netzwerken? Können Drittanbieter Sicherheiten liquidieren oder Preisparameter verändern? Reentrancy ist nur eine mögliche Fehlerklasse. Ein Protokoll kann technisch gegen Wiedereintritt geschützt sein und trotzdem durch fehlerhafte Oracles, unzureichende Liquidität oder kompromittierte Administratoren Verluste erleiden.
Ein vernünftiges Risikomanagement beginnt mit der Annahme, dass ein vollständiger Verlust möglich ist. Setze keine Mittel ein, die Du kurzfristig für Miete, Steuern oder Lebenshaltung benötigst. Verteile nicht blind auf mehrere Anwendungen, wenn diese dieselben zentralen Verträge oder Bridges verwenden. Eine scheinbare Diversifikation über fünf Oberflächen kann wirtschaftlich eine einzige gemeinsame Schwachstelle enthalten. Dokumentiere Einzahlungen und Auszahlungen, damit Du im Schadensfall Deine Transaktionen nachvollziehen kannst.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.
Bitcoin mit Relai kaufen – Gutscheincode AUSWANDERNSCHWEIZ. Relai bietet Bitcoin an, nicht die im Fachartikel behandelten Altcoins.
Was bedeutet ein Hack für Einleger?
Wenn ein Protokoll Vermögenswerte verliert, ist die rechtliche und wirtschaftliche Lage von seiner Struktur abhängig. Ein Anteil-Token kann weiter im Wallet liegen, obwohl sein Gegenwert sinkt. Ein Rückzahlungsanspruch kann technisch oder vertraglich unklar sein. Bei zentralen Verwahrern kommen zusätzlich Insolvenz- und Gegenparteirisiken hinzu. Es gibt keine allgemeine Garantie, dass ein Projekt nach einem Hack Einlagen vollständig ersetzt.
Manche Protokolle verfügen über Notfallfunktionen oder Reserven, doch deren Umfang, Auslöser und Verfügbarkeit unterscheiden sich. Auch ein öffentlich angekündigter Entschädigungsplan ist nicht mit einer rechtlich gesicherten Auszahlung gleichzusetzen. Wer sich auf eine angebliche Versicherung verlässt, sollte den konkreten Versicherungsumfang, Ausschlüsse, Selbstbehalte und Anspruchsvoraussetzungen prüfen. Ein Bug-Bounty-Programm belohnt Sicherheitsforscher, stellt aber keine Einlagensicherung für Nutzer dar.
Nach einem Sicherheitsvorfall ist besondere Vorsicht vor Phishing angebracht. Betrüger imitieren häufig Support-Kanäle oder versprechen eine sofortige Rückerstattung gegen eine Wallet-Signatur. Teile niemals Deine Seed Phrase oder privaten Schlüssel. Unterschreibe keine unbekannte Transaktion, nur weil sie als Entschädigungsformular bezeichnet wird. Informiere Dich über die offiziellen Kommunikationskanäle und sichere relevante Transaktionsdaten, bevor Du weitere Schritte unternimmst.
Schweiz: Steuerliche und regulatorische Einordnung
Ein Reentrancy-Verlust ist zunächst ein technischer und wirtschaftlicher Vorgang. Ob und wie ein Verlust steuerlich berücksichtigt werden kann, hängt von den konkreten Umständen, der steuerlichen Qualifikation der Vermögenswerte und dem anwendbaren Recht ab. Für Privatpersonen in der Schweiz sind insbesondere Vermögenssteuer, die Abgrenzung zwischen privater Vermögensverwaltung und gewerbsmässigem Handel sowie die Behandlung allfälliger Erträge relevant. Eine pauschale Aussage, jeder DeFi-Hack sei steuerlich abzugsfähig, wäre falsch.
Die Eidgenössische Steuerverwaltung veröffentlicht Informationen zu Kryptowährungen und deren steuerlicher Behandlung. Bei komplexen DeFi-Transaktionen kann die Einordnung von Lending, Staking, tokenisierten Forderungen oder Schadensersatzleistungen zusätzliche Fragen aufwerfen. Bewahre daher Transaktionshistorien, Zeitpunkte, Beträge, Wallet-Adressen und verfügbare Belege auf. Bei erheblichen Summen oder unklaren Sachverhalten ist eine individuelle steuerliche Abklärung sinnvoll.
Die FINMA beaufsichtigt bestimmte Finanzmarktaktivitäten und warnt vor Risiken im Zusammenhang mit digitalen Vermögenswerten. Daraus folgt nicht, dass jedes DeFi-Protokoll oder jede Token-Anwendung von der FINMA bewilligt oder geschützt wäre. Ein Smart Contract kann öffentlich zugänglich sein, ohne dass Nutzer eine schweizerische Einlagensicherung oder einen beaufsichtigten Ansprechpartner haben. Prüfe deshalb Anbieter, Rechtsverhältnisse und konkrete Produkte getrennt voneinander.
FAQ: Häufige Fragen zu Reentrancy
Ist Reentrancy dasselbe wie ein Double-Spend-Angriff? Nein. Bei Reentrancy nutzt ein Angreifer fehlerhafte Abläufe innerhalb eines Smart Contracts aus. Double Spending bezeichnet allgemein die unzulässige mehrfache Verwendung derselben digitalen Einheit; im Blockchain-Konsens hat dieser Begriff eine andere technische Bedeutung. Beide Phänomene können finanzielle Schäden verursachen, sollten aber nicht miteinander verwechselt werden.
Kann eine Hardware Wallet Reentrancy verhindern? Nein. Sie kann helfen, private Schlüssel vom Internetgerät zu trennen und Transaktionen bewusster zu bestätigen. Sie repariert jedoch keinen fehlerhaften Smart Contract. Wenn Du Vermögenswerte freiwillig in einen verwundbaren DeFi-Vertrag einzahlst, schützt die sichere Verwahrung Deines privaten Schlüssels nicht automatisch vor einem Fehler im Protokoll.
Sind geprüfte Smart Contracts sicher? Eine unabhängige Prüfung ist ein wichtiges Qualitätssignal, aber keine Garantie. Prüfungen haben einen bestimmten Umfang und beziehen sich auf bestimmte Codeversionen und Annahmen. Spätere Upgrades, neue Integrationen und wirtschaftliche Veränderungen können neue Risiken schaffen. Besonders hilfreich sind transparente Berichte, wiederholte Tests und öffentlich dokumentierte Fehlerbehebungen.
Kann Reentrancy auch ohne direkte Ether-Überweisung auftreten? Ja. Externe Aufrufe können durch andere Token-Standards, Hooks oder die Zusammenarbeit mehrerer Verträge entstehen. Ein vermeintlich lesender Aufruf kann problematische Zwischenwerte sichtbar machen. Entscheidend ist, ob eine Funktion während eines noch nicht abgeschlossenen Zustands erneut oder indirekt erreicht werden kann.
Was soll ich tun, wenn ein verwendetes Protokoll einen Reentrancy-Vorfall meldet? Prüfe zuerst die Authentizität der Meldung. Vermeide überstürzte Signaturen und bewahre Transaktionsdaten auf. Ob eine Auszahlung sinnvoll oder überhaupt möglich ist, hängt vom Zustand des Protokolls und offiziellen Hinweisen ab. Versuche nicht, mit unbekannten Rettungs-Websites oder vermeintlichen Support-Mitarbeitern zu interagieren.
Fazit: Reentrancy ist ein Architekturproblem, kein Kursphänomen
Reentrancy zeigt, wie eng technische Programmierfehler und finanzielle Risiken in DeFi verbunden sind. Ein Vertrag kann eine formal gültige Transaktion ausführen und trotzdem Geld verlieren, wenn er vor einer externen Interaktion seine internen Daten nicht korrekt aktualisiert. Die wichtigste technische Gegenmassnahme ist eine saubere Zustandslogik, ergänzt durch Wiedereintrittsschutz, Tests, Audits und geeignete Betriebsprozesse.
Für Dich als Nutzer zählt vor allem, Risiken auf der richtigen Ebene zu beurteilen. Ein stabiler Tokenpreis, ein bekannter Projektname oder eine grosse Community sagen wenig über die Sicherheit einzelner Smart Contracts aus. Prüfe die tatsächliche Anwendung, ihre Abhängigkeiten und ihre Änderungsrechte. Investiere nur Beträge, deren vollständigen Verlust Du tragen kannst. Dieser Beitrag dient der allgemeinen Information und stellt keine individuelle Anlage-, Steuer- oder Rechtsberatung dar.
Kommentare