Was ist ein Wiedereintrittsangriff und wie können sich Smart Contracts dagegen wehren?

Re-Entrancy-Angriffe in Smart Contracts 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. Dieser Exploit nutzt die Reihenfolge aus, in der Zustandsänderungen und externe Aufrufe ausgeführt werden.

2. Das berüchtigtste Beispiel ist der DAO-Hack im Jahr 2016, bei dem ein Angreifer über 60 Millionen US-Dollar erbeutete, indem er rekursiv Gelder aus einem Vertrag abzog, der die Guthaben vor dem Senden von Ether nicht aktualisierte.

3. Diese Angriffe zielen typischerweise auf Funktionen ab, die externe Aufrufe an nicht vertrauenswürdige Verträge durchführen und gleichzeitig kritische Zustandsvariablen in einem inkonsistenten Zustand halten.

4. Während des rekursiven Aufrufs löst die Fallback- oder Empfangsfunktion des Angreifers dieselbe Auszahlungslogik erneut aus und umgeht so effektiv Zugriffskontrollen oder Kontostandsprüfungen.

5. Die Hauptschwachstelle liegt in der Verletzung des Check-Effects-Interactions-Musters, bei dem Zustandsänderungen immer vor externen Aufrufen erfolgen sollten, um Manipulationen während der Ausführung zu verhindern.

Häufige anfällige Muster in der Solidität

1. Funktionen, die Ether oder Token an benutzerkontrollierte Adressen senden, ohne zuvor die interne Buchhaltung zu aktualisieren, sind Hauptziele für einen Wiedereintritt.

2. Verträge, die Low-Level-Aufrufe wie Anrufe mit nativen Ether-Transfers verwenden, sind besonders gefährdet, da sie das gesamte verbleibende Gas weiterleiten und so eine komplexe Rückruflogik ermöglichen.

3. Logik, die auf Validierungen nach dem Aufruf beruht, schlägt fehl, wenn der Aufruf selbst einen rekursiven Eintrag auslöst, wodurch diese Prüfungen erst dann wirkungslos werden, wenn der Schaden angerichtet ist.

4. Vererbungsstrukturen können unbeabsichtigt Funktionen offenlegen, wenn übergeordnete Verträge keine angemessenen Schutzmaßnahmen erzwingen, selbst wenn untergeordnete Verträge sicher erscheinen.

5. Bibliotheken oder Proxy-Muster können Schwachstellen verbreiten, wenn der Delegatecall-Mechanismus eine Zustandsbeschädigung durch gemeinsam genutzte Speicherlayouts zulässt.

Effektive Abwehrmechanismen

1. Implementieren Sie das Checks-Effects-Interactions- Muster konsequent: Validieren Sie immer Eingaben, aktualisieren Sie Statusvariablen und fahren Sie dann mit externen Aufrufen fort.

2. Verwenden Sie Wiedereintrittswächter aus etablierten Bibliotheken wie ReentrancyGuard von OpenZeppelin, die Mutex-Sperren verwenden, um rekursive Einträge zu blockieren.

3. Überweisen Sie Geld lieber per Überweisung oder Senden statt per Anruf , da diese Methoden die Gasweiterleitung einschränken und die Angriffsfläche verringern.

4. Führen Sie Pull-over-Push-Zahlungsmodelle ein, bei denen Benutzer Gelder einfordern, anstatt diese automatisch versenden zu lassen, wodurch Risiken bei ausgehenden Anrufen vermieden werden.

5. Wenden Sie während der Entwicklung strenge statische Analysetools und formale Verifizierung an, um potenzielle Rekursionspfade vor der Bereitstellung zu erkennen.

Häufig gestellte Fragen

Was macht eine Fallback-Funktion in Wiedereintrittsszenarien gefährlich? Eine Fallback-Funktion wird gefährlich, wenn sie Logik enthält, die die Geschäftsfunktionen des aufrufenden Vertrags erneut aufruft. Wenn der ursprüngliche Vertrag seinen Status vor einem externen Aufruf nicht aktualisiert hat, kann dieser rekursive Auslöser veraltete Salden oder Berechtigungen ausnutzen.

Kann ein Wiedereintritt über mehrere Vertragsinteraktionen hinweg erfolgen? Ja, ein funktionsübergreifender Wiedereintritt ist möglich, wenn verschiedene Funktionen innerhalb desselben Vertrags ohne ordnungsgemäße Synchronisierung auf den gemeinsamen Status zugreifen. Ein Angreifer könnte eine Funktion auslösen, die extern aufruft, und dann mithilfe des Fallbacks eine zweite anfällige Funktion betreten, bevor Statusaktualisierungen erfolgen.

Sind Nicht-Ether-Verträge immun gegen einen Wiedereintritt? Nein, auch Token-Verträge, die ERC-20-Transfers abwickeln, können ausgenutzt werden. Wenn eine Token-Übertragung einen Empfänger-Hook auslöst (z. B. Genehmigen + Rückruf) und der empfangende Vertrag den Status des Absenders während der Übertragung manipuliert, entstehen ähnliche rekursive Exploits.

Wie tragen Compiler-Upgrades dazu bei, den Wiedereintritt zu verringern? Neuere Versionen von Solidity enthalten sicherere Standardeinstellungen und Warnungen für bekannte Anti-Patterns. Beispielsweise reduzieren explizite Sichtbarkeitsspezifizierer und verbesserte Regeln für Gasstipendien unbeabsichtigtes Verhalten. Allerdings können Compilerfunktionen allein keine logischen Fehler beseitigen, die architektonische Disziplin erfordern.