Was ist ein Wiedereintrittsangriff in Smart Contracts?

Wiedereintrittsangriffe verstehen

1. Ein Wiedereintrittsangriff liegt vor, wenn ein böswilliger Vertrag wiederholt eine anfällige Funktion eines anderen Vertrags zurückruft, bevor die erste Ausführung abgeschlossen ist.

2. Dieser Exploit nutzt den externen Aufrufmechanismus in Ethereum-Smart-Verträgen, bei dem die Kontrolle an eine externe Adresse übertragen wird, bevor Zustandsänderungen abgeschlossen werden.

3. Der Angreifer stellt einen Vertrag bereit, der eine Fallback- oder Empfangsfunktion enthält, die rekursive Aufrufe der Rückzugs- oder Übertragungslogik des Ziels auslöst.

4. Da Ethereum Aufrufe synchron mit einem Thread ausführt und standardmäßig keine atomaren Statusaktualisierungen erzwingt, können Salden oder Flags während des Rückruffensters unverändert bleiben.

5. Infolgedessen können ohne ordnungsgemäße Kontrollen mehrmals Gelder von demselben Kontostand abgezogen werden, wodurch die beabsichtigte wirtschaftliche Invariante des Systems verletzt wird.

Berühmtes historisches Beispiel: Der DAO-Hack

1. Im Juni 2016 wurde die dezentrale autonome Organisation namens The DAO für etwa 3,6 Millionen ETH im Wert von damals über 50 Millionen US-Dollar kompromittiert.

2. Die Schwachstelle lag in einer Split-Funktion, die es Benutzern ermöglichte, ihren Anteil abzuheben, nachdem ein Vorschlag angenommen wurde, nach der Überweisung von Geldern jedoch das Guthaben des Mitwirkenden aktualisierte.

3. Ein Angreifer hat einen Vertrag mit einer Fallback-Funktion bereitgestellt, die die Split-Funktion rekursiv aufrief, bevor die Kontostandaktualisierung erfolgte.

4. Jeder rekursive Aufruf liest den ursprünglichen Saldowert und ermöglicht so wiederholte Abhebungen von demselben zugewiesenen Betrag.

5. Der Vorfall löste einen Hard Fork der Ethereum-Blockchain aus, wodurch Ethereum und Ethereum Classic als zwei separate Ketten entstanden.

Technische Bedingungen, die den Wiedereintritt ermöglichen

1. Ein externer Anruf an eine nicht vertrauenswürdige Adresse muss kritischen Statusänderungen wie Kontostandaktualisierungen oder dem Umschalten der Zugriffsflagge vorausgehen.

2. Der Vertrag muss sich auf veränderbare Speichervariablen stützen, die Eigentum oder Berechtigung widerspiegeln, ohne Wiedereintrittswächter zu erzwingen.

3. Das Fehlen von Mutex-Mustern – wie die Verwendung eines gesperrten booleschen Werts oder Wiedereintrittsmodifikatoren – lässt Einstiegspunkte in verschachtelten Aufrufkontexten ungeschützt.

4. Die Verwendung von Low-Level-Aufrufen wie call() anstelle sichererer Alternativen wie transfer() oder send() erhöht das Risiko aufgrund fehlender Beschränkungen für Gasstipendien und des automatischen Zurücksetzens.

5. Verträge, die von veralteten oder ungeprüften Bibliotheken erben, können unbeabsichtigt Funktionen mit geerbten Wiedereintrittsoberflächen offenlegen.

Heutzutage eingesetzte Schadensbegrenzungsstrategien

1. Das Checks-Effects-Interactions-Muster erfordert die Validierung von Bedingungen, die Aktualisierung des internen Status und erst dann die Durchführung externer Aufrufe.

2. Wiedereintrittswächter – wie ReentrancyGuard von OpenZeppelin – verwenden einen gesperrten booleschen Wert, um den erneuten Eintritt einer Funktion während der aktiven Ausführung zu verhindern.

3. Die Verwendung von transfer() oder send() anstelle von raw call() erzwingt eine 2300-Gas-Grenze, wodurch Fallback-Funktionen nicht in der Lage sind, komplexe Logik einschließlich weiterer wiedereintretender Aufrufe auszuführen.

4. Statische Analysetools wie Slither und MythX erkennen potenzielle Wiedereintrittsvektoren während der Entwicklung und CI-Pipelines.

5. Formale Verifizierungs-Frameworks wie Certora und KEVM validieren Vertragsinvarianten unter beliebigen Aufrufsequenzen, einschließlich verschachtelter externer Aufrufe.

Häufig gestellte Fragen

Q1. Können Wiedereintrittsangriffe auf andere Blockchains als Ethereum stattfinden? A1. Ja. Jede EVM-kompatible Kette – einschließlich BNB Chain, Polygon und Arbitrum – ist gleichermaßen anfällig, wenn Verträge dasselbe fehlerhafte Interaktionsmuster replizieren. Nicht-EVM-Ketten mit ähnlicher externer Aufrufsemantik, wie etwa die programmübergreifenden Aufrufe von Solana unter bestimmten Bedingungen, sind ebenfalls mit ähnlichen Risiken konfrontiert.

Q2. Reicht die Verwendung von require()-Anweisungen aus, um einen Wiedereintritt zu verhindern? A2. Nein. Require-Anweisungen überprüfen Vorbedingungen, blockieren aber nicht den erneuten Eintritt. Sie wirken vor Zustandsänderungen und können nachfolgende Rückrufe nicht einschränken, sobald externe Anrufe erfolgen.

Q3. Führen Proxy-basierte aktualisierbare Verträge zusätzliche Wiedereintrittsflächen ein? A3. Ja. Wenn der Implementierungsvertrag keinen Wiedereintrittsschutz aufweist und der Proxy Anrufe weiterleitet, ohne die Anruftiefe abzufangen oder zu validieren, können aktualisierbare Muster bestehende Schwachstellen übernehmen oder verstärken.

Q4. Können Blitzkredite auch ohne böswillige Verträge einen Wiedereintritt auslösen? A4. Ja. Durch Flash-Kredite ermöglichte Angriffe kombinieren häufig Preisorakelmanipulation mit Wiedereintritt, um Liquiditätspools oder Kreditprotokolle zu entleeren, wie bei Exploits gegen dYdX, Harvest Finance und BurgerSwap zu sehen ist – die alle auf unbewachten externen Aufrufen innerhalb kritischer Pfade basieren.