Reentrancy Attack erklärt: Wie man Reentrancy in Solidity verhindert

Reentrancy-Angriffe bleiben eine der berüchtigtsten und hartnäckigsten Bedrohungen für die Sicherheit von Smart Contracts auf Ethereum und EVM-kompatiblen Chains. Trotz jahrelanger Bemühungen in der Branche sehen sich neue Protokolle weiterhin mit Reentrancy-Schwachstellen konfrontiert, was zu erheblichen finanziellen Verlusten führt – manchmal in Millionenhöhe. Diese Exploits treten häufig in DeFi-Lending-, Staking- und Bridge-Verträgen auf, bei denen externe Aufrufe und Token-Transfers üblich sind.

In diesem Artikel analysieren wir die Mechanik eines Reentrancy-Angriffs, identifizieren typische anfällige Vertragsmuster und teilen erprobte Gegenmaßnahmen. Basierend auf unserer Analyse von über 255 Smart Contract-Audits bei Soken zeigen wir auf, wie nuancierte Solidity-Coding-Praktiken und umfassende Test-Workflows Reentrancy-Bedrohungen verhindern können. Der Beitrag verweist außerdem auf verwandte Risiken wie Delegatecall-Missbrauch und Flash-Loan-Taktiken, um ein ganzheitliches Verständnis zu gewährleisten – essenziell für jeden ernsthaften Web3-Entwickler oder Security Auditor.

Was ist ein Reentrancy-Angriff und wie nutzt er Smart Contracts aus?

Ein Reentrancy-Angriff tritt auf, wenn ein schadhafter Vertrag wiederholt eine Funktion eines anfälligen Vertrags aufruft, noch bevor die ursprüngliche Ausführung abgeschlossen ist, und dabei den inkonsistenten Zustand des Vertrags ausnutzt.

In der Praxis entsteht eine Reentrancy-Schwachstelle durch schlecht geregelte Reihenfolgen von Zustandsänderungen und externen Aufrufen innerhalb eines Contracts. Wenn der Contract ETH oder Token per Call oder Transfer an eine nicht vertrauenswürdige Adresse sendet, kann der Empfänger vor der Aktualisierung der Zustandsvariablen rekursiv in die anfällige Funktion zurückkehren. Dies ermöglicht es dem Angreifer, Gelder abzusaugen oder die Vertragslogik unerwartet zu manipulieren.

Ein Beispiel stellt der berüchtigte DAO-Hack von 2016 dar, bei dem fast 60 Millionen Dollar durch Reentrancy-Schwächen entwendet wurden — eine Warnung für die Branche. Seitdem wurde erkannt, dass die Ursache darin liegt, dass der Kontostand oder Zustand des Vertrags erst nach externen Aufrufen aktualisiert wird, wodurch ein inkonsistentes Zustandsfenster entsteht, das der Angreifer ausnutzt.

Experteneinsicht aus Soken-Audits: „In über 40 % unserer jüngsten DeFi-Sicherheitsaudits treten Reentrancy-Muster in irgendeiner Form auf, oft subtile Variationen mit Proxy Contracts oder geschachtelten Aufrufen. Das Erkennen erfordert eine gründliche Analyse der Vertragsinteraktionen über einzelne Vertragsinspektionen hinaus.“

Übliche Solidity-Muster, die Reentrancy-Schwachstellen verursachen

Reentrancy-Schwachstellen entstehen typischerweise durch eine spezifische Reihenfolge von Operationen: externe Aufrufe (wie ETH-Transfers oder Token-Abrufe) erfolgen bevor der Contract seine internen Zustandsvariablen aktualisiert.

Das anfälligste Muster sieht folgendermaßen aus:

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount;
}

Hier findet der externe Aufruf mittels call.value() vor der Verringerung des Nutzerkontostands statt. Während dieses externen Aufrufs kann die Fallback-Funktion eines Angreifers rekursiv withdraw() aufrufen und so Gelder abziehen, bevor das Guthaben aktualisiert wird.

Wichtige riskante Konstrukte umfassen:

• Externe Aufrufe vor Zustandsupdates: ETH oder Tokens werden geschickt, bevor der Kontostand angepasst wird.
• Verwendung von call oder send ohne Schutzmaßnahmen: Externe Aufrufe über Low-Level-Funktionen umgehen Checks und können Fallback-Funktionen triggern.
• Fehlende Reentrancy-Guards: Keine Mutexes oder andere Sperrmechanismen.
• Komplexe Aufrufketten mit Delegatecall: Diese können indirekt Reentrancy über externe Aufrufe innerhalb aufgerufener Verträge öffnen.

Im Gegensatz dazu kehrt ein sicheres Muster die Reihenfolge um:

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;  // zuerst Zustand aktualisieren
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

Wie man Reentrancy-Angriffe in Solidity verhindert: Best Practices & Tools

Der effektivste Schutz gegen Reentrancy besteht darin, den Zustand vor externen Aufrufen zu aktualisieren und explizite Reentrancy-Schutzmuster zu verwenden.

Standardisierte Gegenmaßnahmen:

1. Checks-Effects-Interactions-Muster:
   Aktualisiere immer zuerst den internen Zustand, bevor du externe Aufrufe tätigst. Das minimiert inkonsistente Vertragszustände während externer Aufrufe.

