Infinite Mint Attack
Ein Angriff, bei dem ein Angreifer eine unbegrenzte Menge an Tokens prägt, indem er eine Schwachstelle im Smart Contract ausnutzt.
Ein Infinite Mint Attack, oft auch als 'Mint-Glitch' oder 'Reentrancy-Schwachstelle' im Kontext von Smart Contracts bezeichnet, ist eine Art von Exploit, bei dem ein Angreifer die Logik eines Vertrags manipuliert, um eine beliebig große Menge an Tokens oder Vermögenswerten zu prägen. Dies geschieht typischerweise in dezentralen Finanzprotokollen (DeFi), insbesondere in solchen, die Token-Prägung, Kreditvergabe oder Besicherungsmechanismen beinhalten. Die Kernschwachstelle liegt oft darin, wie der Vertrag externe Aufrufe behandelt oder seinen internen Zustand während einer Transaktion aktualisiert. Zum Beispiel könnte ein Vertrag einem Benutzer erlauben, Sicherheiten zu hinterlegen, basierend auf diesen Sicherheiten einen neuen Token zu prägen und dann die Sicherheiten abzuheben, alles innerhalb einer einzigen Transaktion. Wenn der Vertrag den neuen Token prägt, bevor die Hinterlegung der Sicherheiten verifiziert oder sein interner Zustand korrekt aktualisiert wird, könnte ein Angreifer die Prägefunktion mehrmals innerhalb desselben Transaktionskontexts auslösen. Jeder Aufruf könnte mehr Tokens basierend auf denselben anfänglichen (oder unzureichend verifizierten) Sicherheiten prägen, was zur Erstellung von 'unendlichen' oder stark aufgeblähten Mengen an Tokens aus dem Nichts führt. Dies entwertet den Token und kann die Reserven des Protokolls erschöpfen. Die Verhinderung solcher Angriffe erfordert sorgfältiges Design von Smart Contracts, einschließlich der Verwendung des Checks-Effects-Interactions-Musters, Reentrancy Guards und gründlicher Audits.
graph LR
Center["Infinite Mint Attack"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_consciousness_simulation_hardware["consciousness-simulation-hardware"]:::related -.-> Center
click Rel_consciousness_simulation_hardware "/terms/consciousness-simulation-hardware"
Rel_cognitive_enhancement["cognitive-enhancement"]:::related -.-> Center
click Rel_cognitive_enhancement "/terms/cognitive-enhancement"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Wissenstest
🧒 Erkläre es wie einem 5-Jährigen
Stell dir eine magische Keksmaschine vor, die für jede Goldmünze, die du hineinwirfst, einen Keks geben soll. Wenn die Maschine kaputt ist, könntest du vielleicht eine Münze hineinwerfen, einen Keks bekommen und dann *diesen* Keks benutzen, um die Maschine auszutricksen, damit sie denkt, du hättest eine weitere Münze eingeworfen, und du bekommst unendlich viele Kekse!
🤓 Expert Deep Dive
Infinite Mint Attacks nutzen Schwächen in der Zustandsübergangslogik von Smart Contracts aus, die oft mit Reentrancy oder fehlerhafter Behandlung externer Aufrufe zusammenhängen. Ein gängiges Muster beinhaltet eine Funktion, die: 1) Benutzereingaben akzeptiert (z. B. Sicherheiten). 2) Einen externen Aufruf durchführt (z. B. an einen ERC777-Token-Vertrag, der einen Callback auslöst). 3) Den internen Zustand aktualisiert (z. B. Tokens prägt, Salden aktualisiert). Wenn der externe Aufruf einen reentranten Aufruf zurück in die ursprüngliche Funktion auslöst, bevor der Zustand aktualisiert wird (z. B. die Sicherheiten vollständig erfasst sind oder der Saldo angepasst wird), kann der Angreifer dies ausnutzen. Zum Beispiel könnte in einem Kreditprotokoll ein Benutzer Sicherheiten C hinterlegt, mint(loan_amount) aufruft, was intern einen externen Token-Vertrag aufruft. Die Fallback-Funktion dieses Token-Vertrags ruft die mint-Funktion erneut auf, wodurch der Angreifer erneut mit denselben Sicherheiten C prägen kann, bevor der erste mint-Aufruf seine Zustandsaktualisierung abschließt. Das 'Checks-Effects-Interactions'-Muster ist entscheidend: Bedingungen prüfen (Checks), internen Zustand aktualisieren (Effects), dann mit externen Verträgen interagieren (Interactions). Reentrancy Guards (Mutexes) können auch rekursive Aufrufe innerhalb desselben Transaktionskontexts verhindern. Schwachstellen können auch aus den Reentrancy-Fähigkeiten von ERC777 oder fehlerhaften ERC20-Implementierungen entstehen.