Was ist ein Wiedereintrittsangriff und wie können Sie ihn in Ihren Verträgen verhindern?

Wiedereintrittsangriffe in Smart Contracts verstehen

1. Ein Wiedereintrittsangriff liegt vor, wenn ein böswilliger Vertrag wiederholt eine anfällige Funktion aufruft, bevor die erste Ausführung abgeschlossen ist. Dieses rekursive Verhalten nutzt die Reihenfolge externer Aufrufe und Zustandsänderungen innerhalb eines Smart Contracts aus.

2. Die größte Schwachstelle liegt in Verträgen, die Gelder senden oder externe Anrufe tätigen, bevor ihr interner Status aktualisiert wird. Ein Angreifer kann dieses Fenster nutzen, um mehrmals Geld abzuheben, indem er die Auszahlungsfunktion erneut aufruft.

3. Eines der berüchtigtsten Beispiele ist der DAO-Hack im Jahr 2016, bei dem Ether im Wert von über 60 Millionen US-Dollar aufgrund eines Wiedereintrittsfehlers abgezogen wurde. Der Angreifer nutzte eine Fallback-Funktion, um den Auszahlungsmechanismus rekursiv aufzurufen.

4. Diese Angriffe beschränken sich nicht auf Ether-Transfers. Jeder externe Aufruf zu einem benutzergesteuerten Vertrag kann potenziell zu einer Waffe werden, wenn keine angemessenen Sicherheitsmaßnahmen vorhanden sind.

5. Wiedereintritt bleibt eines der kritischsten Sicherheitsrisiken bei dezentralen Anwendungen, insbesondere bei DeFi-Protokollen, die große Mengen an Benutzergeldern verarbeiten.

Gemeinsame Muster, die Wiedereintritt ermöglichen

1. Verträge, die dem Muster „Zuerst anrufen, später aktualisieren“ folgen, sind grundsätzlich anfällig. Durch das Senden von Ether oder Token vor der Reduzierung des Guthabens eines Benutzers können Angreifer mit einem aktualisierten Guthaben, das immer noch dem ursprünglichen Betrag entspricht, erneut eintreten.

2. Funktionen, die auf Low-Level-Aufrufen wie call() , delegatecall() oder send() ohne ordnungsgemäße Prüfungen basieren, erhöhen die Gefährdung. Diese Methoden lösen die Fallback- oder Empfangsfunktion des Empfängers aus, die schädliche Logik enthalten kann.

3. Die unzureichende Nutzung von Pull-over-Push-Zahlungsmodellen trägt zum Risiko bei. Push-basierte Systeme, die während einer Transaktion proaktiv Gelder senden, schaffen Möglichkeiten für rekursive Ausnutzung.

4. Komplexe Vertragsinteraktionen über mehrere Schnittstellen hinweg verstärken die Gefahr. Wenn ein Vertrag einen anderen aufruft und beide einen veränderlichen Status haben, wird es schwierig, den Ausführungsfluss zu verfolgen, was die Wahrscheinlichkeit eines Versehens erhöht.

5. Selbst scheinbar sicherer Code kann gefährdet sein, wenn Zustandsaktualisierungen nicht atomar sind und nach externen Interaktionen erfolgen.

Effektive Präventionsstrategien

1. Wenden Sie das Checks-Effects-Interactions (CEI)-Muster konsequent an. Validieren Sie immer Eingaben, aktualisieren Sie interne Zustandsvariablen und tätigen Sie erst dann externe Aufrufe. Durch diese Reihenfolge entfällt das Wiedereintrittsfenster.

2. Verwenden Sie Mutex-Sperren oder Wiedereintrittswächter, die von Bibliotheken wie ReentrancyGuard von OpenZeppelin bereitgestellt werden. Diese erzwingen einen Sperrmechanismus, der verhindert, dass eine Funktion erneut eingegeben wird, während sie bereits ausgeführt wird.

3. Beschränken Sie die Verwendung von Low-Level-Anrufen. Bevorzugen Sie High-Level-Übertragungsfunktionen wie transfer() die über integrierte Schutzmaßnahmen verfügen, wie z. B. ein Gasstipendienlimit, das häufig rekursive Ausführungen verhindert.

4. Implementieren Sie Auszahlungsmuster anstelle von Direktauszahlungen. Ermöglichen Sie Benutzern, den Abruf von Geldern über eine separate Funktion zu veranlassen, wodurch die Anzahl externer Anrufe bei sensiblen Vorgängen minimiert wird.

5. Regelmäßige Audits und statische Analysetools sollten in den Entwicklungslebenszyklus integriert werden, um potenzielle Wiedereintrittsvektoren vor der Bereitstellung zu erkennen.

Häufig gestellte Fragen

Welche Rolle spielen Fallback-Funktionen bei Wiedereintrittsangriffen? Fallback-Funktionen werden automatisch ausgeführt, wenn ein Vertrag Ether ohne Daten empfängt. Angreifer erstellen böswillige Fallbacks, die anfällige Funktionen erneut aufrufen und so eine Schleife erzeugen, die Gelder abzieht, bevor die ursprüngliche Transaktion abgeschlossen ist.

Kann es zu Wiedereintritten zwischen verschiedenen Funktionen im selben Vertrag kommen? Ja. Ein funktionsübergreifender Wiedereintritt tritt auf, wenn eine Funktion einen externen Aufruf durchführt, der zu einer anderen Funktion desselben Vertrags zurückführt und dabei einen gemeinsamen Status ausnutzt, der nicht aktualisiert wurde. Um solche Wege zu blockieren, sind eine ordnungsgemäße staatliche Verwaltung und Wachen unerlässlich.

Sind Proxy-Verträge immun gegen Wiedereintritt? Nein. Proxy-Verträge können immer noch anfällig sein, wenn die Logikimplementierung ungeprüfte externe Aufrufe enthält. Da Proxys Aufrufe an aktualisierbare Logikverträge delegieren, bleibt jeder Fehler in der Logikschicht, einschließlich Wiedereintritt, ausnutzbar.

Wie wirken sich Gasbeschränkungen auf Wiedereintrittsversuche aus? Einige frühe Verteidigungsmaßnahmen beruhten darauf, das gesamte verfügbare Gas zu verbrauchen, um die Rekursion zu blockieren. Moderne Angriffe umgehen dies jedoch, indem sie eine präzise Gasschätzung verwenden. Es ist unzuverlässig, sich ausschließlich auf Gasgrenzwerte zu verlassen. Strukturelle Codemuster bieten einen stärkeren Schutz.