2. Reentrancy Guards / Mutexes:
   OpenZeppelins Solidity-ReentrancyGuard verwendet einen einfachen Mutex, um verschachtelte Aufrufe zu blockieren. Integration wie folgt:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureContract is ReentrancyGuard {
    mapping(address => uint256) balances;

    function withdraw(uint256 amount) public nonReentrant {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success);
    }
}

1. Externe Aufrufe begrenzen:
   Minimiere Transfers oder Interaktionen in kritischen Funktionen – nutze Pull- statt Push-Zahlungen, sodass Nutzer explizit Gelder abheben.

2. Statische Analyse und automatisierte Tools:
   Werkzeuge wie Slither und die Audit-Frameworks von Soken markieren Reentrancy.

3. Neueste Solidity-Versionen und Features verwenden:
   Solidity 0.8+ bringt eingebaute Overflow-Prüfungen, aber Reentrancy-Risiken bestehen weiterhin – kombiniere Code-Sicherheit mit bewährten Designmustern.

Soken-Methodik: Unsere Audits vereinen manuelles Threat Modeling, symbolische Ausführung und Fuzz Testing, die komplexe Reentrancy-Flows erfassen, welche generelle Scanner oft übersehen.

Reale Beispiele für Reentrancy-Exploits und deren Auswirkungen

Reentrancy-Angriffe sind trotz gestiegener Awareness weiterhin verbreitet. Nachstehend ein Vergleich bemerkenswerter Hacks, der Vielfalt und Kosten solcher Exploits verdeutlicht:

Anmerkung: Sokens Audits legen Wert auf vielschichtige Sicherheit, besonders bei cross-contract calls und Token-Standards, die dynamisch Fallback-Funktionen aktivieren können.

Delegatecall und Flash-Loan-Vektoren: Vergrößerung der Reentrancy-Risiken

Delegatecall, das Code im Kontext des aufrufenden Contracts ausführt, kann das Risiko von Reentrancy verschleiern und die Angriffsfläche vergrößern – besonders in Kombination mit Flash Loans.

Reentrancy-Angriffe nutzen häufig Flash Loans, um Kapital für rekursive Geldabflüsse zu maximieren:

• Flash Loans bieten große Liquidität in einer einzigen Transaktion.
• Ein Angreifer nutzt die mittels Flash Loan geliehenen Mittel, um rekursive Aufrufe zu triggern und Protokollliquidität vor der Rückzahlung leerzuräumen.
• Delegatecall kann unbeabsichtigt externen, nicht vertrauenswürdigen Code ausführen, der Vertragszustände ändert oder Reentries ermöglicht.

Sicherheits-Einsicht: „Nach Soken-Erfahrung betrifft Reentrancy-Schutz nicht nur einzelne Verträge, sondern das Protokolldesign insgesamt – besonders wenn Delegatecall und Flash Loans zusammenkommen. Verträge müssen Reentrancy-Guards mit Eingangskontrollen und flash-loan-spezifischen Überprüfungen (Deckelung der Kreditbeträge, Begrenzung rekursiver Aufrufe) kombinieren.“

Vergleichstabelle: Gängige Reentrancy-Präventions-Techniken

Solidity-Codebeispiel: Ein anfälliger Reentrancy-Vertrag und seine Absicherung

Hier ein minimal anfälliger Vertrag und seine gehärtete Version mittels ReentrancyGuard:

// Anfällig: Auszahlung vor Kontostand-Update
contract Vulnerable {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient funds");
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] -= amount; // Anfällig: Zustand erst nach externem Aufruf aktualisiert
    }
}

Absicherung mit OpenZeppelin ReentrancyGuard und Effekten vor Interaktion:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract Secure is ReentrancyGuard {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external nonReentrant {
        require(balances[msg.sender] >= amount, "Insufficient funds");
        balances[msg.sender] -= amount; // Zustand vor externem Aufruf aktualisieren
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

Profi-Tipp: Kombinieren Sie stets Checks-Effects-Interactions mit Reentrancy-Guards. Audits von Contract-Call-Graphen sowie Fuzz-Tests können subtile Multi-Hop-Reentrancy-Schwachstellen vor Deployment aufdecken.

Reentrancy-Schwachstellen bleiben eine kritische Bedrohung für Smart Contracts, insbesondere in komplexen DeFi-Ökosystemen, die Flash Loans und Delegatecall verwenden. Die effektivsten Schutzmaßnahmen verbinden diszipliniertes Coding (Checks-Effects-Interactions), explizite Reentrancy-Guards, gründliche Audits und kontextbewusste Transaktionsvalidierung.

Bei Soken vereint unsere Sicherheitsforschung manuelle und automatisierte Techniken, verfeinert an über 255 Smart Contract-Audits, und identifiziert konsequent Reentrancy sowie verwandte Risiken. Die Nutzung bewährter Best Practices und umfassender Testmethoden ist für jedes Projekt, das Nutzergelder verwaltet, unverzichtbar.

Benötigen Sie fachkundige Sicherheitsberatung? Das Soken-Audit-Team hat über 255 Smart Contracts geprüft und mehr als 2 Milliarden US-Dollar an Protokollwert gesichert. Egal ob Sie eine umfassende Auditierung, eine kostenlose Security X-Ray-Bewertung oder Unterstützung bei der Navigation durch Krypto-Regulierungen benötigen – wir sind bereit, Ihnen zu helfen.

Kontaktieren Sie einen Soken-Experten | Sehen Sie sich unsere Auditberichte an