Vermeidung von Infinite Mint Attacks in Solidity

Was ist ein unendlicher Mint-Angriff und wie funktioniert er?

Ein unendlicher Mint-Angriff tritt auf, wenn ein Token-Vertrag es einem Angreifer erlaubt, Tokens ohne gültige Berechtigung zu erstellen, ohne eine maximale Versorgung zu erzwingen, oder beides. Der Angreifer prägt eine willkürliche Menge an Tokens, verkauft, tauscht, hinterlegt oder kollateralisiert die neu erstellten Tokens, bevor Märkte und Integrationen reagieren können.

Die Konsequenz ist nicht nur Inflation. Unendliches Minting kann den Austauschwert eines Tokens vernichten, Liquiditätspools auslaugen und ungesicherte Sicherheiten in Kredit- oder Treasury-Systemen schaffen. Am 05.06.2022 wurde Elrond mit einem Vorfall, der als Infinite Mint klassifiziert wurde, registriert, bei dem ein Verlust von 113,0 Mio. USD verzeichnet wurde — was zeigt, wie eine fehlerhafte Ausgabegrenze auf Systemebene zu einem ecosystemweiten Schaden führen kann.

Was ist ein unendlicher Mint-Angriff und wie funktioniert er?

Ein unendlicher Mint-Angriff nutzt eine Token-Ausgabepfade aus, die nicht zuverlässig nachweisen, wer prägen darf und wie viel existieren darf. Eine öffentlich zugängliche oder falsch geschützte mint-Funktion erlaubt es einem Angreifer, Guthaben zu erstellen, die vom Rest des Protokolls als legitime ERC-20-Token behandelt werden.

Eine mint-Funktion ist nur dann sicher, wenn ihre Ausführung durch eine Berechtigung des Aufrufers, die Ausgabebedingungen und die Bestandsführung mit dem ökonomischen Design des Protokolls übereinstimmen. Wenn jeder Anrufer die mint-ähnliche Logik erreichen kann oder ein privilegierter Anrufer eine Obergrenze umgehen kann, ist die Knappheit des Tokens lediglich eine Annahme.

Ein typischer unendlicher Mint-Angriff folgt diesem Ablauf:

1. Der Angreifer erkennt einen extern aufrufbaren Mint-Pfad oder eine umgehbare Zugriffskontrolle.
2. Der Angreifer ruft die Funktion mit einem vom Angreifer kontrollierten Empfänger und Betrag auf.
3. Der Vertrag erhöht das Guthaben des Angreifers und oft auch die totalSupply.
4. Der Angreifer transferiert die geminteten Tokens in eine DEX-Pool, einen Kreditmarkt, eine Bridge oder eine Vault.
5. Der Angreifer tauscht künstliche Tokens gegen echte Vermögenswerte oder nutzt sie als Sicherheit.
6. Liquidity Provider, Kreditgeber und Token-Inhaber tragen den daraus entstehenden wirtschaftlichen Verlust.

Unendliche Mint-Schwachstellen sind besonders gefährlich, wenn Token-Guthaben von anderen Verträgen akzeptiert werden, ohne unabhängig zu überprüfen, wie diese Guthaben entstanden sind. Ein Kreditprotokoll kann z.B. nicht zwischen Tokens unterscheiden, die durch die vorgesehene Emission entstanden sind, und solchen, die durch eine fehlende Zugriffskontrolle geprägt wurden.

Welche Solidity-Muster verursachen Schwachstellen bei unendlichem Minting?

Unendliche Mint-Schwachstellen entstehen meist durch fehlende Berechtigungen, fehlende Obergrenzen oder Berechtigungen, die optisch korrekt erscheinen, aber durch einen unbeabsichtigten administrativen Weg erreichbar sind. Überprüfen Sie jede Funktion, die das Guthaben erhöht, direkt oder indirekt.

Das offensichtlichste Muster ist eine öffentliche mint-Funktion ohne Beschränkungen beim Aufrufer:

function mint(address to, uint256 amount) external {
    balanceOf[to] += amount;
    totalSupply += amount;
}

