Die 5 größten Sicherheitslücken bei Smart Contracts und wie man sie verhindert

Wiedereintrittsangriffe

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

2. Dieser Fehler ermöglicht es Angreifern, Gelder abzuschöpfen, indem sie wiederholt eine Auszahlungsfunktion aufrufen, bevor Statusvariablen aktualisiert werden.

3. Der berüchtigte DAO-Hack im Jahr 2016 nutzte genau dieses Muster aus und führte zum Verlust von ETH im Wert von über 60 Millionen US-Dollar .

4. Entwickler können dieses Risiko mindern, indem sie das Checks-Effects-Interactions-Muster anwenden und so sicherstellen, dass alle Zustandsänderungen vor jedem externen Aufruf erfolgen.

5. Durch die Verwendung des ReentrancyGuard-Modifikators von OpenZeppelin wird ein Sperrmechanismus hinzugefügt, der den rekursiven Zugriff auf sensible Funktionen verhindert.

Ganzzahliger Überlauf und Unterlauf

1. Vor Solidity 0.8.0 wurden arithmetische Operationen bei Über- oder Unterlauf nicht automatisch zurückgesetzt.

2. Angreifer könnten Salden manipulieren, indem sie Werte zum Umlauf zwingen – beispielsweise durch Subtrahieren von Null, um eine enorme positive Zahl zu erzeugen.

3. Im Jahr 2018 erlitt das BeautyChain-Projekt einen kritischen Exploit, bei dem ein Unterlauf zu einer unbefugten Token-Prägung führte.

4. Ein Upgrade auf Solidity 0.8.0+ behebt dieses Problem auf Compiler-Ebene, da integrierte Prüfungen jetzt automatische Wiederherstellungen auslösen.

5. Für Legacy-Codebasen, die noch ältere Versionen verwenden, müssen SafeMath-Bibliotheken explizit importiert und für jede arithmetische Operation verwendet werden.

Ungeprüfte externe Anrufe

1. Verträge gehen häufig davon aus, dass externe Aufrufe erfolgreich sind, ohne dass Rückgabewerte überprüft oder Fehler behandelt werden.

2. Wenn ein aufgerufener Vertrag rückgängig gemacht wird oder stillschweigend scheitert, kann der aufrufende Vertrag mit ungültigen Zustandsannahmen fortfahren.

3. Beim Parity Wallet-Hack ermöglichte ein ungeprüfter Aufruf eines Bibliotheksvertrags böswilligen Akteuren die Übernahme des Wallet-Besitzes.

4. Verwenden Sie immer require(call.success, 'External call failed') oder Low-Level-Aufrufe mit expliziter Erfolgsvalidierung.

5. Vermeiden Sie Delegataufrufe, es sei denn, dies ist unbedingt erforderlich. Missbrauchte Delegatecalls können zu Speicherkollisionen und der Ausführung willkürlichen Codes führen.

Vorreiterrolle durch öffentliche Transaktionen

1. Der Mempool von Ethereum macht ausstehende Transaktionen allen Validatoren und Suchern zugänglich, bevor er in Blöcke aufgenommen wird.

2. Angreifer suchen nach profitablen Gelegenheiten – wie großen Swaps oder Governance-Vorschlägen – und übermitteln konkurrierende Transaktionen mit höheren Gasgebühren.

3. Im Jahr 2020 zogen führende Bots während volatiler Marktveränderungen über 12 Millionen US-Dollar von Uniswap v2-Liquiditätsanbietern ab.

4. Implementieren Sie Commit-Reveal-Systeme für kritische Aktionen wie Auktionsgebote oder Governance-Abstimmungen.

5. Verwenden Sie private Transaktions-Relays wie Flashbots Protect oder integrieren Sie eine Schwellenwertverschlüsselung, um die Absicht bis zur Ausführung zu verschleiern.

Logische Fehler in der Zugangskontrolle

1. Falsch konfigurierte Modifikatoren oder fehlerhafte Rollenzuweisungslogik können nicht autorisierten Benutzern Administratorrechte gewähren.

2. Bei dem Cream Finance-Vorfall ermöglichte ein logischer Fehler in der Eigentümerübertragungsfunktion einem Angreifer, sich selbst als neuen Eigentümer festzulegen.

3. Fest codierte Adressen oder fehlender Eigentumsverzicht nach der Bereitstellung schaffen dauerhafte Angriffsflächen.

4. Erzwingen Sie Multisignaturanforderungen für privilegierte Funktionen mithilfe von Standards wie Gnosis Safe.

5. Führen Sie manuelle Prüfungen aller onlyOwner- , onlyRole- und benutzerdefinierten Zugriffsmodifikatoren durch, um Vererbungspfade zu bestätigen und die Sicherheit außer Kraft zu setzen.

Häufig gestellte Fragen

F: Kann eine formelle Verifizierung alle Schwachstellen von Smart Contracts beseitigen? A: Die formale Verifizierung beweist mathematisch, dass bestimmte Eigenschaften unter allen Eingaben gelten, sie kann jedoch keine Fehler in der Geschäftslogik, wirtschaftliche Angriffe oder Integrationsprobleme mit externen Protokollen abdecken.

F: Ist es sicher, geprüften Code aus anderen Projekten wiederzuverwenden? A: Nicht von Natur aus. Selbst geprüfter Code kann bei der Bereitstellung in neuen Umgebungen kontextspezifische Annahmen, veraltete Abhängigkeiten oder ungetestete Randfälle enthalten.

F: Reproduzieren Testnetze die Sicherheitsbedingungen des Mainnets vollständig? A: Nein. Testnetzen mangelt es an echten wirtschaftlichen Anreizen, sie weisen ein anderes Miner-Verhalten auf und führen oft modifizierte Client-Versionen aus – was sie für die Erkennung von Frontrunning- oder Griefing-Vektoren unzureichend macht.

F: Welchen Zusammenhang haben Orakelmanipulationen mit Schwachstellen bei Smart Contracts? A: Oracle-Manipulation ist per se kein Fehler auf Vertragsebene, aber Verträge, die auf zentralisierten oder gering abgedeckten Preis-Feeds basieren, bergen systemische Risiken – z. B. kann ein einzelner kompromittierter Knoten, der falsche Daten einspeist, Liquidationen über DeFi-Protokolle hinweg auslösen.