Wiedereintrittsangriffe in Smart Contracts verstehen (Der DAO-Hack erklärt)

Was ist ein Wiedereintrittsangriff?

1. Ein Wiedereintrittsangriff tritt auf, wenn ein externer Vertrag den aktuellen Vertrag zurückruft, bevor die ursprüngliche Ausführung abgeschlossen ist.

2. Diese Schwachstelle entsteht durch unsachgemäße Zustandsverwaltung – insbesondere, wenn Zustandsvariablen nach externen Aufrufen und nicht vorher aktualisiert werden.

3. Der Angreifer setzt einen böswilligen Vertrag ein, der eine Fallback-Funktion enthält, die die anfällige Funktion im Zielvertrag rekursiv aufruft.

4. Jeder rekursive Aufruf gelangt erneut in denselben Logikpfad und verbraucht wiederholt Geld, ohne dass der Kontostand aktualisiert wird, bis der gesamte Aufrufstapel abgewickelt ist.

5. Solche Angriffe nutzen das synchrone Single-Thread-Ausführungsmodell von Ethereum aus, bei dem externe Aufrufe den Kontrollfluss innerhalb des Aufrufkontexts behalten.

Der DAO-Vorfall: Ein historischer Zusammenbruch

1. Das DAO war eine dezentrale autonome Organisation, die 2016 auf Ethereum gegründet wurde und als Risikokapitalfonds konzipiert war, der durch Smart-Contract-Regeln gesteuert wird.

2. Sein Code ermöglichte es Token-Inhabern, sich vom DAO zu trennen und Ether durch Aufrufen einer SplitDAO -Funktion zurückzugewinnen.

3. Diese Funktion übertrug Ether an die Adresse des Anforderers, bevor der interne Kontostand aktualisiert wurde, wodurch ein klassisches Wiedereintrittsfenster entstand.

4. Ein Angreifer hat einen Vertrag mit einer Fallback-Funktion eingesetzt, der bei Erhalt von Geldern erneut SplitDAO auslöste.

5. Über mehrere verschachtelte Anrufe wurden mehr als 3,6 Millionen ETH – damals im Wert von über 50 Millionen US-Dollar – abgeschöpft, bevor die Transaktion rückgängig gemacht oder gestoppt wurde.

Wie das Ausführungsmodell von Ethereum Wiedereintritt ermöglicht

1. Jeder externe Aufruf in Solidity wird im gleichen Transaktionskontext ausgeführt, wodurch Arbeitsspeicher, Speicher und Aufrufstapel-Sichtbarkeit erhalten bleiben.

2. Es gibt keinen automatischen Wiedereintrittsschutz, es sei denn, er wird explizit über Muster wie Checks-Effects-Interactions implementiert.

3. Gasgrenzwerte verhindern keine Rekursion; Sie schränken nur die Gesamtberechnung ein und Fallback-Funktionen erfordern zur Ausführung nur minimalen Aufwand.

4. Die EVM erzwingt keine Isolation zwischen Aufrufer und Angerufenem – vom Angerufenen vorgenommene Zustandsänderungen sind für den Aufrufer während der laufenden Ausführung sichtbar.

5. Entwickler unterschätzen oft, wie stark voneinander abhängige Vertragsinteraktionen sein können, insbesondere wenn es um Token oder Orakel Dritter geht.

Gängige Codemuster, die zum Wiedereintritt einladen

1. Aktualisierung von Guthaben oder Flags nach dem Senden von Ether oder dem Aufruf externer Verträge statt vorher.

2. Verwendung von call.value()() ohne Validierung von Rückgabewerten oder Begrenzung der Rekursionstiefe.

3. Sich bei der Buchhaltung auf this.balance verlassen, anstatt Salden in Speichervariablen zu verfolgen.

4. Implementierung von Auszahlungsmustern ohne Sperren, Mutexe oder Wiedereintrittsmodifikatoren wie ReentrancyGuard von OpenZeppelin.

5. Fehler bei der Prüfung der geerbten Logik – insbesondere bei der Verwendung von Proxy-Mustern oder aktualisierbaren Verträgen, bei denen der Delegatecall den Kontext beibehält.

Häufig gestellte Fragen

F: Kann es bei ERC-20-Transfers zu einem Wiedereintritt kommen? A: Standardmäßige ERC-20-Übertragungsfunktionen lösen keine externen Aufrufe aus, sodass ein nativer Wiedereintritt nicht möglich ist. Allerdings führen Erweiterungen wie transferFrom in Kombination mit Hooks (z. B. in ERC-777) Callback-Oberflächen ein, bei denen ein Wiedereintritt auftreten kann.

F: War der DAO-Hack aufgrund einer Hard Fork umkehrbar? A: Ja. Die Ethereum-Community führte einen Hard Fork durch, um gestohlene Gelder wiederherzustellen, indem sie den Kettenverlauf neu schrieb, was zur Aufspaltung von Ethereum und Ethereum Classic führte.

F: Verhindern moderne Solidity-Versionen standardmäßig den Wiedereintritt? A: Nein. Solidity v0.8.x bietet sicherere Arithmetik und ein sichereres Zurücksetzungsverhalten, führt jedoch keinen automatischen Wiedereintrittsschutz ein. Entwickler müssen weiterhin Abwehrmuster manuell anwenden.

F: Ist die Verwendung von require(msg.sender.call{value: amount}('')) sicherer als address.send() ? A: Beides ist nicht grundsätzlich sicher. Beide ermöglichen Wiedereintritt, wenn sie vor Statusaktualisierungen verwendet werden. Der entscheidende Faktor ist die Reihenfolge der Interaktionen – nicht der spezifische Aufrufmechanismus.