Das gleiche Risiko besteht, wenn ein Entwickler die falsche Identität überprüft. Beispielsweise sollte tx.origin nicht zur Bestimmung der Mint-Berechtigung herangezogen werden, da ein Angreifer eine privilegierte Wallet dazu verleiten kann, einen bösartigen Zwischenvertrag aufzurufen. Ebenso ist das Prüfen, ob ein Empfänger privilegiert ist, kein Beweis dafür, dass der Aufrufer Token prägen darf.

Weitere häufige Ursachen sind:

• Eine setMinter-Funktion, die von jedem Konto aufgerufen werden kann und Angreifern ermöglicht, sich selbst Prägerechte zu gewähren.
• Ein upgradefähiger Proxy, dessen Upgrade-Authority die Mint-Beschränkungen ersetzen kann.
• Eine Bridge oder ein Cross-Chain-Handler, der beliebigen Nachrichten als Mint-Anweisungen vertraut.
• Eine Obergrenze, die in einer mint-Funktion durchgesetzt wird, aber in einer anderen Ausgabe-Route, z.B. bei Belohnungsansprüchen oder Migrationen, fehlt.
• Mathematische Fehler oder Einheitenumrechnungsfehler, die eine nominelle Obergrenze unwirksam machen.
• Burn- und Mint-Kontrollen, bei denen Burns nicht wirklich geprüft werden, bevor Ersatztokens ausgegeben werden.

Allein die Variable totalSupply ist kein Kontrollmechanismus. Der Vertrag muss jede Prägung ablehnen, die dazu führt, dass totalSupply + amount den vorgesehenen Maximalwert übersteigt. Dieses Prinzip muss bei allen Ausgabewegen gelten, inklusive administrativer Wiederherstellung, Bridge-Minting, Rewards und Migrationen.

Wie sieht unsicherer und korrigierter Solidity-Code für unendliches Minting aus?

Ein verwundbarer Vertrag für unendliches Minting offenbart eine unbeschränkte Ausgabe-Funktion. Jeder externe Account kann beliebige Tokens prägen, ohne Begrenzung auf eine maximale Versorgung.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VerwundbaresUnendlichesMintToken {
    string public constant name = "Verwundbares Token";
    string public constant symbol = "VULN";

    uint256 public totalSupply;
    mapping(address => uint256) public balanceOf;

    event Transfer(address indexed from, address indexed to, uint256 amount);

    function mint(address to, uint256 amount) external {
        // SCHWACHSTELLE: jeder kann beliebig Tokens erzeugen.
        totalSupply += amount;
        balanceOf[to] += amount;
        emit Transfer(address(0), to, amount);
    }

    function transfer(address to, uint256 amount) external returns (bool) {
        require(balanceOf[msg.sender] >= amount, "Ungenügendes Guthaben");

        unchecked {
            balanceOf[msg.sender] -= amount;
        }
        balanceOf[to] += amount;

        emit Transfer(msg.sender, to, amount);
        return true;
    }
}

Die korrigierte Version trennt den Administrator vom autorisierten Prägenden und erzwingt eine maximale Versorgung, bevor das Guthaben erhöht wird. Die Obergrenze ist kein Ersatz für Berechtigungen, und Berechtigungen sind kein Ersatz für eine Obergrenze. Beide Kontrollmechanismen adressieren unterschiedliche Fehlerfälle.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract BegrenztesMandatMintToken {
    string public constant name = "Begrenztes Token";
    string public constant symbol = "CAP";

    address public immutable admin;
    uint256 public immutable maxSupply;
    uint256 public totalSupply;

    mapping(address => bool) public isMinter;
    mapping(address => uint256) public balanceOf;

    event Transfer(address indexed from, address indexed to, uint256 amount);
    event MinterUpdated(address indexed minter, bool erlaubt);

    modifier nurAdmin() {
        require(msg.sender == admin, "Nicht Administrator");
        _;
    }

    modifier nurMinter() {
        require(isMinter[msg.sender], "Nicht Prägeberechtigter");
        _;
    }

    constructor(uint256 maxSupply_) {
        require(maxSupply_ > 0, "Null-Obergrenze");
        admin = msg.sender;
        maxSupply = maxSupply_;
        isMinter[msg.sender] = true;
    }

    function setMinter(address minter, bool erlaubt) external nurAdmin {
        isMinter[minter] = erlaubt;
        emit MinterUpdated(minter, erlaubt);
    }

    function mint(address to, uint256 amount) external onlyMinter {
        // FIX: Genehmigte Ausgabe darf die immutable Obergrenze nicht überschreiten.
        require(totalSupply + amount <= maxSupply, "Obergrenze überschritten");

        totalSupply += amount;
        balanceOf[to] += amount;
        emit Transfer(address(0), to, amount);
    }

    function transfer(address to, uint256 amount) external returns (bool) {
        require(balanceOf[msg.sender] >= amount, "Ungenügendes Guthaben");

        unchecked {
            balanceOf[msg.sender] -= amount;
        }
        balanceOf[to] += amount;

        emit Transfer(msg.sender, to, amount);
        return true;
    }
}

Wenn Ihr Protokoll z.B. minting durch Rewards, Bridges, Vault-Anteile oder Migrationen vorsieht, kann eine Smart-Contract-Audit- und Sicherheitsüberprüfung jeden Ausgabepfad auf seine Berechtigung und die Einhaltung der Versorgung invarianten vor Deployment überprüfen.

Wie verhindert man unendliche Mint-Angriffe in Solidity?

Vorbeugung gegen unendliche Mint-Angriffe erfordert ein mehrschichtiges Ausgabedesign: explizite Berechtigungen, durchgesetzte Versorgungskonflikte, enge administrative Befugnisse und Tests, die beweisen, dass kein anderer Weg existiert, um Guthaben zu erstellen. Das passende Design hängt davon ab, ob die Versorgung fix, begrenzt, emissionsbasiert, kollateralisiert oder brückenbasiert ist.

Bei Tokens mit fester Versorgung ist die stärkste Methode oft, die gesamte Zuweisung bei Deployment zu prägen und alle späteren Mint-Fähigkeiten zu entfernen. Für emission-basierte Tokens ist es sinnvoll, einen messbaren Zeitplan abzulegen, die Gesamtobergrenze in der gemeinsam genutzten internen Ausgabe-Funktion durchzusetzen und sicherzustellen, dass jede externe Funktion eine eigene Berechtigungszweck hat.

Die Soken-Methodik sieht Minting als eine Asset-Create-Grenze, nicht nur als Bequemlichkeitsfunktion. Jeder Weg, der Token-Guthaben erhöht, sollte eine dokumentierte Berechtigungsmodell, eine explizite ökonomische Grenze und eine testbare Invariante besitzen.

Welche realen Vorfälle wurden als unendliche Mint-Attacken klassifiziert?

Aufgezeichnete Fälle von unendlichem Minting zeigen, dass Schwachstellen bei der Token-Ausgabe etablierte Assets sowie neue Protokolle über mehrere Chains hinweg betreffen. Die unten gelisteten Vorfälle sind im DefiLlama-Hacks-Datensatz als Infinite Mint klassifiziert.

Diese Vorfälle teilen eine zentrale wirtschaftliche Eigenschaft: Sobald ungesicherte Tokens in einen integrierten Markt gelangen, erstreckt sich der Angriff über den Token-Vertrag hinaus. Liquidity Pools kaufen die künstliche Versorgung, Kreditmärkte könnten sie als Sicherheit akzeptieren, und Brücken oder Vaults könnten das Guthaben in weitere Systeme weiterleiten.

Die relevante Fragestellung lautet daher: „Kann ein Angreifer mint aufrufen?“ oder noch weiter gefasst: „Kann jeder unzuverlässige oder übermäßig vertrauenswürdige Pfad das Protokoll dazu verleiten, ungesicherte Tokens als gültige Vermögenswerte anzuerkennen?“

Wie erkennt man eine Schwachstelle bei unendlichem Minting vor der Deployment?

Die Erkennung solcher Schwachstellen erfordert eine umfassende Abbildung aller Zustandsübergänge, die das Guthaben erhöhen, und den Nachweis, dass jeder Übergang durch eine Berechtigung erfolgt und das vorgesehene Versorgung invariant bewahrt. Eine manuelle Überprüfung sollte bei den Token-Verträgen beginnen, muss aber auch in Bridging-, Vault-, Reward-Verteilungs-, Upgrademodulen- und Admin-Hilfsfunktionen fortgesetzt werden.

Folgende Checkliste kann dabei helfen:

1. Alle Schreibzugriffe auf Guthaben, Anteile, Versorgungscounter und interne Mint-Funktionen identifizieren.
2. Sicherstellen, dass jede externe Ausgabe-Route eine angemessene Anrufberechtigung besitzt.
3. Überprüfen, ob jeder Pfad die gleiche Obergrenze oder Emissionskontrolle durchsetzt.
4. Funktionen prüfen, die Minters und Administratoren hinzufügen, entfernen oder austauschen.
5. Abwärts- und Aufwärtswege bei Upgrades, Bridges, Migrationen und Callbacks nachverfolgen, die die Mint-Logik erreichen können.
6. Überprüfen, ob privilegierte Konten die Obergrenze, Emittent oder Buchhaltungseinheit unerwartet ändern können.
7. Sicherstellen, dass Mint-Events und totalSupply mit der tatsächlichen Guthaben-Schöpfung übereinstimmen.
8. Integrationstests durchführen, bei denen Tokens als Sicherheit, Liquidität oder Vault-Vermögen akzeptiert werden.

Slither ist nützlich, um extern aufrufbare Funktionen, privilegierte Zustandsänderungen und verdächtige Zugriffskontrollmuster zu erkennen, kann aber keine wirtschaftlich korrekte Versorgungslage bestätigen. Eine manuelle Überlegung ist unerlässlich, um indirekte Mint-Pfade und bereichsübergreifende Zuständigkeiten zu prüfen.

Mit Foundry-Fuzzing lassen sich Tests durchführen, um zu prüfen, dass beliebige Anrufer keine Tokens prägen können und dass die Versorgung nie die Obergrenze übersteigt. Invariante Tests sind besonders effektiv, weil sie die Sicherheits-Property direkt formulieren:

function invariant_supplyNeverExceedsCap() public view {
    require(token.totalSupply() <= token.maxSupply(), "Versorgungslimit verletzt");
}

Ein weiteres Invarianten-Statement sollte sicherstellen, dass nur autorisierte Akteure die Versorgung erhöhen können. In der Soken-Review-Methodik wird diese Eigenschaft getestet, indem alle öffentlichen Funktionen überprüft werden, nicht nur die Funktion mint. Für weitergehende Informationen zu Zugriffskontrolle, Token-Rechnungsführung und systembezogenen Risiken besuchen Sie das Soken Hub.

Sicherheits-Einsatz: Die Soken-Methodik behandelt jeden neuen Token als eine Verpflichtung, die vom Protokoll geschaffen wurde. Wenn der Vertrag nicht beweisen kann, wer diese Verpflichtung autorisiert hat und warum sie innerhalb des Ausgabe-Musters bleibt, ist der Mint-Pfad eine Sicherheitsgrenze, die eine Neugestaltung erfordert.

Eine Rollenüberprüfung und eine Obergrenze wandeln uneingeschränkte Ausgabe in einen begrenzten, verantwortlichen Vorgang um – vorausgesetzt, alle Mint-Pfade verwenden sie. Die zentrale technische Aufgabe besteht darin, die Guthabenerzeugung zu zentralisieren und Umgehungen durch Konstruktion unmöglich zu machen.

Vor dem Launch oder Upgrade sollte die vorgesehene Versorgung invariabel in verständlicher Sprache formuliert, im gemeinsamen Mint-Pfad implementiert und mit Foundry-Invariante-Tests durchgesetzt werden.